20% snabbare Linux

[li]

Enligt uppgift har Intel en kompilator anpassad till Intel som ger 20% snabbare linux

http://www.intel.com/software/products/compilers/clin/

Tyvärr kostar den 400$.

Finns det nån som testat. Det vore kul om någon kunde starta en service att kompilera kärnor. Man skickar en konfiguration och får en kärna i retur!

[trekkie78]

Den kommersiella ger väl bara tillgång till support ? Som jag fattar så kan du ladda ner den icke-komersiella versionen från:

http://www.intel.com/software/products/ ... noncom.htm

//trekkie

[dafty]

Kan det vara ett steg för att konkurrera med AMD 64?

[li]

Den kommersiella ger väl bara tillgång till support ? Som jag fattar så kan du ladda ner den icke-komersiella versionen från:

http://www.intel.com/software/products/ ... noncom.htm

//trekkie

Jaha, det var väldigt intressant.

[TB]

Kan man kompilera själva kärnan med intels kompilator eller går det bara med gcc kompilatorn?

[md2perpe]

Kan man kompilera själva kärnan med intels kompilator eller går det bara med gcc kompilatorn?

I ett PDF-dokument hittade jag följande:

As a demonstration of compatibility with gcc,
Intel C++ 7.0 Compilers for Linux have
successfully built and run the Linux kernels,
Version 2.4.18, on IA-32 and Itanium
processors using a limited number of
temporary source patches.

Tydligen har man implementerat GCC:s utökningar av C så att kärnan går att kompilera.

[zuhat]

Det var väl en bra nyhet till linuxvärlden

[dr_van_nostrand]

Vilken version av gcc är så mycket långsammare än intels kompilator?
Ska iallafall pröva att komputera kärnan med gcc 3.4 nu

[Lucifer888]

Hur har dom kommit fram till att det blir 20% snabbare och vad blir 20% snabbare?

[Agitator[RoX]]

Hums.. Skulle ngo helst vilja att någon oberoende tittade på det där.
Att intel säger nåt sånt, tja, det ingjuter inte någon större tilltro i mig iaf.

[EricC]

Det stämmer faktiskt att intels kompilator ger en ca 20% prestandaökning, har själv gjort en del tester med den och 3d programmet Blender. Sen att Blender blir ganska buggigt med intels kompilator är en annan femma...

Jag skulle iaf inte vilja köra en intel-kompilerad Linux på ett kritiskt system.

[Lucifer888]

Det stämmer faktiskt att intels kompilator ger en ca 20% prestandaökning

Dock i vilka program märker man av det mest? Vart lämpar det sig, kärnor? servrar? vanliga desktop-program?

[EricC]

Dock i vilka program märker man av det mest? Vart lämpar det sig, kärnor? servrar? vanliga desktop-program?

Jag talar alltså enbart för Blender, där det var en ganska stor skillnad i prestanda. Har ingen aning om hur det ter sig om man testar andra typer av program.

[li]

Ska iallafall pröva att komputera kärnan med gcc 3.4 nu

Jag testade, märkte ingen skillnad, kärnan blev något större!

[li]

Jag skulle iaf inte vilja köra en intel-kompilerad Linux på ett kritiskt system.

Varför? En professionell kompilator borde väl vara säkrare. När jag använt gcc har jag ofta fått helt missledande kompileringsfel.

[Sparkle]

Jag skulle iaf inte vilja köra en intel-kompilerad Linux på ett kritiskt system.

Varför? En professionell kompilator borde väl vara säkrare. När jag använt gcc har jag ofta fått helt missledande kompileringsfel.

Fördelen med en kommersiell produkt är att man har ett telefonnummer dit man kan ringa och gråta när den kommersiella produkten inte fungerar som den ska. I ett kritiskt system är det rätt mycket värt. Faktiskt

[e8johan]

Jag skulle iaf inte vilja köra en intel-kompilerad Linux på ett kritiskt system.

Varför? En professionell kompilator borde väl vara säkrare. När jag använt gcc har jag ofta fått helt missledande kompileringsfel.

Hmm, professionell som i sluten då eller? Öppen kod borde ge säkrare resultat tack vare peer-reviewing. Jag skulle nog vilja påstå att gcc är mycket utbredd inom professionell utveckling, bl.a. för inbäddade system.

[Sparkle]

Jag skulle iaf inte vilja köra en intel-kompilerad Linux på ett kritiskt system.

Varför? En professionell kompilator borde väl vara säkrare. När jag använt gcc har jag ofta fått helt missledande kompileringsfel.

Hmm, professionell som i sluten då eller? Öppen kod borde ge säkrare resultat tack vare peer-reviewing. Jag skulle nog vilja påstå att gcc är mycket utbredd inom professionell utveckling, bl.a. för inbäddade system.

