Slashdot Mirror
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."
And what is the C99 standard to tell the compiler to pack structures with a 1 byte alignment?
(Hint: there is no standard way)
To a large extent, they have. ICC really no longer has the performance lead that it once did over gcc. There was absolutely a time when the difference was consistent, and significant. But, a lot has changed since gcc 2.95, when egcs existed. The 4.x branch in particular has been about improving the optimisation capabilities of the compiler. These days, I generally reccomend just going with gcc to anybody who asks me.
There isn't one, so what you do is use pragmas (I remember #pragma pack(1)) or attributes (__attribute__((packed)) or something similar.
Of course they're compiler-specific but there's no reason that code can't be written wrapped in defines or typedefs to stop compiler-specific stuff getting into real production code nested 10 directories down in a codebase with 40,000,000 lines.
Linux does an okay job of this - but since coders usually reference the compiler manual to use these esoteric pragmas and types, they are usually told "this is specific to GCC" (GCC does a good job of this anyway) so they should be wrapping them by default to help their application be portable and maintainable to future compilers (especially if they change the attribute name or the way it works - as has been done on many a GCC, let alone other compilers).
What usually nukes it (and why linux-dna has a compiler wrapper) is because they're hardcoding options and doing other weird GCC-specific crap. This is not because they are lazy but because the Linux kernel has a "we use GCC so support that, who gives a crap about other compilers?" development policy and it usually takes some convincing - or a fork, as linux-dna is - to get these patches into mainline.
There are actually quite a few ARM processors that do. See Jazelle.
Java is not a "systems language", meaning you don't write operating systems and systems level code in it for very good reasons.
Funny cause Sun already did that like 13 years ago.
One of them being, name me a processor that can run Java bytecode nativly.
The ARM9E.
> Its their compiler, they are damn well allowed to do what they want - call me when AMD pour that kind of resource into having their own compiler.
ARM put money into GCC. That's far better than them trying to make their own compiler.
Depends on the CPU... gcc has reasonable performance on x86, but on ia64 or ppc the vendor supplied compilers have a big advantage. even on x86 icc leads by a considerable margin in some areas, especially on very new processors.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
On the contrary - there is no support for threads or interrupts whatsoever in C99. Sure, there's pthreads and the like - but those are not part of C99, nor can you implement them in pure C99.
C itself (all versions) tries very hard to avoid tying itself to any specific hardware or OS. It even supports weird things like platforms with more than 8 bits in a char, or with reserved bits in their integers. But as a result, it has only the bare minimum featureset common across all platforms imaginable, and this is why it's very hard to write anything useful with only pure C. (No networking, no listing the contents of a directory, no executing any other programs except via system()...)
For most userland applications, C plus some OS-dependent libraries are good enough, of course. Things like the POSIX API can't be implemented in regular C (at some level you have an assembly call to the OS's syscall interface), but if you treat it as opaque, no problem.
But for an OS kernel, things aren't that easy. In the quest for high performance, Linux does all kinds of neat hacks, including things like inlining assembly code into C functions - and later rewriting that code on the fly (google for 'smp alternatives' for more information). It also makes use of CPU-level atomic operations - and exactly which ones are available depend on the architecture. Because of these kinds of hacks, which produce noticeable speed improvements, it is utterly impossible to stick purely to standards like C99.