LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software > Linux - Kernel
User Name
Password
Linux - Kernel This forum is for all discussion relating to the Linux kernel.

Notices


Reply
  Search this Thread
Old 09-08-2008, 08:42 PM   #1
monohouse
Member
 
Registered: Oct 2004
Distribution: Arch
Posts: 206

Rep: Reputation: 30
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
and getting the error:
Quote:
echo ' LD vmlinux.o'; ld -m elf_i386 -r -o vmlinux.o arch/x86/kernel/head_32.o arch/x86/kernel/head32.o arch/x86/kernel/init_task.o init/built-in.o --start-group usr/built-in.o arch/x86/kernel/built-in.o arch/x86/mm/built-in.o arch/x86/mach-default/built-in.o arch/x86/crypto/built-in.o arch/x86/vdso/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a arch/x86/lib/lib.a lib/built-in.o arch/x86/lib/built-in.o drivers/built-in.o sound/built-in.o arch/x86/pci/built-in.o net/built-in.o --end-group
LD vmlinux.o
ld: arch/x86/kernel/head_32.o: No such file: No such file or directory
the kernel buids just fine with GCC

Last edited by monohouse; 09-08-2008 at 08:46 PM.
 
Old 09-09-2008, 02:38 AM   #2
jf.argentino
Member
 
Registered: Apr 2008
Location: Toulon (France)
Distribution: FEDORA CORE
Posts: 493

Rep: Reputation: 50
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.
 
Old 09-09-2008, 06:47 AM   #3
monohouse
Member
 
Registered: Oct 2004
Distribution: Arch
Posts: 206

Original Poster
Rep: Reputation: 30
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:
-O3 -Wall -fno-rtti -fno-exceptions -march=athlon-xp -mfpmath=sse,387 -mmmx -msse -m3dnow -momit-leaf-frame-pointer -minline-all-stringops -mno-align-stringops -maccumulate-outgoing-args -msseregparm -m128bit-long-double -malign-double -mtls-direct-seg-refs -ffast-math -fsingle-precision-constant -fbranch-target-load-optimize -fbranch-target-load-optimize2 -fmodulo-sched -fsched2-use-traces -fsched-spec-load-dangerous -fsched-spec-load -fgcse-sm -fgcse-las -ftree-vectorize -fivopts -fvariable-expansion-in-unroller -fno-cprop-registers -ffunction-sections -fdata-sections -fbtr-bb-exclusive -freorder-blocks-and-partition -fmerge-all-constants -ftree-loop-im -ftree-loop-linear -fmove-loop-invariants -fprefetch-loop-arrays -funswitch-loops -ftree-loop-ivcanon -funsafe-loop-optimizations -Wunsafe-loop-optimizations --param max-gcse-memory=1000000000 --param max-gcse-passes=1000 --param max-crossjump-edges=15000 --param max-delay-slot-insn-search=15000 --param max-delay-slot-live-search=15000 --param scev-max-expr-size=15000 --param max-iterations-to-track=15000 --param max-cse-path-length=15000 --param max-cse-insns=15000 --param max-reload-search-insns=15000 --param max-sched-region-blocks=15000 --param max-sched-region-insns=15000
you can be sure that you're pretty much at the maximum possible performance you can get from GCC, but then you need to know what is the maximum that ICC has to offer

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.

Last edited by monohouse; 09-09-2008 at 06:50 AM.
 
Old 09-09-2008, 07:36 AM   #4
jf.argentino
Member
 
Registered: Apr 2008
Location: Toulon (France)
Distribution: FEDORA CORE
Posts: 493

Rep: Reputation: 50
Quote:
that linux is about "free as in beer" and being tunnel-vision limited to gnu-tools only does not represent that ideal.
I'm totally agree with you for this. But:


-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.
 
Old 09-09-2008, 01:04 PM   #5
monohouse
Member
 
Registered: Oct 2004
Distribution: Arch
Posts: 206

Original Poster
Rep: Reputation: 30
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:
-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.
I agree, all the tests that I found seem to indicate that ICC performs best when it comes to floating point math and barely any improvement when it comes to IO, and that sometimes GCC is better.

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:
-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.
that is also true, and here I also agree, kernel is mostly IO based, while ICC is optimizations are mostly math-based, and if it was all that ICC does, I wouldn't have bothered to check it, but that is not all, because ICC also performs IPO and PGO, which are known to be better that their GCC equivalents (GCC only has PGO since version 4.x and it is a new feature).

Quote:
-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...
that is also true, but that is why ICC has automatic loop unrolling heuristics, and for the rest there is the -Os and -O1 -O2 and -O3, combined with some benchmarking software, you can compile several kernels and determine which is optimal for your architecture. on top of that you have profrun. all these tools combined can give you advantages to optimize code, but what you typed is a general difficulty of optimization not ICC-specific, but we still optimize ! the question is whether it is hardcore or not.

