Forskjell på 386- og686 Kernel

[dabear]

Hepp, jeg kjører nå ubuntu med kernel "Ubuntu, kernel 2.6.10-5-686 ", om den er rett for systemet mitt veit jeg ikke- men den funker da. Som default var kernel "Ubuntu, kernel 2.6.10-5-386 " installert. Hva er egentlig forskjellen? hvordan veit jeg hva som er rett kernel for meg?

[objorkum]

i686 vil sei at den er optimert for Pentium II eller nyare, så det er best å bruke den.

[genstian]

i686 vil sei at den er optimert for Pentium II eller nyare, så det er best å bruke den.

jepp og enkelte ganger er det dramatisk forskjel.

[olear]

i686 vil sei at den er optimert for Pentium II eller nyare, så det er best å bruke den.

jepp og enkelte ganger er det dramatisk forskjel.

Tja, det er vel egentlig ikke så stor forskjell.

[ratix]

jepp og enkelte ganger er det dramatisk forskjel.

Har du bevis på det?

[genstian]

jepp og enkelte ganger er det dramatisk forskjel.

Har du bevis på det?

kompiler helle gentoo med i386 optimalisering og test og etter på med i686 optimalisering.

[olear]

jepp og enkelte ganger er det dramatisk forskjel.

Har du bevis på det?

kompiler helle gentoo med i386 optimalisering og test og etter på med i686 optimalisering.

For det først så snakker vi om kerneler her, og for det andre så er Slackware installasjonenen min (i486) mye raskere en din Gentoo installasjon noen gang vil bli. Det er veldig mange myter om at hvis man kompilererer/optimaliserer programmer osv så vil det gå mye raskere, men i realiteten så er det nesten ikke noe forskjell.

[ratix]

kompiler helle gentoo med i386 optimalisering og test og etter på med i686 optimalisering.

Bruker du stage1?

Hvis ikke så har du egentlig minimalt å si om denne saken

[LessThanJake]

På min ubuntu-maskin er det NULL ytelsesforskjell på 686 og 386. Kjører mprime 24/7, så jeg har testet litt på det. Kjører en xp-m, kan hende det er større forskjell på mer moderne cpu-er.

[genstian]

kompiler helle gentoo med i386 optimalisering og test og etter på med i686 optimalisering.

Bruker du stage1?

Hvis ikke så har du egentlig minimalt å si om denne saken

jepp

[genstian]

På min ubuntu-maskin er det NULL ytelsesforskjell på 686 og 386. Kjører mprime 24/7, så jeg har testet litt på det. Kjører en xp-m, kan hende det er større forskjell på mer moderne cpu-er.

på ubuntu er vel alle pakkene kompilert for i386 så derfor merker du ikke noe.

[Del]

686 arkitekturen har flere registere, og skal derfor med utnyttelse av disse være raskere. Har selv testet med prekompilerte (går litt raskere enn å kompilere selv) med P4, det var absolutt merkbar forskjell.

 

Dersom du har xp-m burde du bruke k7 optimalisering, den skal vise tilsvarende ytelsesforbedring.

[drall]

Det er flere grunner til at du vanligvis tjener lite, eller ingenting på å kompilere selv.

Med utgangspunkt i følgende påstander (hovedsaklig relatert til x86):

• Det meste av programvare er i/o-begrenset, ingen grunn til å gå lange baner for å optimalisere disse for en spesifikk prosessor.
  
• Ingen generelle cflags er "best" på alt.
  
• Utviklere av cpu-begrenset programvare finner som regel cflags som passer best mulig til sitt program (og gjerne sin kompilator). At du overstyrer disse med dine generelle, fører oftest til ytelsestap. (Dog overstyrer mange distro-pakkere likevel cflags.)
  
