gcc partial optimization

I missed that and so far thought this is hardly possible, but, for your note, 

you can set per-function optimization levels with Function Specific Option Pragmas: 

For example:

#pragma GCC push_options
#pragma GCC optimize ("O2") 

   code
#pragma GCC pop_options

OTOH, of course, you can split the source code into several files and compile 

each with specific optimization options. Anyway.

signed to unsigned optimization

Consider the following code snippet:

#define MAX_NR 123

int
check_nr(int nr)
{
     return ((nr >= 0) && (nr < MAX_NR));
}


which is supposed to be compiled into the following instruction set:

   push   %rbp
   mov    %rsp,%rbp
   mov    %edi,-0x4(%rbp)
   cmpl   $0x0,-0x4(%rbp)
   js     0x4004be
   cmpl   $0x7a,-0x4(%rbp)
   jg     0x4004be
   mov    $0x1,%eax
   jmp    0x4004c3
   mov    $0x0,%eax
   pop    %rbp
   retq 


The fun part begins when optimizer touches the code. Compiler can
prove that with the above limitation [0, MAX_NR) it's actually safe
to eliminate one of the checks by casting signed int nr to unsigned
int nr, thus shortening the instruction set to:

   xor    %eax,%eax
   cmp    $0x7a,%edi
   setbe  %al
   retq  

Future is awesome!

KGPU

What is It?

KGPU is a GPU computing framework for the Linux kernel. It allows Linux kernel to call CUDA
programs running on GPUs directly. The motivation is to augment operating systems with GPUs
so that not only userspace applications but also the operating system itself can benefit from
GPU acceleration. It can also free the CPU from some computation intensive work by enabling
the GPU as an extra computing device.
[...]
The current KGPU release includes a demo of GPU augmentation: a GPU-accelerated AES cipher,
which can be used in conjunction with the eCryptfs encrypted filesystem. This enables read/write 
bandwidths for an ecrypted filesystem that can reach a factor of 3x ~ 4x improvement over an
optimized CPU implementation (using a GTX 480 GPU).

See http://code.google.com/p/kgpu/ if interested.

Well, the next "big thing", I guess, would be calling kernel functions from the cloud ;-)

[PHORONIX] Linux Kernel Boot Statistics: 2.6.24 To 2.6.39

Phoronix guys tested linux kernel boot times through 2.6.24 to 2.6.39

Linux 2.6.24: 23 seconds / 17 MB/s
Linux 2.6.25: 21 seconds / 21 MB/s
Linux 2.6.26: 23 seconds / 21 MB/s
Linux 2.6.27: 24 seconds / 17 MB/s
Linux 2.6.28: 24 seconds / 18 MB/s
Linux 2.6.29: 25 seconds / 18 MB/s
Linux 2.6.30: 25 seconds / 19 MB/s
Linux 2.6.31: 25 seconds / 22 MB/s
Linux 2.6.32: 27 seconds / 21 MB/s
Linux 2.6.33: 28 seconds / 19 MB/s
Linux 2.6.34: 29 seconds / 21 MB/s
Linux 2.6.35: 30 seconds / 21 MB/s
Linux 2.6.36: 30 seconds / 22 MB/s
Linux 2.6.37: 29 seconds / 22 MB/s
Linux 2.6.38: 30 seconds / 22 MB/s
Linux 2.6.39: 39 seconds / 18 MB/s

Read full story here

Pretty correlates with my feeling -- on my laptop it's getting slower. 

Though on 64-bit platform:
Linux 2.6.24: 26 seconds / 41 MB/s
Linux 2.6.25: 23 seconds / 35 MB/s
Linux 2.6.26: 26 seconds / 30 MB/s
Linux 2.6.27: 22 seconds / 32 MB/s
Linux 2.6.28: 26 seconds / 35 MB/s
Linux 2.6.29: 17 seconds / 32 MB/s
Linux 2.6.30: 25 seconds / 35 MB/s
Linux 2.6.31: 26 seconds / 32 MB/s
Linux 2.6.32: 26 seconds / 31 MB/s
Linux 2.6.33: 26 seconds / 34 MB/s
Linux 2.6.34: 19 seconds / 34 MB/s
Linux 2.6.35: 18 seconds / 34 MB/s
Linux 2.6.36: 18 seconds / 34 MB/s
Linux 2.6.37: 19 seconds / 34 MB/s