Comments | brad: linux-kernel; inlines

brad

linux-kernel; inlines

Jan 02, 2006 21:37

I'm addicted to reading the linux-kernel list. There's a big thread going on about changing the meaning of "inline" in the kernel tree to mean "if gcc4 wants to" instead of the historical "always-inline!" that was required due to gcc3 quirks. Then introducing a new "__always_inline" to actually mean __attribute__((always_inline)), for the few ( Read more... )

tech, linux

Comments 17

the_p0pe January 3 2006, 05:42:35 UTC

That's some good linux drama

way2tired January 3 2006, 05:51:52 UTC

I'm so amused that I read "Ricing option" more than once. What a term.

Ricing option? pyesetz January 3 2006, 05:55:28 UTC

The linked page mentions "ricing option" but does not define it. Google has only five hits for "ricing option", none of which define it.

Re: Ricing option? brad January 3 2006, 06:24:19 UTC

At least one international user on the list was confused as well. Alan Cox replied "think go-fast stripes".

I say: http://funroll-loops.org/

Re: Ricing option? mulix January 3 2006, 06:34:39 UTC

some of my best friends are gentoo developers!

Re: Ricing option? brad January 3 2006, 06:41:59 UTC

I have no problems with $x developers, it's generally $x users I can't stand.

Thread 8

(The comment has been removed)

brad January 3 2006, 06:53:56 UTC

There are certainly places it helps, but (I guess?) gcc4 can finally do it well enough to just let it do it in almost all cases.

The bigger problem is people have been throwing "inline" on every static function with one caller "just because". The problem, as many are quick to point out, is that eventually you have two callers and you forget to remove the inline, then your icache goes to shit and you have 20,000 inlines in the kernel, expanded 100,000 times. (the current situation) Also, those cases of "but there's just one caller!" actually make gcc generate worse code because gcc handles large functions with lots of local variables poorly, and a call would've just been quicker than all the spilling.

(The comment has been removed)

brad January 3 2006, 07:13:51 UTC

Yup. "inline is the new register" is heard a lot lately.

Thread 7

ghewgill January 3 2006, 14:45:01 UTC

I'm usually of the opinion that the less you try to tell your compiler/computer how to do things, the better off you are. The last company I worked at offered distributed computing infrastructure for customers, where the customers would run it over anywhere from tens to thousands of desktop machines. It always happened that some customer would want some option or other to always schedule this job on machines that have more than X cpu MHz, or Y amount of memory, or isn't being used for Z hours, or whatever. We used to call these "go-slow" options because it almost invariably turned out that if you just let the scheduler do its thing and don't try to impose artificial constraints on the job execution to try to make it go faster, then your job would in face complete sooner. Nevertheless, it turned out that the scheduler was full of exceptions that just handled these artificial constraints ( ... )