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

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