Hi,
please have a look at http://www.pyrillion.org/linuxkernelpatch.html
for a working 2.6.3 patch to compile the kernel with Intel Compiler 8.0
for Linux.
Please CC me in answers/replies to this mail.
Rgs, Ingo Kubbilun.
Ingo at Pyrillion wrote:
> patch to compile the kernel with Intel Compiler 8.0
> for Linux.
Speed improvements over same kernel compiled with gcc?
Thanks,
Norberto
And results running resultant on an Athlon?
On Tue, 2004-03-09 at 21:08 -0300, Norberto Bensa wrote:
> Ingo at Pyrillion wrote:
> > patch to compile the kernel with Intel Compiler 8.0
> > for Linux.
>
> Speed improvements over same kernel compiled with gcc?
I used the patch to compile two identical kernels with gcc 3.3.3 and
icc 8.0 with oprofile support built in.
The optimization switches were chosen quite conservative, i.e.
"-O2 -Ob1", no IPO, and of course: no MMX, SSE, and SSE2 stuff inside
the kernel (thus disabling Intel's great vectorizer).
Profiling: lmbench ran ten times but time measurements were taken from
oprofile (on Pentium 4, GLOBAL_POWER_EVENTS in kernel space only,
counter overflow: 3.000).
Results: 33% of the lmbench procs faster on icc, 66% faster on gcc.
Thus, take the kernel patch as a good basis for modifying the
compiler switches and other things to get more performance gains. As
I know, a lot of people are looking for a patch.
Please check the patch file; you have to modify a lot of things in 2.6.3
to create a quite stable working version of the kernel. The patch is not
just about changing some minor Makefile things...
Kind rgs., Ingo.
-----Urspr?ngliche Nachricht-----
Von: Norberto Bensa [mailto:[email protected]]
Gesendet: Mittwoch, 10. M?rz 2004 01:09
An: Ingo at Pyrillion
Cc: [email protected]
Betreff: Re: Kernel 2.6.3 patch for Intel Compiler 8.0
Ingo at Pyrillion wrote:
> patch to compile the kernel with Intel Compiler 8.0
> for Linux.
Speed improvements over same kernel compiled with gcc?
Thanks,
Norberto
Hi All!!
>I used the patch to compile two identical kernels with gcc 3.3.3 and
>icc 8.0 with oprofile support built in.
>The optimization switches were chosen quite conservative, i.e.
>"-O2 -Ob1", no IPO, and of course: no MMX, SSE, and SSE2 stuff inside
>the kernel (thus disabling Intel's great vectorizer).
>Profiling: lmbench ran ten times but time measurements were taken from
>oprofile (on Pentium 4, GLOBAL_POWER_EVENTS in kernel space only,
>counter overflow: 3.000).
>Results: 33% of the lmbench procs faster on icc, 66% faster on gcc.
Really???
If it is ture using icc 66% faster than gcc., It is wonderful.
Could you show us detail data to lmbench results.
Thanks!!
Norihiko
Norihiko Mukouyama wrote:
> Hi All!!
>
> >Results: 33% of the lmbench procs faster on icc, 66% faster on gcc.
> If it is ture using icc 66% faster than gcc., It is wonderful.
> Could you show us detail data to lmbench results.
I saw it the other way around: gcc is faster 66% of the time. Or did I read
wrong?
Thanks,
Norberto
Hi again,
please read my last mail carefully:
"33% procs faster on icc, 66% faster on gcc"
means that gcc (GNU) is superior. But the patch is a preliminary
version...
greetings, Ingo.
-----Urspr?ngliche Nachricht-----
Von: Norihiko Mukouyama [mailto:[email protected]]
Gesendet: Mittwoch, 10. M?rz 2004 01:50
An: Ingo at Pyrillion; 'Norberto Bensa'
Cc: [email protected]
Betreff: RE: Kernel 2.6.3 patch for Intel Compiler 8.0
Hi All!!
>I used the patch to compile two identical kernels with gcc 3.3.3 and
>icc 8.0 with oprofile support built in. The optimization switches were
>chosen quite conservative, i.e. "-O2 -Ob1", no IPO, and of course: no
>MMX, SSE, and SSE2 stuff inside the kernel (thus disabling Intel's
>great vectorizer).
>Profiling: lmbench ran ten times but time measurements were taken from
>oprofile (on Pentium 4, GLOBAL_POWER_EVENTS in kernel space only,
>counter overflow: 3.000).
>Results: 33% of the lmbench procs faster on icc, 66% faster on gcc.
Really???
If it is ture using icc 66% faster than gcc., It is wonderful.
Could you show us detail data to lmbench results.
Thanks!!
Norihiko
Norberto Bensa wrote:
> Norihiko Mukouyama wrote:
>
>>Hi All!!
>>
>>
>>>Results: 33% of the lmbench procs faster on icc, 66% faster on gcc.
>>
>>If it is ture using icc 66% faster than gcc., It is wonderful.
>>Could you show us detail data to lmbench results.
>
>
> I saw it the other way around: gcc is faster 66% of the time. Or did I read
> wrong?
1/3 of the things are faster with icc. 2/3 of the things are faster
with gcc. Performance numbers not given.
// Stefan
Hi,Stefan!!
>1/3 of the things are faster with icc. 2/3 of the things are faster
>with gcc. Performance numbers not given.
Thank you very much.
I understood that meaning.
By the way,
I would like to learn the result of making his patch run on Itanium2.
Because, the difference of the performance of the compiler being sure to influence most
remarkably.
Can anyone try?
Thanks.
Norihiko
In 2.6, we already have sufficient changes for Intel IPF Compiler to
build the kernel, especially intrinscs changes, and you should not need
a patch. To make it faster, we might want to use PGO (profile guided
optimization) provided by the compiler; yes, it's available even for the
kernel with a driver.
Thanks,
Jun
>-----Original Message-----
>From: [email protected] [mailto:linux-kernel-
>[email protected]] On Behalf Of Norihiko Mukouyama
>Sent: Tuesday, March 09, 2004 6:08 PM
>To: Stefan Smietanowski; Norberto Bensa
>Cc: Ingo at Pyrillion; [email protected]
>Subject: RE: Kernel 2.6.3 patch for Intel Compiler 8.0
>
>Hi,Stefan!!
>
>>1/3 of the things are faster with icc. 2/3 of the things are faster
>>with gcc. Performance numbers not given.
>
>Thank you very much.
>I understood that meaning.
>
>By the way,
>
>I would like to learn the result of making his patch run on Itanium2.
>Because, the difference of the performance of the compiler being sure
to
>influence most
>remarkably.
>
>Can anyone try?
>
>Thanks.
>
>Norihiko
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
Hi Jun,
the patch I submitted is for icc 8.0, i.e. I386 platform only.
Did I understand your last message right that you even do not
need a kernel patch for icc, i.e. I386?
If so, then try to compile the 2.6.3 kernel using icc without
applying my patch and see what happens if icc "tries" to compile
hybrid code, i.e. mixed assembly and C statements....
The current icc 8.0 (and also icc 7.0) makes FATAL mistakes
compiling those mixings. Just check the object file that results
from "dec_and_lock.c" in arch/i386/lib using a disassembler.
Rgs, Ingo.
-----Urspr?ngliche Nachricht-----
Von: Nakajima, Jun [mailto:[email protected]]
Gesendet: Mittwoch, 10. M?rz 2004 03:53
An: Norihiko Mukouyama; Stefan Smietanowski; Norberto Bensa
Cc: Ingo at Pyrillion; [email protected]
Betreff: RE: Kernel 2.6.3 patch for Intel Compiler 8.0
In 2.6, we already have sufficient changes for Intel IPF Compiler to
build the kernel, especially intrinscs changes, and you should not need
a patch. To make it faster, we might want to use PGO (profile guided
optimization) provided by the compiler; yes, it's available even for the
kernel with a driver.
Thanks,
Jun
>-----Original Message-----
>From: [email protected] [mailto:linux-kernel-
>[email protected]] On Behalf Of Norihiko Mukouyama
>Sent: Tuesday, March 09, 2004 6:08 PM
>To: Stefan Smietanowski; Norberto Bensa
>Cc: Ingo at Pyrillion; [email protected]
>Subject: RE: Kernel 2.6.3 patch for Intel Compiler 8.0
>
>Hi,Stefan!!
>
>>1/3 of the things are faster with icc. 2/3 of the things are faster
>>with gcc. Performance numbers not given.
>
>Thank you very much.
>I understood that meaning.
>
>By the way,
>
>I would like to learn the result of making his patch run on Itanium2.
>Because, the difference of the performance of the compiler being sure
to
>influence most
>remarkably.
>
>Can anyone try?
>
>Thanks.
>
>Norihiko
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
Ingo, Hi
We tried it (2.6.4) our side. As long as we tested, we did not need _any
changes_ to the kernel tree, and I guess what you are missing is a shell
script that calls icc converting the GCC specific options to Intel
compiler.
Attached is the script. Just type "make CC=kicc" for example.
Can you be more specific about the issue with dec_and_lock.c?
Jun
> Hi Jun,
>
> the patch I submitted is for icc 8.0, i.e. I386 platform only.
>
> Did I understand your last message right that you even do not
> need a kernel patch for icc, i.e. I386?
>
> If so, then try to compile the 2.6.3 kernel using icc without
> applying my patch and see what happens if icc "tries" to compile
> hybrid code, i.e. mixed assembly and C statements....
> The current icc 8.0 (and also icc 7.0) makes FATAL mistakes
> compiling those mixings. Just check the object file that results
> from "dec_and_lock.c" in arch/i386/lib using a disassembler.
>
> Rgs, Ingo.
<<kicc>>
Hi Jun,
thanks for the script, I'll check it out.
First of all, I am using icc 8.0 (Build 20031016Z Package ID:
l_cc_p_8.0.055) and encountered several problems with the compiler and
Linux kernel 2.6.3.
1.) icc sometimes interprets assembler constraints for inline assembly
in the wrong way (I will check my disk for a sample to prove it).
2.) is it right that the "-fno-common" switch of icc is incompatible to
that of gcc and generates common variables, e.g. in modules?
3.) arch/i386/lib/dec_and_lock.c: I attached the wrong assembler version
generated by icc (with comments).
btw: Could you supply me with the PGO kernel driver for icc, or: where
can I find it?
Rgs, Ingo.
"Nakajima, Jun" <[email protected]> schrieb am 12.03.2004,
23:31:02:
> Ingo, Hi
>
> We tried it (2.6.4) our side. As long as we tested, we did not need _any
> changes_ to the kernel tree, and I guess what you are missing is a shell
> script that calls icc converting the GCC specific options to Intel
> compiler.
>
> Attached is the script. Just type "make CC=kicc" for example.
>
> Can you be more specific about the issue with dec_and_lock.c?
>
> Jun
>