High Performance Linux Kernel Project — LinuxDNA

Thaidog submits word of a high-performance Linux kernel project called "LinuxDNA," writing "I am heading up a project to get a current kernel version to compile with the Intel ICC compiler and we have finally had success in creating a kernel! All the instructions to compile the kernel are there (geared towards Gentoo, but obviously it can work on any Linux) and it is relatively easy for anyone with the skills to compile a kernel to get it working. We see this as a great project for high performance clusters, gaming and scientific computing. The hopes are to maintain a kernel source along side the current kernel ... the mirror has 2.6.22 on it currently, because there are a few changes after .22 that make compiling a little harder for the average Joe (but not impossible). Here is our first story in Linux Journal."

Comments

Portability..

[thesupraman]

IMHO This is a great development, for one important reason.

Portability of the kernel.

GCC is a great compiler, but relying on it excessively is a bad thing for the quality of kernel code, the wider range of compilers used, the more portable and robust the code should become.

I know there will be the usual torrent of its-just-not-open-enough rants, but my reasoning has nothing to do with that, it is simply healthy for the kernel to be compilable across more compilers.

It also could have interesting implications with respect to the current GCC licensing 'changes' enforcing GPL on the new plugin structures, etc.

GCC is a wonderful compiler however it has in the past had problems with political motivations rather than technical, and moves like this could help protect against those in the future (some of us still remember the gcc->pgcc->egcs->gcc debarcle).

Of course no discussion of compilers should happen without also mentioning LLVM, another valuable project.

Will this kernel run fast on AMD processors?

[steveha]

A few years ago someone figured out that Intel's compiler was engaged in dirty tricks: it inserted code to cause poor performance on hardware that did not have an Intel CPUID.

http://techreport.com/discussions.x/8547

But perhaps they have cleaned this up before the 10.0 release:

http://blogs.zdnet.com/Ou/?p=518

steveha

Re:Will this kernel run fast on AMD processors?

[Anonymous Coward]

It wasn't necessarily malicious

Like Hell it wasn't. Read this and see if you still believe it wasn't malicious.

http://yro.slashdot.org/comments.pl?sid=155593&cid=13042922

Intel put in code to make all non-Intel parts run a byte-by-byte memcpy().

Intel failed to use Intel's own documented way to detect SSE, but rather enabled SSE only for Intel parts.

Intel's C compiler is the best you can get (at least if you can trust it). It produces faster code than other compilers. So, clearly the people working on it know what they are doing. How do you explain these skilled experts writing a byte-by-byte memcpy() that was "around 4X slower than even a typical naive assembly memcpy"?

People hacked the binaries such that the Intel-only code paths would always be taken, and found that the code ran perfectly on AMD parts. How do you then believe Intel's claims that they were only working around problems?

I'm pissed at Intel about this. You should be too.

Re:GCC compatibility - Time to move to Java?

[Anonymous Coward]

They should think about moving to a Java kernel. They could just bootstrap one of the new, clever "Just-In-Time" Virtual Machines at powerup.
These JVMs are able to dynamically optimize the running code in real-time, far beyond what could be achieved by C or C++ compilers, without any performance degradation.
A Java kernel would likely run at least 50 times faster then the very best hand coded assembler - and since the language is completely type-safe and doesn't implement dangerous legacy language features such as pointers or multiple-inheritance then it would be unlikely to ever crash.