Remember that "optimized" code often runs slower than
simple code.
Here's a nice piece of obfuscated C code:
>>> Both there and for user supplied byte offsets/sizes, we just need to check
>>> that user supplied values are not being overflowed on 32-bit sector_t
>>> compiled kernels... something like
>>>
>>> if (sizeof(sector_t) == 4) {
>>> if (value & ~(((u64)1 << 32) - 1))
>>> return -E2BIG;
>>> }
>>>
>>> should compile out nicely for 64-bit sector_t and provide a simple, highly
>>> optimized check for 32-bit sector_t... (If gcc optimizes it well I should
>>> hope it will just do a simple 32-bit compare of the high 32-bits with
>>> zero...)
True, gcc will optimize that, but the extra screwing
around will prevent additional optimizations. Don't
be trying this either:
>> More readable:
>>
>> if( sizeof(sector_t)==4 && (value>>32) ) return -E2BIG;
Really, this is what you want:
if( sizeof(sector_t)==4 && (value>0xffffffff) )
return -E2BIG;
I'm not kidding. Besides looking better, it's faster.
I put the above code in a simple function that would also
do a printf if not too big. Checking the assembly...
Trying to beat the compiler:
load a zero into r4
OR that and "value" into r0 to set flags
conditional branch to .L33
// useful stuff -- where I put printf
load the OK return value
branch to .L35
.L33
load the -E2BIG return value
.L35
return
The simple way:
compare
load the -E2BIG return value
conditional branch to .L42
// useful stuff -- where I put printf
load the OK return value
.L42
return
This is with "GCC: (GNU) 2.95.4 20011002 (Debian prerelease)",
on 32-bit ppc, which surely isn't anything special or unusual.
I get pretty much the same result on Red Hat 7 with
gcc 2.96 20000731 on x86: an extra jump in the assembly.
>> A bit offtopic, but: I heard M$ and Intel compilers beat GCC
>> by 20-40% in terms of code size. Why GCC is so much behind?
>>
> er...
> one big reason is that gcc is cross platform, while
> ms and intel can cut corners and optimize for x86
That and most of gcc's optimizations are done at the RTL level, which
is just a glorified assembler. IIRC the original GCC optimizer was
based on the U of Arizona optimizer which was just an assembly
optimizer. Consequently higher lever optimizations, which every
serious compiler (but gcc) do, are unbeknownst to gcc.
If you lower the high level code too much (like gcc does), you loose
certain abstractions such as loops, that could benefit enormously from
high lever optimizations.
Diego Novillo is doing a lot of infrastructure work for gcc so we can
do these high level optimizations, but that's a bit far in the
horizon.
Cheers.
Aldy
On 27 July 2002 01:23, Albert D. Cahalan wrote:
> Remember that "optimized" code often runs slower than
> simple code.
A bit offtopic, but: I heard M$ and Intel compilers beat GCC
by 20-40% in terms of code size. Why GCC is so much behind?
--
vda
Denis Vlasenko wrote:
>On 27 July 2002 01:23, Albert D. Cahalan wrote:
>
>
>>Remember that "optimized" code often runs slower than
>>simple code.
>>
>>
>
>A bit offtopic, but: I heard M$ and Intel compilers beat GCC
>by 20-40% in terms of code size. Why GCC is so much behind?
>
>
er...
one big reason is that gcc is cross platform, while
ms and intel can cut corners and optimize for x86
Just my $.02
Joe