Ett kommersiell/professionell kan väl både vara öppen och "sluten". Om man köper en produkt ska man få garanti och/eller service. Det är väl poängen med att pröjsa.

Många företag väljer en kommersiell produkt framför en "öppen" även om den är sämre enbart därför att det finns support. Värt att notera är också att bara för att något är sämre än nåtot annant behöver det inte betyda att det är dåligt.

[e8johan]

Varför? En professionell kompilator borde väl vara säkrare. När jag använt gcc har jag ofta fått helt missledande kompileringsfel.

Hmm, professionell som i sluten då eller? Öppen kod borde ge säkrare resultat tack vare peer-reviewing. Jag skulle nog vilja påstå att gcc är mycket utbredd inom professionell utveckling, bl.a. för inbäddade system.

Ett kommersiell/professionell kan väl både vara öppen och "sluten". Om man köper en produkt ska man få garanti och/eller service. Det är väl poängen med att pröjsa.

Många företag väljer en kommersiell produkt framför en "öppen" även om den är sämre enbart därför att det finns support. Värt att notera är också att bara för att något är sämre än nåtot annant behöver det inte betyda att det är dåligt.

Jag är fullt medveten om att support är A och O när man köper mjukvara, men i li's mening, d.v.s. säkrare som i "färre fel" så har sluten mjukvara inga fördelar.

[li]

Jag är fullt medveten om att support är A och O när man köper mjukvara, men i li's mening, d.v.s. säkrare som i "färre fel" så har sluten mjukvara inga fördelar.

20% snabbare är väl ett starkt argument. Det finns många idealister i Linux men det kanske inte räcker alltid. Själv tycker jag att EU skulle betala de bästa linux-utvecklarna i stället för att slänga bort pengar på fifflande tobaksodlare eller på subventioner till bönder som konkurrerar ut alla uländer!

[e8johan]

Jag är fullt medveten om att support är A och O när man köper mjukvara, men i li's mening, d.v.s. säkrare som i "färre fel" så har sluten mjukvara inga fördelar.

20% snabbare är väl ett starkt argument. Det finns många idealister i Linux men det kanske inte räcker alltid. Själv tycker jag att EU skulle betala de bästa linux-utvecklarna i stället för att slänga bort pengar på fifflande tobaksodlare eller på subventioner till bönder som konkurrerar ut alla uländer!

Snabbt och fel är lika värdelöst som slött och fel, iaf när det gäller kompilatorer.

Angående EU och finansiering av Linuxutvecklare så är väl det lika felvridet som dagens jordbrukpolitik. Finansiering av mjukvaruutveckling görs lämpligen genom upphandling. Köper man öppna system så flödar pengarna till öppna system, d.v.s. deras utvecklare.

[EricC]

Jag skulle iaf inte vilja köra en intel-kompilerad Linux på ett kritiskt system.

Varför? En professionell kompilator borde väl vara säkrare. När jag använt gcc har jag ofta fått helt missledande kompileringsfel.

Det handlar inte om huruvida man får "missvisande kompileringsfel" eller inte. Jag vet bara att Blender, som är ett väldigt stabilt program vanligtvis, helt plötsligt fick osannolika buggar med intels kompilator. Men det kan mycket väl bero på nånting annat, som opengl t.ex. (då blender helt bygger på opengl)

[robinr]

Sen att Blender blir ganska buggigt med intels kompilator är en annan femma....

Jag kan också optimera kod väldigt mycket om jag får införa en massa buggar.

Som assemblerfantasterna: Nej, det funkar inte riktigt..., men visst är det snabbt!

[li]

Rätt skriven kod (med volatile etc) tål väl optimering. Jag har svårt att tro att Intel levererar en defekt kompilator.

[e8johan]

Rätt skriven kod (med volatile etc) tål väl optimering. Jag har svårt att tro att Intel levererar en defekt kompilator.

Men du vet det inte, för du har inte tillgång till källkoden. Sedan är det männskligt att fela och ganska stor sannolik att det finns ett antal fel i ett såpass stort projekt som en kompilator.

Läs lite om kodoptimering och kompilatordesign så inser du ganska snart att det man idag sysslar med är långt ifrån trivialt, och därför kan innehålla fel som bara visar sig i vissa, sällsynta fall.

[li]

Läs lite om kodoptimering och kompilatordesign så inser du ganska snart att det man idag sysslar med är långt ifrån trivialt, och därför kan innehålla fel som bara visar sig i vissa, sällsynta fall.

Det har jag. Jag har använt en mängd olika kommersiella kompilatorer genom åren. Ytterst sällan har det varit ngt fel på dem.

Om man misstänker att en kompilator optimerar på ett felaktigt sätt, så slår man helt enkelt av optimeringen. Om resultatet då blir rätt och om man själv kodat rätt så felanmäler man kompilatorn. Jag har aldrig haft problem med detta. 99.9% av alla fel visar sig vara egna tabbar...