Quote:
-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.
"this is just the beginning", eventually I will try to compile as much as possible with the best possible parameters and best possible compiler, once that is determined, and I think a kernel optimization could give accurate results in that regard for benchmarks, if the benchmarks say it is faster, then I intend to use for the rest of the system (LFS with uClibs/Busybox/DirectFB). but one thing at a time.

Quote:
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?
I don't think I know what you meen by that.

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
# ---------------------------------------------------------------------------
#
# Normally, we echo the whole command before executing it. By making
# that echo $($(quiet)$(cmd)), we now have the possibility to set
# $(quiet) to choose other forms of output instead, e.g.
#
#         quiet_cmd_cc_o_c = Compiling $(RELDIR)/$@
#         cmd_cc_o_c       = $(CC) $(c_flags) -c -o $@ $<
#
# If $(quiet) is empty, the whole command will be printed.
# If it is set to "quiet_", only the short version will be printed. 
# If it is set to "silent_", nothing will be printed at all, since
# the variable $(silent_cmd_cc_o_c) doesn't exist.
#
# A simple variant is to prefix commands with $(Q) - that's useful
# for commands that shall be hidden in non-verbose mode.
#
#	$(Q)ln $@ :<
#
# If KBUILD_VERBOSE equals 0 then the above command will be hidden.
# If KBUILD_VERBOSE equals 1 then the above command is displayed.

ifeq ($(KBUILD_VERBOSE),1)
  quiet =
  Q =
else
  quiet=quiet_
  Q = @
endif
and change to:
Code:
ifeq ($(KBUILD_VERBOSE),1)
  quiet =
  Q =
else
  quiet=
  Q =
endif
this hack makes sure that you see all compiler output during kernel build, so that in case there is an error, you can manually copy the command and repeat it in place without needing to restart the entire compile process of the kernel just to see if you fixed the problem

then under that there is
Code:
# Make variables (CC, etc...)
LD		= $(CROSS_COMPILE)ld
CC		= $(CROSS_COMPILE)gcc
CPP		= $(CC) -E
AR		= $(CROSS_COMPILE)ar
change it to
Code:
# Make variables (CC, etc...)
LD		= $(CROSS_COMPILE)xild
CC		= $(CROSS_COMPILE)icc
CPP		= $(CC) -E
AR		= $(CROSS_COMPILE)xiar
this ensures that the compile process uses the correct binaries for the process by ICC, make sure that in step 1 you manually exported the variables that are supposed to be in /usr/share/config.site-icc in addition to writing them to the file, because the kernel does not read that script, it probably does not read most of these variable from the environment, so you have to manually modify the Makefile for that

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:
gcc -Wp,-MD,kernel/.pid.o.d -nostdinc -isystem /usr/lib/gcc/i686-pc-linux-gnu/4.3.1/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -O2 -fno-stack-protector -m32 -mregparm=3 -freg-struct-return -march=i686 -mtune=pentium3 -ffreestanding -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -Iinclude/asm-x86/mach-default -fomit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(pid)" -D"KBUILD_MODNAME=KBUILD_STR(pid)" -c -o kernel/pid.o kernel/pid.c
as root and make sure that the owning user of the created file kernel/pid.o is root and other/users is not allowed to write, then see if you can continue to compile with the normal user after this file is not overwritable, if the compile fails then it's time for option #2:

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
to
Code:
CC		= $(CROSS_COMPILE)gcc
then ^C to break compile after that file is ready and then re-modify the Makefile again to icc and then re-run make, this method should work for any errors you may encounter with ICC, however this was not yet tested and unsure if this creates a working kernel at all, but this is a method that should at least compile the kernel to know what other errors in ICC need fixing

6. it should build

7. if you have an AMD cpu go here: http://server01.iiiii.info/patch-AuthenticAMD.html

Last edited by monohouse; 09-10-2008 at 10:15 PM.
 
Old 09-09-2008, 02:03 PM   #6
jf.argentino
Member
 
Registered: Apr 2008
Location: Toulon (France)
Distribution: FEDORA CORE
Posts: 493

Rep: Reputation: 50
Quote:
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?
What I try to tell is that, nowadays, even if you get 30% more efficiency by compiling your code with ICC, it's like you just bought a X months newer PC (is really X greater than 6?), and what is these X months regarding to:
- 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?
 
Old 09-09-2008, 03:53 PM   #7
monohouse
Member
 
Registered: Oct 2004
Distribution: Arch
Posts: 206

