In this mailing list archive I found a discussion on how to compile
kenrel 2.6.x with Intel C++ compiler, but it was a bit old, and only
kernel patch for version 2.6.5 or around so can be found. As mine is
HT enabled, I want newer one.
Does anyone know where to find it, or how to make it?
regards,
--
Luckiest in the world / Weapon of Mass Distraction
http://maverick6664.bravehost.com/
Aviation Jokes: http://www.geocities.com/tetsuji_rai/
On Thu, 12 May 2005, Tetsuji "Maverick" Rai wrote:
> In this mailing list archive I found a discussion on how to compile
> kenrel 2.6.x with Intel C++ compiler, but it was a bit old, and only
> kernel patch for version 2.6.5 or around so can be found. As mine is
> HT enabled, I want newer one.
>
> Does anyone know where to find it, or how to make it?
>
> regards,
The kernel is designed to be compiled with the GNU 'C' compler
supplied with every distribution. It uses a lot of __asm__()
statements and other GNU-specific constructions.
Why would you even attempt to convert the kernel sources to
be compiled with some other tools? Also C++ won't work because
the kernel is all about method, i.e., procedures. You need
a procedural compiler for most of it, not an object-oriented
one.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
Richard B. Johnson wrote:
> The kernel is designed to be compiled with the GNU 'C' compler
> supplied with every distribution. It uses a lot of __asm__()
> statements and other GNU-specific constructions.
Yep. And Intel added a bunch of them to their compiler so that they
could build a kernel with it.
> Why would you even attempt to convert the kernel sources to
> be compiled with some other tools?
The Intel compiler is quite good at optimizing for their processors (and
ironically for AMD ones as well). However, I think that a lot of the
gains come from the vectorizer, which of course can't be used with
kernel code.
Chris
On 05.12, Richard B. Johnson wrote:
> On Thu, 12 May 2005, Tetsuji "Maverick" Rai wrote:
>
> > In this mailing list archive I found a discussion on how to compile
> > kenrel 2.6.x with Intel C++ compiler, but it was a bit old, and only
> > kernel patch for version 2.6.5 or around so can be found. As mine is
> > HT enabled, I want newer one.
> >
> > Does anyone know where to find it, or how to make it?
> >
> > regards,
>
> The kernel is designed to be compiled with the GNU 'C' compler
> supplied with every distribution. It uses a lot of __asm__()
> statements and other GNU-specific constructions.
>
The intel compiler supports all gcc syntax tweaks (__attribute__'s,
asm, cli options...) just because they want to be perfectly compatible
with gcc to compare/substitute...
> Why would you even attempt to convert the kernel sources to
> be compiled with some other tools? Also C++ won't work because
> the kernel is all about method, i.e., procedures. You need
> a procedural compiler for most of it, not an object-oriented
> one.
Intel's is a C/C++/Fortran compiler.
Last time I checked (a year or so ago) gcc catched the intel compiler
for equivalent options, or say it the other way, adjusting gcc options
you could get more or less the same performance. There were even places
where gcc generated faster code than icc. And that was gcc-3.0.x,
I think.
It is all a matter of knowing the default options that icc uses; the
big advantage (??) of icc was that it enabled the vectorizer by
default. And I think you could not allow streaming instructions
all over the kernel. I know they are used (raid) but I suppose it has
to be in a controlled way (does context switch preserve xmm registers ?).
And vector instructions are usefull just in very restricted situations.
It would be nice to redo the tests with gcc4/icc8 ;), now that gcc
has an auto-vectorizer.
In short, from my experience, I don't worry about icc. GCC is nice.
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.11-jam17 (gcc 4.0.0 (4.0.0-3mdk for Mandriva Linux release 2006.0))
On 5/13/05, Chris Friesen <[email protected]> wrote:
> Richard B. Johnson wrote:
>
> > The kernel is designed to be compiled with the GNU 'C' compler
> > supplied with every distribution. It uses a lot of __asm__()
> > statements and other GNU-specific constructions.
>
> Yep. And Intel added a bunch of them to their compiler so that they
> could build a kernel with it.
>
> > Why would you even attempt to convert the kernel sources to
> > be compiled with some other tools?
>
> The Intel compiler is quite good at optimizing for their processors (and
> ironically for AMD ones as well). However, I think that a lot of the
> gains come from the vectorizer, which of course can't be used with
> kernel code.
>
> Chris
>
Yes, that's why I wanted to use Intel's compiler for kernel (of course
I didn't mean to use C++; the product's name is C++, it doesn't sell C
alone.) Its vectorization is so nice that SETI@home calculates
20-30% faster than the original one compiled with gcc.
But I thought it's not such a good idea to build kernel with Intel
compiler, because kernel's speed doesn't affect so much in my case.
And that vectorization isn't so effective in kernel. PGO (profile
guided optimization) is the only effective optimization in the kernel
according to
http://softwareforums.intel.com/ids/board/message?board.id=16&message.id=1504
So I decided not to try this...looks like too much effort and little
gain. and I guess that's why nobody is trying this now.
--
Luckiest in the world / Weapon of Mass Distraction
http://maverick6664.bravehost.com/
Aviation Jokes: http://www.geocities.com/tetsuji_rai/
Background: http://maverick.ns1.name/
Tetsuji "Maverick" Rai wrote:
> On 5/13/05, Chris Friesen <[email protected]> wrote:
>
>>Richard B. Johnson wrote:
>>
>>
>>>The kernel is designed to be compiled with the GNU 'C' compler
>>>supplied with every distribution. It uses a lot of __asm__()
>>>statements and other GNU-specific constructions.
>>
>>Yep. And Intel added a bunch of them to their compiler so that they
>>could build a kernel with it.
>>
>>
>>>Why would you even attempt to convert the kernel sources to
>>>be compiled with some other tools?
>>
>>The Intel compiler is quite good at optimizing for their processors (and
>>ironically for AMD ones as well). However, I think that a lot of the
>>gains come from the vectorizer, which of course can't be used with
>>kernel code.
>>
>>Chris
>>
>
>
> Yes, that's why I wanted to use Intel's compiler for kernel (of course
> I didn't mean to use C++; the product's name is C++, it doesn't sell C
> alone.) Its vectorization is so nice that SETI@home calculates
> 20-30% faster than the original one compiled with gcc.
>
> But I thought it's not such a good idea to build kernel with Intel
> compiler, because kernel's speed doesn't affect so much in my case.
> And that vectorization isn't so effective in kernel. PGO (profile
> guided optimization) is the only effective optimization in the kernel
> according to
> http://softwareforums.intel.com/ids/board/message?board.id=16&message.id=1504
>
> So I decided not to try this...looks like too much effort and little
> gain. and I guess that's why nobody is trying this now.
>
Yeah that's what the 2.6.5 patch does. Some People talked about 20% more speed with this patch last year. If anyone is
able to patch the current kernel the patch should be in -mm.
Matthias-Christian Ott
>>>>> "J" == J A Magallon <J.A.> writes:
J> On 05.12, Richard B. Johnson wrote:
>> On Thu, 12 May 2005, Tetsuji "Maverick" Rai wrote:
>>
>> > In this mailing list archive I found a discussion on how to
>> compile > kenrel 2.6.x with Intel C++ compiler, but it was a bit
>> old, and only > kernel patch for version 2.6.5 or around so can be
>> found. As mine is > HT enabled, I want newer one.
>> >
>> Why would you even attempt to convert the kernel sources to be
>> compiled with some other tools? Also C++ won't work because the
>> kernel is all about method, i.e., procedures. You need a procedural
>> compiler for most of it, not an object-oriented one.
J> Intel's is a C/C++/Fortran compiler.
J> Last time I checked (a year or so ago) gcc catched the intel
J> compiler for equivalent options, or say it the other way, adjusting
J> gcc options you could get more or less the same performance. There
J> were even places where gcc generated faster code than icc. And that
J> was gcc-3.0.x, I think.
For IA64, the intel compiler generates *much* better code than gcc.
Depending on the source, you can get factor of two or better,
particularly for crypto code like rc4.
--
Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au
The technical we do immediately, the political takes *forever*