• GCC klarer foreløpig ikke å konsistent øke ytelsen på programmer ved å optimalisere for en gitt prosessor. På et av mine meget cpu-begrensede prosjekter gjorde jeg en del tester for å finne gode cflags. Det viste seg at "-march=pentium4" var et par prosent raskere enn ingenting, men "-march=i386 -mtune=i686" viste seg å være enda litt raskere på min pentium4. "-march=i386" var også raskere enn å ikke spesifisere -march. På samme kode var også "-march=i386 -mtune=i686" raskere enn "-march=i386" på min k6-3 (som er en i586), noe som kanskje kan tyde på at hvilke march/mtune-flagg som er best avhenger like mye av kode som prosessor. Som et interresant tillegg viste det seg at -O3 (inkluderer -finline-functions) på g++-3.4 overstyrer all bruk av inline-nøkkelordet, noe som resulterte i et ytelsestap på 5-10%, i forhold til å bruke mine hint med -O2. g++-3.3 viste seg å ha nesten motsatt oppførsel, dvs. den ignorert inline-hintene ved -O2, men benyttet dem ved -O3. Jeg kan vel også nevne at jeg har kjørt egne tester basert på diverse utbredte benchmarker, som bekrefter at bruk av -march=<din prosessor> øker ytelsen like ofte som det minker den, alltid med veldig lav margin. Som regel har det så og si ingen effekt.
  
• Den eneste virkelig nyttige nye intruksjonen i i686-arkitekturen er cmov (conditional move), simd-instruksjonene klarer ikke gcc å benytte seg av (ikke uten auto-vektorisering i hvert fall, som så vidt jeg vet ikke er god nok i gcc-4.0 ennå). Den er forøvrig tilsynelatende lite flink på å benytte seg av cmov også.
  
• De fleste distroer inkluderer i686-versjoner av pakker som er spesialtilpasset dette (asm-optimalisert el.), eller drar ekstra nytte av slikt. Feks kernelen og glibc.
  EDIT:
  
• Når flere bruker samme binær-filer, får de samme filene mer utbredt testing, og det blir lettere å finne bugs.
  

Jeg anbefaler dere å teste selv. Mangfoldig testing på ulike prosessorer burde gi sikrere resultater. (Min kildekode er for rotete for offentlig skue ennå, og jeg orker ikke grave frem gamle benchmarks fra verdensvevens avkrok).

Endret 15. mai 2005 av drall

[Del]

I tilfelle misforståelse: Jeg mente ikke at prekompilerte kjerner prosesserer raskere enn egenkompilerte, bare at det går raskere å installere en prekompilert.

 

drall: flott at du deler dine erfaringer, og du har unektelig rett i mange av poengene dine. Jeg siktet forsåvidt til at selve kjernen blir raskere, ikke nødvendigvis applikasjoner -der er det som du påpeker mange faktorer som spiller inn, og ofte lite å vinne utover -O1 optimalisering. GNU kompilatorene har vist en klar ytelsesbedring over de siste generasjonene, og er imponerende nok på nivå med PGI sin pakke. Likevel har de langt igjen før de klarer å utnytte CPU'er optimalt.

 

Litt vanskelig å forholde seg til den koden du nevner, siden du ikke sier noe om hva programmet gjør. Har du prøvd Intel sine kompilatorer, de er fritt tilgjengelige? Det går heller ikke klart frem hvilke versjoner av kompilatorene erfaringene dine er fra, selv om du nevner g++ 3.4, gcc 4.0.

[olear]

Det er flere grunner til at du vanligvis tjener lite, eller ingenting på å kompilere selv.

Når det gjelder performance så er jeg helt enig, vanligvis så kompilerer jeg alltid kernelen selv, dette fordi jeg ikke har behov for alt som ligger der, pluss at jeg hater moduler.

[drall]

drall: flott at du deler dine erfaringer, og du har unektelig rett i mange av poengene dine. Jeg siktet forsåvidt til at selve kjernen blir raskere, ikke nødvendigvis applikasjoner -der er det som du påpeker mange faktorer som spiller inn, og ofte lite å vinne utover -O1 optimalisering. GNU kompilatorene har vist en klar ytelsesbedring over de siste generasjonene, og er imponerende nok på nivå med PGI sin pakke. Likevel har de langt igjen før de klarer å utnytte CPU'er optimalt.

 

