In my experience, -Os produced faster code on gcc-2.95 than -O2 or
-O3.
On what CPU? The effect of different optimisations varies
hugely between different CPUs (and architectures).
x86
That's not a CPU, that's an architecture. I hope you
understand there are very big differences between di
On Mon, Jun 25, 2007 at 09:08:23AM +0200, Segher Boessenkool wrote:
> >In my experience, -Os produced faster code on gcc-2.95 than -O2 or -O3.
>
> On what CPU? The effect of different optimisations varies
> hugely between different CPUs (and architectures).
x86
> >It was not only because of cac
-Os is "as fast as you can without bloating the code size",
so that is the expected result for CPUs that don't need
special hand-holding around certain performance pitfalls.
this sounds like you are saying that people wanting performance should
pick -Os.
That is true on most CPUs. Some CPUs
Also note that whether or not it is profitable to unroll
a particular loop depends largely on how "hot" that loop
is, and GCC doesn't know much about that if you don't feed
it profiling information (it can guess a bit, sure, but it
can guess wrong too).
actually, what you are saying is that the
On Mon, 25 Jun 2007, Segher Boessenkool wrote:
In my experience, -Os produced faster code on gcc-2.95 than -O2 or -O3.
On what CPU? The effect of different optimisations varies
hugely between different CPUs (and architectures).
It was not only because of cache considerations, but because
On Mon, 25 Jun 2007, Segher Boessenkool wrote:
then do we need a new option 'optimize for best overall performance' that
goes for size (and the corresponding wins there) most of the time, but is
ignored where it makes a huge difference?
That's -Os mostly. Some awful CPUs really need higher
In my experience, -Os produced faster code on gcc-2.95 than -O2 or -O3.
On what CPU? The effect of different optimisations varies
hugely between different CPUs (and architectures).
It was not only because of cache considerations, but because gcc used
different tricks to avoid poor optimizatio
then do we need a new option 'optimize for best overall performance'
that goes for size (and the corresponding wins there) most of the
time, but is ignored where it makes a huge difference?
That's -Os mostly. Some awful CPUs really need higher
loop/label/function alignment though to get any
pe
On Sun, Jun 24, 2007 at 06:33:15PM -0700, [EMAIL PROTECTED] wrote:
> On Sun, 24 Jun 2007, Arjan van de Ven wrote:
>
> >On Sun, 2007-06-24 at 18:08 -0700, [EMAIL PROTECTED] wrote:
> >>>
> >>>on a system level, size can help performance because you have more
> >>>memory available for other things.
On Mon, 25 Jun 2007, Adrian Bunk wrote:
On Sun, Jun 24, 2007 at 09:34:05PM -0400, Jeff Garzik wrote:
Adrian Bunk wrote:
The interesting questions are:
Does -Os still sometimes generate faster code with gcc 4.2?
If yes, why?
Smaller code can mean fewer page faults, fewer cache invalidations,
On Sun, Jun 24, 2007 at 09:34:05PM -0400, Jeff Garzik wrote:
> Adrian Bunk wrote:
>> The interesting questions are:
>> Does -Os still sometimes generate faster code with gcc 4.2?
>> If yes, why?
>
> Smaller code can mean fewer page faults, fewer cache invalidations, etc.
>
> It's not just a matter
he example Duron/Athlon case. Both -march=athlon{,-4) but
64K versus 256K L2 which I'd expect to be an important difference in the -Os
versus -O2 behaviour.
Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mor
On 06/25/2007 03:23 AM, Rene Herman wrote:
On 06/25/2007 02:41 AM, Adrian Bunk wrote:
The interesting questions are:
Does -Os still sometimes generate faster code with gcc 4.2?
If yes, why?
I would wager that the CPU type makes more of a difference than the
compiler version. That is, I'd ex
Adrian Bunk wrote:
The interesting questions are:
Does -Os still sometimes generate faster code with gcc 4.2?
If yes, why?
Smaller code can mean fewer page faults, fewer cache invalidations, etc.
It's not just a matter of compiler code generation, gotta look at the
whole picture.
Je
On Sun, 24 Jun 2007, Arjan van de Ven wrote:
On Sun, 2007-06-24 at 18:08 -0700, [EMAIL PROTECTED] wrote:
on a system level, size can help performance because you have more
memory available for other things. It also reduces download size and
gives you more space on the live CD
if you want
On Sun, Jun 24, 2007 at 05:58:46PM -0700, Arjan van de Ven wrote:
>
> > I wouldn't care if CONFIG_CC_OPTIMIZE_FOR_SIZE was hidden behind
> > CONFIG_EMBEDDED, but as long as it's available as a general purpose
> > option we have to consider it's performance.
>
> I think you are missing the point.
On 06/25/2007 02:41 AM, Adrian Bunk wrote:
The interesting questions are:
Does -Os still sometimes generate faster code with gcc 4.2?
If yes, why?
I would wager that the CPU type makes more of a difference than the compiler
version. That is, I'd expect my Duron with it's "puny" 64K L1 to have
On Sun, 2007-06-24 at 18:08 -0700, [EMAIL PROTECTED] wrote:
> >
> > on a system level, size can help performance because you have more
> > memory available for other things. It also reduces download size and
> > gives you more space on the live CD
> >
> > if you want to make things bigger agai
On Sun, 24 Jun 2007, Arjan van de Ven wrote:
I wouldn't care if CONFIG_CC_OPTIMIZE_FOR_SIZE was hidden behind
CONFIG_EMBEDDED, but as long as it's available as a general purpose
option we have to consider it's performance.
I think you are missing the point. You tell the kernel to
OPTIMIZE_FOR_
> I wouldn't care if CONFIG_CC_OPTIMIZE_FOR_SIZE was hidden behind
> CONFIG_EMBEDDED, but as long as it's available as a general purpose
> option we have to consider it's performance.
I think you are missing the point. You tell the kernel to
OPTIMIZE_FOR_SIZE. *over performance*. Sure. Performanc
On Sun, Jun 24, 2007 at 05:23:42PM -0700, Arjan van de Ven wrote:
> On Sun, 2007-06-24 at 20:12 -0400, Benjamin LaHaise wrote:
> > On Sun, Jun 24, 2007 at 05:09:16PM -0700, Arjan van de Ven wrote:
> > > if you care about the last cycle, don't specify -Os but -O2.
> > > simple as that... you get wha
21 matches
Mail list logo
