Slashdot Mirror

← Back to Stories (view on slashdot.org)

High Performance Linux Kernel Project — LinuxDNA

Posted by timothy on from the squeezing-out-performance dept.

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."

5 of 173 comments (clear)

  1. Will this kernel run fast on AMD processors? by steveha · · Score: 5, Interesting

    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

    --
    lf(1): it's like ls(1) but sorts filenames by extension, tersely
    1. Re:Will this kernel run fast on AMD processors? by Jah-Wren+Ryel · · Score: 4, Interesting

      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.

      It wasn't necessarily malicious, all the compiler did was default to a "slow but safe" mode on CPUIDs that it did not recognize. Intel's reasoning was that they only tweaked the code for cpus that they had qual'd the compiler against. Seeing as how they were Intel, they were not particularly interested in qualing their compiler against non-Intel chips. In hindsight, what they should have done is add a "I know what I'm doing dammit!" compilation flag that would enable optimizations anyway.

      --
      When information is power, privacy is freedom.
    2. Re:Will this kernel run fast on AMD processors? by Anonymous Coward · · Score: 5, Interesting

      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.

  2. Re:GCC compatibility by forkazoo · · Score: 4, Interesting

    Compilers shouldn't need to be compatible with each other; code should be written to standards (C99 or so) and Makefiles and configure scripts should weed out the options automatically.

    Unfortunately, writing an OS inherently requires making use of functionality not addressed in the C standards. If you stick only to behavior well defined by the ISO C standards you *can* *not* write a full kernel. Doing stuff that low level requires occasional ASM, and certainly some stuff dependent on a particular hardware platform. I think that being as compiler-portable as it is hardware-portable should certainly be a goal. The ability to build on as many platforms as possible certainly helps shake out bugs and bad assumptions. But, just saying "clean it up to full C99 compliancy, and don't do anything that causes undefined behavior" would be ignoring the actual reality of the situation, and makes as much sense as porting the whole kernel to Java or Bash scrips.

  3. Unimpressed with ICC by Erich · · Score: 4, Interesting
    We tried ICC on our simulator. The result: 8% slower than GCC. On intel chips. Specifying the correct archtiecture to ICC.

    We were not impressed.

    --

    -- Erich

    Slashdot reader since 1997