compiling 2.6.26.3 with Intel compiler
I am trying to build the kernel with the intel compiler 10.1 for linux, but I have some errors and overheard that I need to use some wrapper scripts, but i was unable to find any specific documentation on how to build the kernel with ICC and I was hoping maybe someone had any experience compiling the kernel with ICC
I build the kernel with: Code:
make CC=icc -kernel Quote:
|
It's a very bad idea to compile a linux kernel with something else than GCC ! And if you're looking for performance increases, I'll try to compile main libraries before the kernel... By the way, do you have google'd? My first hit give me ftp://download.intel.com/support/per...whitepaper.pdf
A last word, GCC is a very good compiler, and there's some intel developers which are paid by intel to work on it, so maybe it's not as optimized for intel arch than ICC, but I think it's not too bad, and not too bad for PowerPC, UltraSparc, Coldfire, Blackfin... Where ICC can't do nothing. |
I've heard that (last word) before, and I agree that it may not be too bad for PowerPC, UltraSparc, Coldfire, Blackfin. however if I didn't have doubts that it IS too bad for x86/_64 I wouldn't have looked for additional adventures, but it is a fact that ICC is faster by at least 30% compared to GCC, unfortunately I also know that alot of people in the linux department don't like the idea of using non-GNU tools, and for that I have to remind you all that linux is about "free as in beer" and being tunnel-vision limited to gnu-tools only does not represent that ideal.
to be sure that GCC is not too bad as you claim I have to check that myself and compare all possible parameters, not that I don't trust you, but because I believe I can make a difference compared to the research that was done on comparing to ICC before, and I can maybe reveal some news that may proove that ICC is significantly better, and yes I am not interrested in doing that, in fact I'd take GCC anytime, but ONLY if it is better, and right now I do not know that for sure. the thing is that when you compile things with parameters such as these: Quote:
how do you compile the main libraries before the kernel ? I've read that pdf several times before and I didn't find any concrete information, it is "empty" in terms of content. but I have found other places and I heard that there are so called "wrapper scripts" that help to compile the kernel with ICC, but I was unable to find them. this looks like a simple error, because the actual compilation process does work well. |
Quote:
-When you're saying that code compiled by ICC run 30% faster than the same code compiled by GCC, it to easy to be true. If you find and take a look at some different benchmarks, you will see that for some type of operations, ICC is better, for some ICC and GCC give roughly the same results, and some show that GCC perform better than ICC. -Then, are you sure that ICC perf improvement are done for type of code you'll find in the Linux kernel? For example, ICC can have a better SSE instructions exploitation, but they aren't used in the kernel. More over, you won't find any float or double processing inside the kernel, so all performance gain that ICC have for these are meaningless for a kernel. -Another point is that a code efficiency isn't easy to validate (in my opinion it's impossible) because it rely on the system and its state. For example, an easy way to "gain" some speed is to unroll loop, but while unrolling the loop, you're increasing the code size. And what happen if the unrolled code size doesn't fit into the CPU cache while rolled one does? You have lost performance! Same thing with "inline" functions... -When you want to optimize something, you begin by where your optimization will have the greatest impact. In my opinion (can discuss about that), you'd better to get performance from most used libraries before trying to optimize the kernel. So try to compile glibc and other well used libraries with ICC. To end, performances is not all! Security, code compatibility and so on are important too... Today, 6 months after having buy the fastest computer of the world, it become just a middle-scale one. So in this kind evolution, how many time represent a 30% better performance? By the way, trying to compile the linux kernel (or any other C code) with another compiler than GCC is a great challenge which is really useful since it can reveal bugs that are hidden by GCC, but in my opinion it's the only one good reason to do so. But don't use such a kernel in a product platform, nor as your everyday kernel since kernel bugs could hurt hard. I think that if you still want to compile Linux kernel with ICC, you'd better post on an ICC (or kernel) relative forum since it's really a geek stuff. |
I have successfully built it with ICC (2.6.26.5), and it works (boots and runs), and I haven't used any optimization switches yet.
Quote:
but that depends how seriously these tests were done, and how long ago and which version on they were done, and most are done on old versions of ICC (version 8 most of the tests I found), ICC improved much since that version, a re-evaluation is always a good thing. Quote:
Quote:
Quote:
Quote:
anyway, now that I have successfully compiled the kernel with ICC10.1, I have some preliminary things to add, and while still not fully optimized (just compiles) with all the good parameters (-ip -xK etc...) I can sense that it is already faster that the latest GCC build of the kernel I made, obviously I will need to verify that with some better accuracy with some benchmarks. however, in case someone wants to know how I did it: 1. http://www.linuxfromscratch.org/hint...c-compiler.txt 2. get the latest kernel and unpack it, go to your toplevel Makefile and change lines in it that look like: Code:
# Beautify output Code:
ifeq ($(KBUILD_VERBOSE),1) then under that there is Code:
# Make variables (CC, etc...) Code:
# Make variables (CC, etc...) 3. go to arch/x86/Makefile and find a line there that contains -mno-see and -mno-mmx, remove these extra parameters, but not the entire line 4. run the source script to add vars to environment or add the /bin directory of the compiler to the $PATH$ (the former is preferred) 5. if you compile now, you will get an error in kernel/pid.c, I do not know how to fix it, currently I propose 3 ways to fix it: 1. manually compile that with gcc and see if the rest continues to compile with ICC by executing something similar to this (replace with the output of the command of your parameters that fail to compile this file) Quote:
compile the entire kernel with gcc but with the anti-silence hack enabled, so that you could capture the output, then capture the output to a file, not sure how to do this with make but there must be a way, then manually edit the created file and replace the appropriate commands, that is what can be called a "manual build", save the file and +x it, and try to run it, for the moment both of these options are untested, but they do seem to make some sense and even may work, option #3: temporarily modify the Code:
CC = $(CROSS_COMPILE)icc Code:
CC = $(CROSS_COMPILE)gcc 6. it should build 7. if you have an AMD cpu go here: http://server01.iiiii.info/patch-AuthenticAMD.html |
Quote:
- the amount of time needed to compile successfully with ICC: in a professional point of view you the pay of the engineer multiplied by the time he/she work on that can be far more than the cost of the last PC. - Optimization flags can done strange behaviours at runtime (it's true with GCC too), and floating points accuracy getting worse. For example, I think I can remember that in a linux kernel README you get with the sources you can read it is _NOT_ trustworthy to compile it with any GCC optimization flags (maybe my knowledge is outdated there, or simply I don't remember well) - A system which rely only on the compiler optimization flags to work properly is, in my own opinion, a bad system. Improve the design, search for a mathematical trick (like for the FFT)... But don't rely on compiler optimizations. There was my opinion, through my little experience in embedded system. By the way, it's very interesting and if you have the time to make some benchmark, could you please post them? A last word, did you have try compile the kernel with GCC and its optimization flags to compare results? |
gcc version of kernel so far was only compiled with default flags, to determine compilability of the kernel and it's .config in the first place, once that was accomplished I moved to ICC, now the next stage is getting the compile flags for ICC, and once that is done I will get the compile flags for GCC as well, and then compare them all with benchmark.
right now I am having difficulties with the Makefile and trying to correct, it seems there is some compiler error that did not exist before and I am sure it is because I made some wrong change in the Makefile beyond what the kernel patch does but yhe, I will post any benchmarks I make to give other people some idea what to expect from ICC10.1 and GCC compile time: (P3Katmai 500/100 2.6.26.5 ICC10.1 default) GCC 4.3.1 default: 30 minutes ICC 10.1 optimized: 59 minutes this seems to indicate that the intel compiler IS being used with it's optimization options nbench was compiled with GCC 4.3.1 Arch Linux original kernel: Code:
TEST : Iterations/sec. : Old Index : New Index Code:
TEST : Iterations/sec. : Old Index : New Index |
thanks I actually made alot of progress since then, I've read alot about many things such as:
http://www.linuxfromscratch.org/hint...c-compiler.txt while that did made progress, I still got some other probably smaller issues: Quote:
Code:
kernel/pid.c(298): error: subscript must be constant Code:
kernel/pid.c(377): error: subscript must be constant Quote:
Quote:
|
All times are GMT -5. The time now is 05:26 PM. |