Original Poster
Rep: Reputation: 30
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
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :           194.4  :       4.99  :       1.64
STRING SORT         :          16.215  :       7.25  :       1.12
BITFIELD            :      7.1299e+07  :      12.23  :       2.55
FP EMULATION        :            25.2  :      12.09  :       2.79
FOURIER             :          5054.5  :       5.75  :       3.23
ASSIGNMENT          :          4.0682  :      15.48  :       4.02
IDEA                :            1002  :      15.32  :       4.55
HUFFMAN             :          295.28  :       8.19  :       2.61
NEURAL NET          :          5.7563  :       9.25  :       3.89
LU DECOMPOSITION    :           186.8  :       9.68  :       6.99
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 10.053
FLOATING-POINT INDEX: 8.012
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : GenuineIntel Pentium III (Katmai) 501MHz
L2 Cache            : 512 KB
OS                  : Linux 2.6.25-ARCH
C compiler          : 
libc                : 
MEMORY INDEX        : 2.257
INTEGER INDEX       : 2.715
FLOATING-POINT INDEX: 4.444
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
GCC 4.3.1 with default options:
Code:
TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          196.52  :       5.04  :       1.66
STRING SORT         :          16.328  :       7.30  :       1.13
BITFIELD            :      7.1807e+07  :      12.32  :       2.57
FP EMULATION        :           25.39  :      12.18  :       2.81
FOURIER             :          5090.3  :       5.79  :       3.25
ASSIGNMENT          :          4.1294  :      15.71  :       4.08
IDEA                :          1009.1  :      15.43  :       4.58
HUFFMAN             :           297.5  :       8.25  :       2.63
NEURAL NET          :          5.7884  :       9.30  :       3.91
LU DECOMPOSITION    :          186.96  :       9.69  :       6.99
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 10.142
FLOATING-POINT INDEX: 8.048
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : GenuineIntel Pentium III (Katmai) 501MHz
L2 Cache            : 512 KB
OS                  : Linux 2.6.26.3
C compiler          : 
libc                : 
MEMORY INDEX        : 2.279
INTEGER INDEX       : 2.738
FLOATING-POINT INDEX: 4.464
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38

Last edited by monohouse; 09-11-2008 at 01:21 AM.
 
Old 09-10-2008, 07:37 PM   #8
monohouse
Member
 
Registered: Oct 2004
Distribution: Arch
Posts: 206

Original Poster
Rep: Reputation: 30
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:
icc -Wp,-MD,kernel/.pid.o.d -nostdinc -isystem /usr/lib/gcc/i686-pc-linux-gnu/4.3.1/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wframe-larger-than=1024 -fno-stack-protector -m32 -mregparm=3 -freg-struct-return -march=pentium3 -O2 -Wall -ffreestanding -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -Iinclude/asm-x86/mach-default -fomit-frame-pointer -foptimize-sibling-calls -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(pid)" -D"KBUILD_MODNAME=KBUILD_STR(pid)" -c -o kernel/pid.o kernel/pid.c
Code:
kernel/pid.c(298): error: subscript must be constant
                        return container_of(pnr, struct pid,
                               ^
Code:
kernel/pid.c(377): error: subscript must be constant
                        result = hlist_entry(first, struct task_struct, pids[(type)].node);
                                 ^
pid.c lines 290-301
Quote:

struct pid *find_pid_ns(int nr, struct pid_namespace *ns)

{
struct hlist_node *elem;
struct upid *pnr;

hlist_for_each_entry_rcu(pnr, elem,
&pid_hash[pid_hashfn(nr, ns)], pid_chain)
if (pnr->nr == nr && pnr->ns == ns)
return container_of(pnr, struct pid, //line 298
numbers[ns->level]);

return NULL;
}
pid.c lines 370-380
Quote:
struct task_struct *pid_task(struct pid *pid, enum pid_type type)
{
struct task_struct *result = NULL;
if (pid) {
struct hlist_node *first;
first = rcu_dereference(pid->tasks[type].first);
if (first)
result = hlist_entry(first, struct task_struct, pids[(type)].node); //line 377
}
return result;
}
I might be able to fix it, if I run the specific non-compiling commandlines with gcc, but the "make" process does not skip even if the compile was successful of gcc, how can I manually control which lines of the process do take place and which do not ? to compile with gcc the lines that do not compile with icc

Last edited by monohouse; 09-10-2008 at 08:40 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Compiling error with intel cpp compiler and open mp lucifer1987 Linux - Newbie 2 04-01-2008 11:49 AM
Has anyone tried the Intel compiler? bigearsbilly Programming 3 12-22-2005 03:06 PM
Any HOWTOs about Intel C Compiler?? dNX Linux - General 0 01-11-2004 10:22 PM
intel c++ compiler sharky Linux - Software 0 08-17-2003 02:29 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software > Linux - Kernel

All times are GMT -5. The time now is 08:58 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration