Intel-compilers zorgen voor topprestaties Opteron

The Inquirer meldt dat voor het compileren van code voor AMD's Opteron het beste gaat met de compilers van Intel. Deze zijn namelijk erg goed in het optimaliseren van code voor het x86-platform. Deze geoptimaliseerde code is wat de Opteron nodig heeft in de strijd tegen Intel's Xeon en daarvoor wordt alles uit de kast gehaald. Zo heeft de Opteron SSE2-ondersteuning, maar om code te compileren die gebruik maakt van de SSE2-instructies met de compilers van Intel, is een Xeon-machine nodig. De code die door de Xeon-machine wordt gemaakt, werkt vervolgens prima op een Opteron-systeem. De prestaties van de Opteron op het gebied van Symmetric Multiprocessing (SMP) zijn ook uitstekend. De prestatiewinst van twee Xeon's ten opzichte van één Xeon is in bepaalde benchmarks ongeveer dertig procent. Bij de Opteron is deze prestatiewinst in dezelfde benchmarks tachtig procent.

Reacties (64)

[Xellence]

Waar ik me al een paar jaar me hoofd over breek is dat AMD zelf helemaal niet met compilers is op komen draven. Het lijkt me erg voor de hand liggen dat ze zelf toch wel weten hoe een compiler voor hun CPU de best mogelijke binairy code weet te fabriceren. En dat de intel compilers zo goed x86 code weten te optimaliseren is niets nieuws. Daar staan ze al jaren bekend om.

Frappant is wel te noemen dat de compilatie persé op een Xeon moet plaats vinden. Als ik een compiler schijf op het Alpha platform die als taak heeft x86 code te compileren, zal die gewoon x86 code fabriceren die niet op de Alpha uit te voeren is maar wel op x86.

[voodooless]

Dit is niet helemaal waar. Ze hebben dan we geen eigen compiler, maar hebben een grote steen bijgedragen aan het porten van gcc naar hun x86-64 platvorm.

De Intel compiler maakt alleen nog maar 32 bit code, voor de 64 bit code zal toch gcc of een M$ compiler nodig zijn.

Ik ben erg benieuwd naar de prestaties van de komende gcc versie 3.3, deze heeft namelijk een soort beschrijvingstaal voor de pipelines in de processor om deze zo optimaal te kunnen vullen.

[RIP-airco]

compilers maken is een vak op zich ....
een bedrijf dat de kennis in huis heeft om CPU's te maken heeft vaak niet de uitmuntende programmeurs die tot op systeemtaal de machine kunnen aanspreken.

[wica]

Omdat een goede bug vrije compileren moeilijk te maken is. En jaren en jaren duurt

/edit
tijd = geld. Toch?

[packman]

Correctie - een bugvrije zwaar geoptimaliseerde compiler maken is heel moeilijk.

Intel heeft een enorme compiler optimalisatie know-how in huis, en levert al een heel aantal jaren de beste compilers af voor fortran en C(++). Dat is iets waar miljoenen $$$ insteekt - en iets dat er niet zomaar opeens staat - daar is een zware investering en ontwikkeling aan voorafgegaan...

[packman]

@GP500:

De Intel compilers zijn helemaal niet gratis, Borland deelt deze ook niet zomaar uit Sommige CPU makers (dedicated dan - zoals Hitachi) geven wel compilers gratis weg om hun chips te promoten - maar met de know-how en ontwikkelingen die er bij Intel achter steken kan Intel zich het absoluut niet permitteren dit gratis weg te geven.

GCC is wel gratis - maar het is pas sinds GCC 3.1 dat deze min of meer acceptabele geoptimaliseerde code kan genereren. De Intel compiler genereert dan nog in vele gevallen code die tot 20% sneller is op dezelfde cpu. Compileroptimalisaties zijn een van de moeilijkste dingen die er zijn om te begrijpen en te implementeren (ik ben net zelf aan een compilerprojectje bezig - en optimalisatie wil niet echt lukken )

[BoomSmurf]

Borland deelt z'n C++ compiler wel degelijk gratis uit! De IDE zelf alleen niet!

[thunderbird2k]

De IDE geven ze ook gratis weg. Voor vrijwel al hun paketten geven ze de standaardversies weg mits je registreert.

[Verwijderd]

AMD zal wel licenties betalen voor de x86 architectuur en op die manier meebetalen.

[gp500]

Te bedenken dat, denk dat compilers gratis zijn, AMD daar zo even gratis van kan profiteren.

[Aetje]

Dat zal dus nu afgelopen zijn vrees ik...

[Verwijderd]

"Frappant is wel te noemen dat de compilatie persé op een Xeon moet plaats vinden. Als ik een compiler schijf op het Alpha platform die als taak heeft x86 code te compileren, zal die gewoon x86 code fabriceren die niet op de Alpha uit te voeren is maar wel op x86"

Wat jij zegt is toch net het zelfde als in de posting geschreven wordt: De compiler van intel draait alleen op een Xeon en heeft de taak x86-64 code te compileren en die code draait daarna perfect op x86-64 machines.

Het verschil is de de Xeon zelf ook een x86-64 processor is, maar dit kan ik best begrijpen. MS zorgt er toch ook voor dat hun office pakket alleen op hun OS werkt. (Een ver gezochte vergelijking ik weet het maar het komt wel op het zelfde neer)

[packman]

Een Xeon is helemaal geen x86-64 CPU - intel heeft (officieel) geen x86-64 cpu. Een Xeon is gewoon een opgewaardeerde en gereviseerde P4 met een paar optimalisaties voor servers, multiprocessorcapaciteiten en eventueel meer cache.

[boesOne]

Het verschil is de de Xeon zelf ook een x86-64 processor is, maar dit kan ik best begrijpen. MS zorgt er toch ook voor dat hun office pakket alleen op hun OS werkt. (Een ver gezochte vergelijking ik weet het maar het komt wel op het zelfde neer)

Totale onzin.
De Xeon is gewoon een 32 bitter hoor. Het artikel gaat dus alleen over 32 bit x86 code. Wat de compiler dus waarschijnlijk goed doet is code voor HTT/Dual systemen uitspugen en voor SSE2 optimaliseren.

[memphis]

Waarom zouden ze, de Intel compilers doen het prima

[C00P]

Waarom moet code gecompileerd worden ?

Ik lees elke dag tweakers.net en vooral het AMD nieuws, maar dit snap ik ff niet...

[Verwijderd]

Het simpele antwoord is, omdat de taal die de CPU "spreekt", niet dezelfde is als die waarin geprogrammeerd wordt. Als je code niet zou compileren zou de CPU dus of commando's van alle programmeertalen moeten kunnen begrijpen, of de code moet vlak voor het runnen alsnog gecompiled worden (JIT compiler, alle scripttalen werken zo).

Het was trouwens ook wel te verwachten dat de Intel compiler de beste was, die is immers ook geoptimaliseerd voor de Intel x86-CPU's waarvan AMD de SSE(2) instructies mag gebruiken. Wat ik me trouwens wel afvraag is of Intel ook de Optimalisaties voor 3DNow! (Pro) heeft doorgevoerd in hun compilers

EDIT : net ff bij Intel gekeken, en daar wordt helemaal niks gezegd over dat er een Xeon nodig zou zijn om te compilen, SSE2 instructies worden ook niet apart vermeld ofzo.

@ RuuddieBoy : Op zich zou dat wel mogelijk zijn, maar volgens mij zou de die-size van een die processor dan een heel stuk groter zijn dan die van de huidige CPU's. Ook zou bij elke herziening van een programmeertaal de CPU iets aangepast moeten worden.

[Ruuddie]

Waarom maken ze dan geen CPU die gewoon een paar mainstream programmeertalen ondersteunt, zoals Java, C++, en dat soort dingen.
Dat scheelt een hele hoop ontwikkeltijd, omdat dat soort programmeer talen veel worden gebruikt, en dus niet meer gecompiled hoeven te worden.
De programmeertaal waarin Windows is geschreven mogen ze van mij dan ook wel laten ondersteunen

[boesOne]

Omdat je door de instructies op de cpu zo simpel mogelijk te houden je veel snelheid wint. Je kan met behulp van veel simpele instructies, die razendsnel uitgevoerd kunnen worden, ingewikkelde commando's bouwen.
Ook hou je de cpu flexibel. Ontwikkelt iemand nog eens een geniale programmeertaal dan hoef je alleen maar een compiler te bouwen voor je cpu ipv een nieuwe cpu te maken. Dus ik vraag me af of het wel ontwikkeltijd scheelt.

Nou is de x86 al een relatief uitgebreide intructieset geworden in de loop der tijden. Het kan allemaal nog kaler: de zgn RISC instructie sets. Die kunnen bijna helmaal niks, maar zijn ontzettend snel.

[RetepV]

Er zijn overigens wel processoren ontwikkeld die direkt een hogere programmeertaal kunnen uitvoeren. Ik meen voor de volgende programmeertalen:

- Lisp
- Forth (mwo, 'hogere' programmeertaal... )
- Pascal
- Java (duh )

Ze zijn nooit een success geworden, zelfs die Java processor niet. Hoewel er wel een markt lijkt te zijn voor processoren die Java kunnen *versnellen*. Die dus niet direkt Java code uitvoeren, maar net als een coprocessor ondersteunende functies leveren zodat een gewone processor de Java code sneller kan uitvoeren.

Maar verder is het bij mij een klok<->klepel verhaal, dus misschien kan iemand anders nog aanvullen .

[voodooless]

Dit is een kulverhaal! Er zit namelijk altijd een interpreter of VM tussen.
BV In het geval van een java processor, kan deze processor de java bytecode rechtstreeks uitvoeren, echter niet de java source direct. compileren is dus altijd nog nodig.

Dit geld ook voor de anderen in het rijtje.

[RetepV]

Hmm, kulverhaal is een beetje een groot woord.

Er wordt niets gecompiled, er wordt alleen van een tekstrepresentatie naar een bytecode representatie omgezet. Dat is niet meer dan 'tokenizen'.

Maar goed, inderdaad kun je niet direkt de textueele vorm van de sourcecode uitvoeren. Beroepsdeformatie, textueele vorm of tokenized vorm van een programma is voor mij hetzelfde. De eerste is alleen een stuk makkelijker te lezen .

Vergelijk het met assembly. Een assembler is geen compiler, toch zet het de textueele representatie van de binaire code om in de eigenlijke binaire code.

Een compiler doet nog veel en veel meer dan alleen omzetten.

In jouw verhaal is de 'interpreter' juist de processor, terwijl wat jij 'compiler' noemt de tokenizer is die van de text bytecode maakt die dan door de processor geinterpreteerd wordt.

Net zoals in die oude basics. Elke regel die jij intikt wordt getokenized in het geheugen gezet. Vervolgens gaat de Basic virtual machine de code uitvoeren. Daar zit niet nog eens een compiler tussen.

[Verwijderd]

@RetepV

Hmm, kulverhaal is een beetje een groot woord.

Er wordt niets gecompiled, er wordt alleen van een tekstrepresentatie naar een bytecode representatie omgezet. Dat is niet meer dan 'tokenizen'.

Man, lul niet zo slap!

Tokenizen is van de source code een stream van tokens maken, dwz de comments en white space weg strippen.

Bytecode is echter gewoon een assembly taal. Ziet er bijna net zo uit als assembly talen voor hardware CPU's. Het is 'iets' meer highlevel, maar niet meer dan iets. Bytecode kan dus absoluut niet gegenereerd worden door Java source ff te tokenizen, jij grote grapjas!

Aanvullend; Je kunt ook andere talen naar bytecode compileren en dus op de Sun 'java' VM laten draaien. Lees eens wat documenten over de Java VM en/of Java architectuur zou ik zeggen.

[voodooless]

Dat is precies wat ik bedoel

[Verwijderd]

Niet helemaal, de meeste scripting talen worden gewoon geinterpreteerd niet gecompileerd - ook niet ge-just-in-time-compileerd (of hoe je een dergelijk werkwoord ook zou vervoegen)

[H!GHGuY]

om een supersimpel voorbeeldje te geven van 'code':

#include <iostream.h>
void main(void) {
cout<<"hallo!";
}

dit simpel dingetje zet (als ik geen fouten maak) simpelweg hallo! op je scherm.

maar omdat een processor dit niet kan verwerken, moet deze code gecompileerd worden.

er bestaan 2 soorten van compilen:
native compilen: bvb IA-64 code maken op een IA64-computer. het programma draait dus op hetzelfde type processor als de computer waarop het gecompiled is
cross compilen: bvb x86-64 coder maken op een IA64 computer. deze software zal niet draaien op een IA-64 computer(waarop hij gemaakt is), maar wel op een x86-64 computer.

als proef: zoek een .exe bestand en kopieer het in een directory, en open het met kladblok of iets dergelijks, dan zie je wat de computer leest.

[RetepV]

Dat simpele programma'tje zet iets als het volgende op je scherm:

Error: Redefinition of function 'main' in line 2.
main is defined as 'int main( char *argv[], int argc )'.



Als je compiler het niet op je scherm zet heb je de Eerste Wet des Programmeurs overtreden, namelijk: zet de warning en errorlevels op het hoogste dat ze kunnen .

[KatirZan]

Als je compiler het niet op je scherm zet heb je de Eerste Wet des Programmeurs overtreden, namelijk: zet de warning en errorlevels op het hoogste dat ze kunnen

Hmm, niet altijd nodig, sommige errorlevels zijn gewoon niet vervangbaar (de zogenaamde bugs)
daarom zitten er altijd fouten in programmeertaal.

Probeer jij maar eens een proggie te schrijven in binary code

[RetepV]

In theorie niet altijd nodig, maar in de praktijk wel heel erg slim.

Het is beter om alle warnings en errors op maximum te zetten en in de code zelf met #pragma (of iets anders) warnings en errors lokaal uit te zetten. Dan krijg je net zo goed geen ellenlange lijst van onzinnige errors en warnings, maar weet je wel zeker dat je van alle errors en warnings gechecked hebt of ze zinnig of onzinnig waren. Zo slipt er niet per ongeluk een zinnige error die op een onzinnige error lijkt tussendoor.

Het kost je inderdaad wat werk ja, maar als je het direkt bij het begin van je programmeren doet, dan heb je er al gauw voordeel uit.

Je vangt er inderdaad geen denkfouten mee af, maar dat is het doel ook niet. Denkfouten kun je alleen maar afvangen door alles driedubbel te controleren en heel veel van de ASSERT() macro gebruik te maken.

En proggies in binairy code schrijven heb ik echt wel gedaan hoor . Op de 6802, de Z80, de 6502. Goed, het was hex, maar binairy en hex zijn alleen maar andere representaties van hetzelfde

Lees eens het boek 'Writing Solid Code', het is van Microsoft Press. Een erg goed boek.

Oh ja, ik heb het hier voornamelijk over C en C++, maar deze algemene regeltjes gelden denk ik wel voor alle gecompileerde talen en ook voor een groot deel van de geinterpreteerde talen.

[JoostBaksteen]

Normaal heb je de source code, dat is tekst die mensen begrijpen, maar je processor kent alleen 0/1, een compiler zet de tekst om naar een binair bestand wat je computer kan draaien.. exe bestanden

[boesOne]

Code is een stukje tekst dat voldoet aan de syntax van een programmeertaal. Iets als :
10 print "Opteron is lekker sneller dan Xeon"
20 goto 10
Die tekst haal je door een programma die die tekst omzet in instructies voor een cpu, machinetaal. Zo'n programma heet een compiler.
Sommige compilers doen die omzetting speciaal op een slimme manier toegespitst op een bepaalde cpu. Nu is het wel ontzettend lollig dat de compiler voor de Xeon het zo lekker doet voor de opteron.
Blijkbaar kan intel goeie compilers schrijven..

[Verwijderd]

Omdat rauwe code niet uitvoerbaar is en gecompileerde code wel

[MBV]

Je programma zal je tegenwoordig bijna altijd schrijven in een hogere generatie taal als C/C++/Java. Dit kan de processor alleen niet begrijpen: Die kent geen if-then-else o.i.d., alleen optellen. Een compiler zet zo'n hogere taal om naar een taal die de processor wel begrijpt.

Dit is een heel eenvoudige weergave, als je meer wilt weten moet je je echt verdiepen in programmeren

edit:
wie krijgt de dubbelpost?

[Raziel]

Omdat een CPU alleen in ééntjes en nulletjes denkt en niet in C++, Pascal en dat soort zooi

[MPAnnihilator]

Als AMD fan vraag ik mij in feite nu wel af waarom AMD nog zelf geen eigen compiler maakt. Ze zijn nu eens innovatief vind ik met de Opteron, en Intel lijkt dezelfde richting uit te gaan, maar het ontbreken van hun eigen compiler vind ik toch wel erg.
Als je de code kon bemachtigen en hercompileren (met de intel compiler) van sommige software op je eigen ahtlon, zag je soms ook al een boost van enkele procenten, soms spectaculair. De Opteron kan dit denk ik dus blijkbaar ook wel gebruiken, deze extra boost.

Wat is het nu AMD , niet willen , geen geld , of geen bekwame programmeurs hiervoor ?

[delyver]

Zoals ook hierboven al vermeld is, kost het maken van een Goede, stabiele, snelle compiler.. ten eerste een hele hoop met geld, Ten tweede heb je mensen nodig die het kunnen en technische kennis hebben. Ten derde bouw je niet zo 123 een stabiele compiler. Dat duurt jaren

Daar komt nog eens bij dat AMD al een tijdje op de kosten reductie toer is, dus ik denk niet dat AMD komt met een eigen geoptimaliseerde compiler.

[SG]

Oorspronkelijk is een compiler een software side aspect en is de core onderdeel van een software ontwikkelings app

Compilers worden dus geleverd door derden.

Microsoft en linux
GCC
MS Visual Studio

Maar aangezien iNtel graag innovatief is en dat is vaak optimalisatie dus compiler afhankelijk bied intel hier dus sterk msupport voor door 'n plugin compiller die de MS compiler vervangt.

De innovatieve of totaal hernieuwde core en instructie extensies deden het erg slecht op oude code dus voor iNtel een noodzaak.

AMD core die nogal op erg conservatieve classieke wijze ontworpen zijn en dus oude code veel beter verwerken zijn niet zo compiler afhankelijk maar profiteren er ook van maar in mindere mate en door intel CPU detectie soms helemaal niet.

Denk dat 'n third party Compiler, dus niet van iNtel, de AMD CPU wel Optimaliseerd alleen is iNtel op een hogere optimalisatie niveau dan de anderen dus niet o efficient maar wel merkbaar.

Voor x86-64 is AMD afhankelijk van de MS en linux compilers.

[packman]

Het enige spijtige is natuurlijk dat de Intel compiler nooit de 64bit registers zal gebruiken
Dat zou nog voor een performanceboost kunnen zorgen door het gebruik de extra registers die de Opteron heeft te optimaliseren...

[StefanTs]

zou intel niet met x86-64 komen, op de presctoor of diens opvolger?
tenminste ze hadden dr een hele theorie over, stond ook op tweakers

[hardwareaddict]

Een beetje een subjectief geschreven titel. We kunnen ook neerschrijven: "microsoft compiler maakt opteron sneller". Het is uiteindelijk de opteron die het hem doet. De intel c++ compiler maakt gebruik van SSE2 die dus erg snel loopt op de opteron en niet op de K7.

Het is duidelijk dat AMD al jaren geleden had moeten beginnen met het schrijven van een eigen compiler. De bijdrage aan de gcc compiler is toch vrij minimaal gebleken als ik kijk naar de snelheidsverschillen intel c++ versus AMD.

Die intel c++ compiler wordt overgewaardeerd overigens. In belangrijke software valt deze niet te gebruiken omdat de intel c++ compiler erg buggevoelig is. Dit door de manier waarop de compiler is designed en de QAT die alleen gefocussed is op specint/specfpu en de rest telt veel minder zwaar mee.

Belangrijke software kan ik niet met intel c++ compileren omdat hij bugs veroorzaakt. Van intel c++ lieden krijg ik dan een grote mond terug als ik een bug laat zien, terwijl ik niet betaald word om bugs in hun software te vinden.

De intel c++ compiler kortom kan ik niet aanraden om je software mee te compileren. Het ding is berucht om de lossy resultaten die het produceert. Als wetenschappers byte voor byte resultaten vergelijken die de verschillende compilers produceren, dan valt de intel c++ buiten de boot. Wel doet hij het goed als je debug code aanzet, maar dan is de code dus beretraag.

Het is duidelijk dat de manier waarop de compiler de optimalisaties toepast, lastig te debuggen is.

Dit neemt niet weg dat door die compiler de P4 nog heel wat meer lijkt als het ding al is.

AMD heeft duidelijk een verkeerd pad daar bewandeld. Het succes van de opteron is natuurlijk vele factoren groter als er een goede 64 bits compiler voor uitkomt.

We weten dat er een berg beta 64 bits versies van de verschillende compilers zijn die werken voor opteron. Tot die released zijn (dat kost soms heel lang) lijkt het pad dat intel bewandelt veel slimmer.

Nu te claimen dat de opteron met de intel compiler heel snel is, is eigenlijk de duidelijkste bevestiging van het feit dat AMD dus tekort is geschoten in het ontwikkelen van een 64 bits compiler. Op zich is dat een heel triest gegeven.

[FiRePaTH]

Volgens mij klopt er echt iets niet aan dit nieuws! Sinds wanneer heeft een Xeon INTERNE code optimizers die de code voor ene Opteron optimizen? Volgens mij is een optimizer gewoon een stukje software dat door iedere cpu gemaakt kan worden hoor!

[SG]

Ja dat was ook al zo met SSE en nu dus ook met SSE2

De iNtel Compiler checkt op MERK en Type CPU

dus
if Intel then
{
if (check for SSE) then SSE = True
if (check for SSE2) then SSE2 = True
}
Else Default

Dus alles van ander merk met SSE(2) wordt gewoon niet ondersteund en behandeld als een oude Pentium II

AMD is dus afhankelijk van linux en MS compilers

aangezien intel natuurlijk geen x86-64 compiler gaat maken tenzij ze zelf met 'n aMD 64 compatible komen.

dit trukje gaat alleen op voor IA32

[Jack Flushell]

Ik snap het ook niet..... I'm confused... Want inderdeed, het is toch gewoon softwarematig optimizen?

[wica]

Waarschijnlijk bedoelen ze dat de Intel-compiler en Xeon goed overweg kunnen met SSE2-instructies.

aan gezien de Xeon een Intel cpu us zal de compiler daar ook voor gemaakt zijn.

Denk dat ze een stukje code in de compiler hebben zoals:
if ( cpu = "Xeon" ) #include "sse2"

[RetepV]

Mag ik vragen waar jullie het woordje 'interne' gelezen hebben?

In het bericht staat gewoon dat de Intel compiler de Opteron niet herkent als een processor met SSE2 en daarom geen SSE2 code wil maken.

Een ander alternatief is de check uit de compiler hacken, maar dan is compilen op een XEON machine toch echt makkelijker.

Goed, dan blijft nog de vraag waarom de Intel compiler geen commandline vlaggetje heeft om SSE2 te forceren, maar alla, misschien een overijverige compilerbouwer geweest.

[Madrox]

Sorry hoor, maar je maakt een foutje ofzo. CPU's maken geen software, dat doen mensen. Optimaliseren doen compilers, gemaakt door mensen. Kheb nog nooit een CPU gezien die dingen "maakt"

[C00P]

De prestatiewinst van twee Xeon's ten opzichte van één Xeon is 30 procent. Bij de Opteron is deze prestatiewinst maar liefst 80 procent!

En als men 3 Opterons gebruikt ? ik vind dat wel een moie prestatie van AMD !
Wat zouden de resultaten zijn als men 8 opterons in cluster zet, houdt hij toch een ItaniumII bij ? en is nog goedkoper ook denk ik ?
Of sla ik de bal hier volledig mis ?

[Jorik]

Stel je met opzet allemaal domme vragen onder deze nieuwsposting?

[Ruudjah]

Domme vragen bestaan niet, alleen domme antwoorden, zoals joouw post wel weer bewijst

[RetepV]

En dat is dus weer een dom antwoord, want geef dan gelijk antwoord op COOP's vraag .

Het antwoord is dat je zo'n prestatiewinst niet zomaar lineair door kan trekken naar meer processoren. Helemaal afhankelijk van de applicatie kan het zelfs zijn dat 3 processoren *langzamer* worden dan 2 processoren en misschien zelfs langzamer dan 1 processor! De processoren moeten namelijk regelmatig op elkaar wachten.

Zie het als een loket. Als de loketmedewerkers regelmatig dingen aan elkaar moeten vragen, gaat het bij 2 loketmedewerkers nog wel snel: ze kunnen elkaars vragen direkt beantwoorden. Bij 3 loketmedewerkers kan het al zijn dat 2 loketmedewerkers bij elkaar iets aan het vragen zijn. Ze doen op dat moment niets wat het werk versnelt. De 3e loketmedewerker is nog zuurder, want die kan niets doen EN moet nog eens wachten tot de beide loketmedewerkers klaar zijn met elkaar beantwoorden. Vervolgens zal de 3e loketmedewerker aan 1 van de 2 andere zijn vraag stellen, en is er van die 2 andere dus maar 1 die verder kan met zijn werk. Als 1 loketmedewerker alleen maar vragen van anderen aan het beantwoorden is, komt die ene dus nooit aan zijn eigen werk toe. De andere 2 komen minder aan hun werk toe dan anders omdat ze af en toe moeten wachten op die ene. En dus kan het totaal aan werk dat gedaan wordt wel eens minder zijn dan als er maar 2 loketmedewerkers waren geweest.

Snap-ez vous?

edit:

Fijn dat mijn verhaal mee wordt weggemod met het antwoord van Ruudjah...

[Kevinp]

dat licht toch meer aan de chipset lijkt mij. die regeld het verkeer van en naar de processor. of zit ik hier helemaal fout.

[Kheldar]

Ja .

De Opterons hebben geen chipset meer die dat doet, ze hebben de hypertransport- en geheugencontroller gewoon aan boord .

[RetepV]

Intel's compiler maakt code voor Windows ook al een stuk sneller dan Microsoft's compiler.

Bij Intel kunnen ze prima compilers schrijven...

[blobber]

Kunnen ze die Intel compiler niet dissassemblen en dan gaan cross-compilen zodat hij ook op de opteron werkt, dan gaat het compileren ook weer sneller en heb je de xeon niet meer nodig ,of gaat het niet zo makkelijk (iig mag het niet van intel neem ik aan )

[sonix666]

De Inquirer moet eerst eens leren programmeren!!! Ik heb nog nooit meegemaakt dat een compiler niet voor een bepaalde target (P3, P4, Itanium, etc.) compileert omdat je niet die bepaalde machine heeft. Je kunt SSE2 geoptimaliseerde binaries compileren op een P3, maar dan kun je ze niet op die P3 runnen.

Het zoveelste nonsense verhaal op de Inquirer.