Litt vanskelig å forholde seg til den koden du nevner, siden du ikke sier noe om hva programmet gjør. Har du prøvd Intel sine kompilatorer, de er fritt tilgjengelige? Det går heller ikke klart frem hvilke versjoner av kompilatorene erfaringene dine er fra, selv om du nevner g++ 3.4, gcc 4.0.

Erfaringene mine er hovedsakelig med gcc-3.3 og gcc-3.4. Koden jeg nevner er koden bak Game Boy Color-emulatoren min. Jeg klager langt i fra på ytelsen til GCC. GCC er nok en av de beste kompilator-samlingene som eksisterer. Det jeg prøver å poengtere er at å kompilere selv som regel har lite for seg, spesielt mht å optimalisere til spesifikk prosessor.

 

Når det gjelder Intels ICC er denne kun fritt tilgjengelig for linux, jeg trenger kryssplatform-støtte og er i tillegg skeptisk til lisensen. Dessuten tyr jeg nok til asm dersom jeg ønsker optimalisering mot spesifikke prosessorer (hint: dynarec/jitc), og jeg lider slettes ingen nød mht til ytelse. Jeg er forøvrig uenig i at det ofte er lite å vinne fra -O1 til -O2 (i cpu-begrensede programmer).

 

@olear:

Jeg er helt enig i at kjernen er en av de tingene som kan ha noe for seg å kompilere selv. Prosessorvalgene i kernel-configen påvirker dessuten mer enn bare CFLAGS.

Endret 16. mai 2005 av drall

[phatsam]

jepp og enkelte ganger er det dramatisk forskjel.

Har du bevis på det?

kompiler helle gentoo med i386 optimalisering og test og etter på med i686 optimalisering.

For det først så snakker vi om kerneler her, og for det andre så er Slackware installasjonenen min (i486) mye raskere en din Gentoo installasjon noen gang vil bli. Det er veldig mange myter om at hvis man kompilererer/optimaliserer programmer osv så vil det gå mye raskere, men i realiteten så er det nesten ikke noe forskjell.

Mener du virkelig at den er mye raskere?

 

Edit:

Err, hvis du mente selve installasjonsprosessen så missforstod jeg utsanget ditt.

Endret 16. mai 2005 av phatsam

[olear]

Mener du virkelig at den er mye raskere?

Har prøvd distroer som prioriterer fart (Gentoo, Arch). Og ingen av dem er raskere en min installasjon av Slack (til generellt bruk. Når det gjelder booting så er de ganske like før man modifiserer litt ). Vi snakker ikke om sinnsyke forskjeller her, men merkbare.

 

At en distro er kompilert for i686 betyr ikke at den er raskere en en som er kompilert for i386.

[phatsam]

Mener du virkelig at den er mye raskere?

Har prøvd distroer som prioriterer fart (Gentoo, Arch). Og ingen av dem er raskere en min installasjon av Slack (til generellt bruk. Når det gjelder booting så er de ganske like før man modifiserer litt ). Vi snakker ikke om sinnsyke forskjeller her, men merkbare.

 

At en distro er kompilert for i686 betyr ikke at den er raskere en en som er kompilert for i386.

Men som sagt, hvis du prater om selve installasjonsprosessen så tviler jeg ikke et sekund, MEN, jeg tror (er sikker på) at gentooen min til daglig er en del kjappere enn slackwaren din.

 

Nå prater ikke jeg om en vanlig gentoo install, men om en gentoo 2005.0 stage 1/3 NTPL installasjon (med CFLAG'sene "-O3 -march=pentium4 -fomit-frame-pointer -pipe -ftracer -fforce-addr -momit-leaf-frame-pointer", udev, og hele pakka).

 

Kjørte slackware selv i et par år, og synes en ren stage2 install virket kjappere når jeg først skiftet over.

 

Når jeg sier install, så mener jeg ikke selve installasjonsprosessen, men hvordan systemet virker til daglig.

 

Ikke meningen å starte en flamewar nå

Endret 16. mai 2005 av phatsam

[olear]

jeg tror (er sikker på) at gentooen min til daglig er en del kjappere enn slackwaren din.

Dette er dessverre noe vi ikke kan bevise eller motbevise.