20% snabbare Linux

Fritt forum, här är det högt i taket.
Post Reply
User avatar
li
Posts: 1125
Joined: 17 April 2003, 13:38
Location: Stockholm

20% snabbare Linux

Post by li » 5 June 2004, 13:34

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!
gentoo 3.0
arch 3.0
freeBSD 8.2
qemu/minix3
win/xp

trekkie78

Post by trekkie78 » 5 June 2004, 13:38

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

User avatar
dafty
Posts: 98
Joined: 11 May 2004, 23:35
Location: Sollentuna
Contact:

Post by dafty » 5 June 2004, 13:41

Kan det vara ett steg för att konkurrera med AMD 64? :o
jag har fel karma för sql... aftonstjerna
XP 2800 // 512mb ram // 120gb hdd // Mandrake 10.0 på kärna 2.6.3

User avatar
li
Posts: 1125
Joined: 17 April 2003, 13:38
Location: Stockholm

Post by li » 5 June 2004, 13:43

trekkie78 wrote: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.
gentoo 3.0
arch 3.0
freeBSD 8.2
qemu/minix3
win/xp

TB
Posts: 84
Joined: 18 July 2002, 20:30
Contact:

Post by TB » 5 June 2004, 16:40

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

User avatar
md2perpe
Posts: 932
Joined: 12 July 2002, 18:27
Location: Hallonbergen, Kungsbodarna

Post by md2perpe » 6 June 2004, 10:39

Tom wrote: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.
RTFM: förkortning som är bra att ta till om man vill låtsas tycka att frågan är trivial, fast man egentligen inte själv har ett svar.

zuhat
Posts: 361
Joined: 24 December 2002, 04:41
Contact:

Post by zuhat » 6 June 2004, 13:08

Det var väl en bra nyhet till linuxvärlden
~ zuhat ~ zlackware ~
~ linux user #285160
~ LFS user #13183

User avatar
dr_van_nostrand
Posts: 402
Joined: 15 October 2003, 20:39
Location: Linköping
Contact:

Post by dr_van_nostrand » 6 June 2004, 13:14

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 :)
Naiv - Roligare så!

Lucifer888
Posts: 4111
Joined: 3 February 2003, 12:18
Location: Stockholm

Post by Lucifer888 » 6 June 2004, 13:20

Hur har dom kommit fram till att det blir 20% snabbare och vad blir 20% snabbare?
"It's not that I hate people, I just think they're all idiots"
"Långt hår kräver mycket näring, framhålls det, och berövar hjärnan energi."

Agitator[RoX]
Posts: 3416
Joined: 19 September 2002, 17:35
Location: Kalmar
Contact:

Post by Agitator[RoX] » 6 June 2004, 13:21

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.
Gamma Testing - Where testing is extended to the entire user community (AKA shipping the product)

EricC
Posts: 103
Joined: 27 December 2002, 00:30
Location: Norrköping
Contact:

Post by EricC » 6 June 2004, 22:02

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.
Atleast I'm not christian.

Lucifer888
Posts: 4111
Joined: 3 February 2003, 12:18
Location: Stockholm

Post by Lucifer888 » 6 June 2004, 22:08

EricC wrote: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?
"It's not that I hate people, I just think they're all idiots"
"Långt hår kräver mycket näring, framhålls det, och berövar hjärnan energi."

EricC
Posts: 103
Joined: 27 December 2002, 00:30
Location: Norrköping
Contact:

Post by EricC » 6 June 2004, 23:30

Lucifer888 wrote: 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.
Atleast I'm not christian.

User avatar
li
Posts: 1125
Joined: 17 April 2003, 13:38
Location: Stockholm

Post by li » 7 June 2004, 08:20

dr_van_nostrand wrote: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!
gentoo 3.0
arch 3.0
freeBSD 8.2
qemu/minix3
win/xp

User avatar
li
Posts: 1125
Joined: 17 April 2003, 13:38
Location: Stockholm

Post by li » 7 June 2004, 08:25

EricC wrote: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.
gentoo 3.0
arch 3.0
freeBSD 8.2
qemu/minix3
win/xp

Sparkle
Posts: 56
Joined: 24 May 2004, 10:50

Post by Sparkle » 7 June 2004, 09:17

li wrote:
EricC wrote: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

User avatar
e8johan
Posts: 1921
Joined: 2 December 2002, 11:13
Location: Alingsås
Contact:

Post by e8johan » 7 June 2004, 09:46

li wrote:
EricC wrote: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
Posts: 56
Joined: 24 May 2004, 10:50

Post by Sparkle » 7 June 2004, 10:22

e8johan wrote:
li wrote:
EricC wrote: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.

User avatar
e8johan
Posts: 1921
Joined: 2 December 2002, 11:13
Location: Alingsås
Contact:

Post by e8johan » 7 June 2004, 11:44

Sparkle wrote:
e8johan wrote:
li wrote: 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.

User avatar
li
Posts: 1125
Joined: 17 April 2003, 13:38
Location: Stockholm

Post by li » 7 June 2004, 13:14

e8johan wrote: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!
gentoo 3.0
arch 3.0
freeBSD 8.2
qemu/minix3
win/xp

User avatar
e8johan
Posts: 1921
Joined: 2 December 2002, 11:13
Location: Alingsås
Contact:

Post by e8johan » 7 June 2004, 14:48

li wrote:
e8johan wrote: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
Posts: 103
Joined: 27 December 2002, 00:30
Location: Norrköping
Contact:

Post by EricC » 7 June 2004, 16:35

li wrote:
EricC wrote: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)
Atleast I'm not christian.

robinr
Posts: 1662
Joined: 10 July 2002, 00:27

Post by robinr » 7 June 2004, 21:57

EricC wrote: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!

User avatar
li
Posts: 1125
Joined: 17 April 2003, 13:38
Location: Stockholm

Post by li » 8 June 2004, 08:53

Rätt skriven kod (med volatile etc) tål väl optimering. Jag har svårt att tro att Intel levererar en defekt kompilator.
gentoo 3.0
arch 3.0
freeBSD 8.2
qemu/minix3
win/xp

User avatar
e8johan
Posts: 1921
Joined: 2 December 2002, 11:13
Location: Alingsås
Contact:

Post by e8johan » 8 June 2004, 13:13

li wrote: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.

User avatar
li
Posts: 1125
Joined: 17 April 2003, 13:38
Location: Stockholm

Post by li » 8 June 2004, 15:46

e8johan wrote: 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...
gentoo 3.0
arch 3.0
freeBSD 8.2
qemu/minix3
win/xp

Post Reply