mboost-dp1
unknown
Ja, det er lidt sjovt at selv om det er en AMD processor, så sidder der stadigvæk en del Intel Teknologi i den.
Det kommer an på hvad du mener med Intel teknologi, ingen af funktionerne i AMD processoren er [direkte] fra Intel. Alt det AMD understøtter er lavet ud fra diverse [dårlige og utilstræklige] hardwarebeskrivelser og selvfølgelig reverse engineering. Desuden skal den jo understøtte x86 "standarden".
Men nu er artiklen jo fra The Inquirer, så jeg ved ikke hvor meget sandhed der er i den og lige præcis hvordan de måler at koden performer bedre, det nævner de ikke, kun nogen forholdsvis ligegyldige procenter.
Men derfor er det da rart at se at AMD understøtter MMX/SSE/SSE2 så godt som de nu gør, da AMD er min favorit processor fabrikant ;-)
Men nu er artiklen jo fra The Inquirer, så jeg ved ikke hvor meget sandhed der er i den og lige præcis hvordan de måler at koden performer bedre, det nævner de ikke, kun nogen forholdsvis ligegyldige procenter.
Men derfor er det da rart at se at AMD understøtter MMX/SSE/SSE2 så godt som de nu gør, da AMD er min favorit processor fabrikant ;-)
Er overskriften ikke misvisende?
Nu er det vel ikke så meget et tegn på at intels compiler lige laver mere effektive binaries til opteron (så vidt jeg har forstået var tricket at compile det til en Xeon), men mere et spg om at AMD åbenbart har lavet en mere effektiv implementation af SSE2 end intel. Da compileren vel bare laver en SSE2 optimeret binary når den køres på en Xeon maskine.
Nu er det vel ikke så meget et tegn på at intels compiler lige laver mere effektive binaries til opteron (så vidt jeg har forstået var tricket at compile det til en Xeon), men mere et spg om at AMD åbenbart har lavet en mere effektiv implementation af SSE2 end intel. Da compileren vel bare laver en SSE2 optimeret binary når den køres på en Xeon maskine.
#5 nu er SSE2 delen jo ikke noget der skal laves optimeret specielt til en opteron CPU, men en standard som en Opteron og Xeon og P4 CPU understøtter. Og da intel lavede SSE2 standarden er de naturligt nok også dem der har lavet den mest effektive compiler.
Intels C++ compiler er jo også noget af det mest effektive mht x86 (mener det var noget med en 30-40 % nogen målte sig frem til i forhold til gcc).
Intels C++ compiler er jo også noget af det mest effektive mht x86 (mener det var noget med en 30-40 % nogen målte sig frem til i forhold til gcc).
#7
meget rimeligt, men når det nu er en "åben" standard som AMD har implementeret i deres eget design, vil jeg stadig mene at der må være talrige muligheder for selv at bygge compilere specialiceret til ens eget produkt. Selvfølgelig kræver dette at man bruger resourcer tilsvarende Intels på udvikling, men er dette ikke også hvad man burde forvente af en producent som reelt har et bedre produkt. (hvis man ser megaflops pr. mhz. - vi gider ikke til at starte hele fordomsævlet igen)
meget rimeligt, men når det nu er en "åben" standard som AMD har implementeret i deres eget design, vil jeg stadig mene at der må være talrige muligheder for selv at bygge compilere specialiceret til ens eget produkt. Selvfølgelig kræver dette at man bruger resourcer tilsvarende Intels på udvikling, men er dette ikke også hvad man burde forvente af en producent som reelt har et bedre produkt. (hvis man ser megaflops pr. mhz. - vi gider ikke til at starte hele fordomsævlet igen)
#7
en compiler oversætter kode til maskine kode. dette er instruktioner som cpu'en forstår. disse er ens inden for x86 standarden, men der er stor forskel mellem de forskellige arkitekturer hvordan de er implementeret, og mere vigtigt, hvor hurtige de er. Feks kunne en x86 instruction på en Intel P4 tage 3 clock cycles og samme instruction på en AMD kunne tage 2 clock cycles eller måske 4 eller 5.
Af denne simple grund kan man med fordel lave compilere til specifike cpu'er også selv om de understøtter en SSE2 standard.
Måske er AMD's implementation hurtigere end intels, men det betyder ikke at en AMD optimeret compiler ikke ville kunne gøre det bedre end en Intel. Den ville måske oversætte noget kode til nogle andre instructioner (microkode) der tilsammen laver det samme men er endnu hurtigere end Intel optimeret kode.
Så al magt til AMD optimeret compilers. Self. kunne begge dele bygges ind i samme compiler og man kunne vælge at få en exe fil ud der er optimeret til begge dele. Den vil så selv check hvad cpu man har og tage den rigtige kode brance.
Jeg ved ikke om dette giver mening men jeg har prøvet så godt jeg kan ;)
en compiler oversætter kode til maskine kode. dette er instruktioner som cpu'en forstår. disse er ens inden for x86 standarden, men der er stor forskel mellem de forskellige arkitekturer hvordan de er implementeret, og mere vigtigt, hvor hurtige de er. Feks kunne en x86 instruction på en Intel P4 tage 3 clock cycles og samme instruction på en AMD kunne tage 2 clock cycles eller måske 4 eller 5.
Af denne simple grund kan man med fordel lave compilere til specifike cpu'er også selv om de understøtter en SSE2 standard.
Måske er AMD's implementation hurtigere end intels, men det betyder ikke at en AMD optimeret compiler ikke ville kunne gøre det bedre end en Intel. Den ville måske oversætte noget kode til nogle andre instructioner (microkode) der tilsammen laver det samme men er endnu hurtigere end Intel optimeret kode.
Så al magt til AMD optimeret compilers. Self. kunne begge dele bygges ind i samme compiler og man kunne vælge at få en exe fil ud der er optimeret til begge dele. Den vil så selv check hvad cpu man har og tage den rigtige kode brance.
Jeg ved ikke om dette giver mening men jeg har prøvet så godt jeg kan ;)
#10, ja og tydeligvis er AMD's Implementation af lige netop SSE2 delen (drejer sig så vidt jeg husker ikke om mere end nogen få instruktioner) bedre end Intels.
At AMD så godt kunne forventes at lave en optimeret compiler til lige netop deres version af x86 er korrekt.
Men Intels compiler var vidst også mere effektiv uden at tage i betragtning hvilke instruktioner der måske eksekveres hurtigere som maskinkode.
GCC til m68K har f.eks iirc en tendens til at flytte indholdet af flere registre end der faktisk bliver brugt på stacken ved funktionskald. Hvis man antager noget tilsvarende er tilfældet på x86 er der jo rigeligt plads til optimering bare ved at fjerne nogen af disse overflødige instruktioner. Det kræver selvfølgeligt at compileren er lavet godt intelligent nok (til netop den platform), til at holde styr på hvad der bliver brugt af registre konstant.
At AMD så godt kunne forventes at lave en optimeret compiler til lige netop deres version af x86 er korrekt.
Men Intels compiler var vidst også mere effektiv uden at tage i betragtning hvilke instruktioner der måske eksekveres hurtigere som maskinkode.
GCC til m68K har f.eks iirc en tendens til at flytte indholdet af flere registre end der faktisk bliver brugt på stacken ved funktionskald. Hvis man antager noget tilsvarende er tilfældet på x86 er der jo rigeligt plads til optimering bare ved at fjerne nogen af disse overflødige instruktioner. Det kræver selvfølgeligt at compileren er lavet godt intelligent nok (til netop den platform), til at holde styr på hvad der bliver brugt af registre konstant.
Hvorfor skulle amd nogensinde lave deres egen compiler - ville det ikke være langt mere nyttigt at lave nogle patches til gcc?
Dybest set kan jeg sagtens forstå at de slet ikke laver en - de nøjes med at gøre det de er gode til - ikke en skidt ide i øjeblikket...
Dybest set kan jeg sagtens forstå at de slet ikke laver en - de nøjes med at gøre det de er gode til - ikke en skidt ide i øjeblikket...
#13 Hektor
Nej det ville nok ikke passe MS alt for godt.. ;oD
Men umildbart giver både Intel og AMD glimrende informationer til fri software udviklerne.
Så den vil nok hurtigt blive taget ind i varmen.. :)
Og der er jo grundet den uheldige facon BSD licensen er skrevet på, ingen hindringer i af MS nuper lidt af deres kompiler hvis de skulle få lyst til det.
Nej det ville nok ikke passe MS alt for godt.. ;oD
Men umildbart giver både Intel og AMD glimrende informationer til fri software udviklerne.
Så den vil nok hurtigt blive taget ind i varmen.. :)
Og der er jo grundet den uheldige facon BSD licensen er skrevet på, ingen hindringer i af MS nuper lidt af deres kompiler hvis de skulle få lyst til det.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund