Dual-core Itanium Montecito zuiniger dan huidige versies

Op PC Watch Japan is een hoop nieuwe informatie verschenen over Montecito, een nieuwe versie van de Itanium-processor die Intel in de tweede helft van 2005 zal introduceren. Deze specificaties zijn oorspronkelijk afkomstig van HotChips 16, een conferentie waarop Intel eind augustus een presentatie over de chip heeft gegeven. Het meest opvallende nieuwe feit is dat de TDP van de bijna twee miljard transistors tellende chip op 100 Watt is vastgesteld, 30 Watt láger dan dat van de huidige Madison-serie. Dit terwijl de kloksnelheid van de Itanium niet alleen verhoogd wordt van 2,0 naar 2,5GHz, maar er ook nog eens een hele tweede core aan de chip wordt toegevoegd. De overstap van 130nm- naar 90nm-productie werpt voor Itanium dus duidelijk meer vruchten af dan voor de Pentium 4.

De basis van Montecito is een derdegeneratie Itanium-core. Qua executie-eenheden is deze identiek aan de tweede generatie, maar de cachestructuur is drastisch verbeterd en er zijn enkele belangrijke nieuwe features toegevoegd, deels voor extra prestaties en deels voor meer betrouwbaarheid. De meest opvallende verandering qua cache is het splitsen van de L2-cache in aparte stukken voor data (256KB) en instructies (1MB). De meeste moderne processors maken dit onderscheid wel op L1, maar hebben op L2 een gemixt (unified) cache zitten. Het splitsen maakt het makkelijker om lage latencies te halen en biedt bovendien een performancevoordeel: data kan code niet meer het cache uit duwen en andersom.

Verder is de L1-instructiecache vergroot van 16 naar 18KB. De reden hiervoor is niet geheel duidelijk, maar mogelijk gaat het om extra ruimte voor de branch predictor of Coarse-grained MultiThreading. CMT is de techniek waarmee vier threads op de dual-core chip kunnen draaien. Niet geheel tegelijkertijd zoals bij SMT (HyperThreading) gebeurt, maar meer om de beurt; terwijl de ene thread op data uit het geheugen wacht kunnen bijvoorbeeld instructies voor de andere thread uitgevoerd worden. CMT is dus wel wat minder geavanceerd dan SMT, maar blijft nog steeds vele malen sneller dan het uitvoeren van dezelfde truc via software. Verder is er een L3-cache van 12MB en worden er nog drie nieuwe technieken geïntroduceerd. Foxton zorgt voor het dynamisch over- en onderklokken van de chip, voor betere prestaties en meer zuinigheid. Pelston beschermt de processor tegen cachefouten en Silvervale verbetert de ondersteuning voor virtual machines.

Klik voor vergroting

Het schema toont een tweetal van de hierboven beschreven cores die aan elkaar en de bus gekoppeld zijn middels een arbiter: de architectuur van de Montecito. Hoe het aanbod van de goedkopere Millington-chips eruit komt te zien is nog niet duidelijk, maar het is niet meer dan logisch dat er versies met slechts één core en een kleiner L3-cache geleverd zullen worden. In het schema valt overigens op dat er geen x86-eenheid meer wordt getoond. De huidige Itaniums hebben stuk voor stuk een hele berg extra transistors om backwards compatible te blijven, maar IA-32EL heeft dat eigenlijk overbodig gemaakt. Het is echter niet zeker of de x86-hardware écht gedumpt is, het zou namelijk ook gewoon uit de presentatie gelaten kunnen zijn om het diagram niet ingewikkelder te maken dan het al is.

Reacties (46)

[Verwijderd]

Boeiend! Maar eigenlijk vind ik het jammer dat men voor het multi-core concept echt letterlijk complete "stand-alone" cores gaat gebruiken. Volgens mij kun je beter alleen de intensiever gebruikte onderdelen van een single core multiplexen. Dus niet twee complete cores, maar gewoon een single core met daar aan vast een aantal parallel uitgevoerde delen van een single core. De FPU bijvoorbeeld kennen we allemaal, maar er zijn vast meerdere afzonderlijke - parallel uitvoerbare - coredelen te identificeren.

Dus niet 1 + 1=2, maar 1+ 5*1A + 10*1B + ?*? + enz. Dan maak je volgens mij efficienter gebruik van je wafertje.

Om software ervan te laten profiteren moet daar dan wel meer aan veranderd worden natuurlijk, maar ik vind sowieso dat alle software dat in principe parallel uitgevoerd kan worden daar ook inherent geschikt voor gemaakt zou moeten worden.

[Luxx]

Natuurlijk is het bijzonder efficient om je huidige core te verbeteren om hem efficienter te laten werken. Alleen blijf je dan wel vast zitten een een maximum. Als je daarnaast het aantal cores ook kan verhogen, win je dus nog meer prestatie.
Het begin van multi-core processoren is eigenlijk alleen een teken dat het niet zo makkelijk meer is om op andere manieren nog 'snel' winst te boeken. Door de enorme concurrentie op de processor markt is het dus noodzakelijk om wel steeds sneller te blijven gaan, dus dan is dit de meest voor de hand liggende oplossing.
Natuurlijk kan je je hele core omgooien en alles optimaliseren, maar daar zit enorme R&D kosten aan vast, terwijl het toevoegen van een 2e core relatief "simpel" is en nog belangrijker het is ontwerpen, maken en testen van een nieuwe core die "delen" van 2 losse cores samenvoegt tot een samenhangend deel en ook nog eens echt sneller is, duurt gewoon te lang.

[Wouter Tinus]

Software is de grote beperkende factor. IA-64 werkt met bundels van drie instructies, Itaniums kunnen twee van die bundels tegelijk uitvoeren. Het is de taak van geavanceerde compilers om ervoor te zorgen dat er zoveel mogelijk gebruikgemaakt wordt van die zes plaatsen. Het lukt echter slechts zeer zelden om ze daadwerkelijk allemaal te vullen. Het gemiddelde ligt voor zover ik weet onder de vier instructies per cycle, zelfs voor geoptimaliseerde software. Het zou dus bar weinig nut hebben om een Itanium-core te bouwen die twaalf instructies per kloktik uit kan voeren.

Je argumenteert dat software parallel geprogrammeerd zou moeten worden, maar als een programmeur zich met parallellisme bezig houdt dan hebben we het bijna automatisch over threads. Een multi-core, multi-threading processor zoals de Montecito leent zich perfect voor dat soort software. Het soort parallellisme dat je krijgt door een enkele core te "multiplexen" (zoals je dat noemt ) zit op een lager niveau en is juist extreem lastig om te benutten.

[Olaf van der Spek]

Boeiend! Maar eigenlijk vind ik het jammer dat men voor het multi-core concept echt letterlijk complete "stand-alone" cores gaat gebruiken.

Dat is het geen multi-core meer, maar hyper-/multi-threading, wat dus ook al wordt toegepast.

[Verwijderd]

Dat is het geen multi-core meer, maar hyper-/multi-threading, wat dus ook al wordt toegepast.

Niet echt, want bij multithreading zoals Intel dat toepast heeft de core maar kleine aanpassingen ondergaan om het mogelijk te maken een extra thread te draaien in een tijdelijk onbenut gedeelte van de processor. De logica van de processor zelf wordt dus niet veranderd, er wordt alleen maar efficienter mee omgesprongen.

Hoe jevandorp het voorstelt is dat er echt dubbele versies van veelgebruikte onderdelen van de processor worden gemaakt ipv. de hele processor te spiegelen. Alleen is dat zoals door Luxx al opmerkte waarschijnlijk niet rendabel want de mogelijkheid zal vast wel door Intel, AMD, IBM, Transmeta etc. zijn bekeken.

[TheGhostInc]

Je zou helemaal gelijk hebben als we rond de Motorola 68000 zouden zijn blijven steken.
Die gebruiken meerdere clockpulsen per instructie. Huidige processoren clocken elke puls een nieuwe instructie in, die er dan bijvoorbeeld 12 of 16 clockpulsen later uit komt. Dus er wordt al ontzettend veel parallel uitgevoerd. Als je de zaak gaat simplificeren zoals jij nu doet kun je geen uitspraken meer doen die met de werkelijkheid van doen hebben.
Tip: Lees een paar sites over het inwendige van de P4 en Opteron en probeer aan de hand daarvan dan iets zinnigs te zeggen, want op deze manier raak je kant nog wal.

[Verwijderd]

beetje jammer dat je de 68000 hier als voorbeeld gebruikt .... kijk dan liever naar de oude x86 architectuur.

[Verwijderd]

Een "single" core is eigenlijk al een beetje multi-core. De FPU die je aanvoert is sinds de Pentium-I dubbel uitgevoerd, de integer berekeningen 4- tot 6-voudig (overigens is op Celerons een gedeelte hiervan weer gesloopt). De CPU/FPU doet aan branche-predictie binnen 1 thread. Je zou het kunnen zien als ware het dat een Pentium probeert een 1 thread programma om te zetten in een multi-thread-versie. Dit concept maakt dat de FPU delen door meer dan 1 processor juist weer ongunstiger uit zal gaan pakken.

[Verwijderd]

Lekker boeien een L1 Cash van 18 Kb.
Bij AMD is dat 128 !!! kan je nog zoveel L2 en L3 geven het is erg krom. Dat zou Intel eens moeten verhogen.

Net als....
Je komt met je sport wagen pas op een 4 baans weg. Nadat je eerst in de file heb gestaan.

Is L1 Cash dan zo duur ? lijkt me toch verkeerde zijnigheid.

Maar ja wie ben ik he ?

[Wouter Tinus]

Itaniums L1-cache heeft een latency van 1 cycle. In die tijd moet de data gevonden, gelezen en gekopiëerd worden naar de juiste plaats. Met zulke strakke timings is het niet realistisch om een heel groot L1-cache te implementeren. Als het voor Itanium de moeite waard was geweest om een groter L1-cache te bouwen (met als prijs een paar cycles extra latency) dan hadden ze dat heus wel gedaan. De Pentium 4 met zijn snelle L1-cache van 8KB heeft ook lange tijd geen enkele moeite gehad om de Athlon XP met 128KB L1-cache bij te houden.

Om je eigen analogie dus te gebruiken: je koopt een sportwagen en begint te klagen dat je geen grote kofferbak hebt, terwijl de in Volvo van je ouders makkelijk een hele kar boodschappen kan!

[Verwijderd]

Ok dat snap ik.

Maar Intel heeft inmiddels wel de L1 Cash verhoogt naar 16 Kb op de P4 Prescott.
en moet toch de (inverhouding) snellere AMD's
aan zich voorbij laten gaan.
Typerend is dan wel dat AMD 128KB Cash hebben.
en als dat niks uit zou maken waarom dan van 8 naar 16 verhogen ?

Het blijft in mijn ogen toch een twist punt.
Maar thanks voor de uitleg.

[Luxx]

Natuurlijk maakt het wel uit, en meer cache is altijd beter. Maar het is niet zo dat de processor met de meeste L1 cache automatisch de beste is. De hele samenstelling van de processor is veel complexer.

Een iets snellere, maar kleinere L1 cache kan efficienter werken, dan een grote L1 cache. Stel je haalt de L1 cache van een Itanium weg, de L2 is dan automatisch het "eerste" level, en de L3 wordt dus het 2e level. ALs je naar de cijfertjes zou kijken, wordt de L1 cache dus groter (en langzamer), je begrijpt dat het ontwerp er toch niet sneller door zal worden.

[Verwijderd]

Ja nu snap ik het !!!

Anders zou deze er langer over doen om te ververzen
en dus langer vol lopen. en dat is nat. precies wat ze niet willen.

[Luxx]

zelfs de Level2 cache van een itanium heeft maar een latency van 5-6 cycles, terwijl de Opteron dit in 3 cycles doet. Met de 2x zo brede cachebus van de Itanium wordt heeft de L2 cache dus de zelfde bandbreedte als Opterons L1 cache.
Het zelfde geldt ongeveer voor de L3-itanium-cache, vs de L2 Opteron cache. Hoewel de L2 cache latency van de Opteron "geheim" is, wordt deze geschat op 7-8cycles, waar dit bij de Itanium 12-17 is op een wederom 2x zo brede cachebus, is het verschil dus erg klein.
bron1 bron2

[catfish]

aangezien de itanium techniek schijnbaar toch een stuk beter is dan x86 vind ik dat intel toch eens mag beginnen om de consument er voor warm te maken

[Twisted]

Itanium is niet voor de normale consument bedoeld.. Het is een processor die gebruikt wordt voor grote database servers of rekencentra's. Je zult er ook geen gewone programma's vinden die op een Itanium draiien.. dus geen Doom 3 op een Itanium.

De x86 standard is ook helemaal niet slecht en heeft tot nu toe zijn diensten goed bewezen. AMD is nu met de 64bits extensie gekomen maar eigenlijk is die nog helemaal niet nodig. Het vornaamste wat er verandert met de 64 bits extensie is dat je meer geheugen kan aanspreken. Limiet ligt nu bij 4GB, meer dan genoeg voor elke consument.

[n4m3l355]

bij mijn weten emuleert de itanium 32bits dus kun je er zeker wel doom op spelen maar zal het zeker niet snel zijn. maar om de consument klaar te maken voor peperdure procs is een beetje onzinnig. vooral door de extreem grote cache maakt het de processor erg duur.
wat me ook opvalt is dat dit ontwerp qua dual-cores beduidend effectiever opgepakt is dan de amd's wijze. amd gebruikt de crossbar switch terwijl intel de arbiter gebruikt. dit nadat al duidelijk is wat er met het geheugen gaat gebeuren om zodoende 1 uitgang te krijgen naar de system interface via een stevige bus natuurlijk. dit zal een snellere oplossing zijn voor de queering (als ik dat goed spel ^-). ook het verdelen van het geheugen is een mooie oplossing. eigenlijk wel verwonderlijk dat zoiets niet eerder bedacht is aangezien het eigenlijk heel simpel overkomt. al zal dat waarschijnlijk ook de reden zijn waarom.. het komt simpel over maar zal wel weer lastig zijn om het zo uit te voeren in de praktijk

[Verwijderd]

Waarom is een arbiter beter dan een crossbar switch??

[tofus]

Het vo[o]rnaamste wat er verandert met de 64 bits extensie is dat je meer geheugen kan aanspreken

Dat is zeker niet het enige wat veranderd; De 64-bits CPU kan twee keer zoveel bits per kloktik verwerken als een 32-bits CPU. Dit houdt in dat er, in theorie, letterlijk 2x zoveel data kan worden 'verwerkt' in dezelfde periode.

Verder zijn er een boel zaken tegenwoordig in 64 bits datatypes uitgevoerd (floats, bitboards, etc.). Een CPU die 'native' deze formaten ondersteund, zal een stuk krachtiger zijn dan een CPU waarbij eerst 'inhaalslagen' moeten worden gemaakt, om alle bits op een rijtje te krijgen. Kortom: met 64 bits support wordt je programma beter/direkter 'vertaald' naar (betere) machinataal door evt. compilers.

Dat het maximale 'platte' adresseerbereik hiernaast ook nog eens met een factor 4 miljard wordt verbeterd is een leuke 'bonus'. Moderne CPU's en OS'en hadden al de mogelijkheid om meer dan 4Gb aan te spreken d.m.v. geheugen-'segmentering'.

64 bits biedt dus een hoop voordelen, *naast* het extra adresseerbereik voor RAM.

[Wouter Tinus]

Het "64-bits" zijn betekent voor de hier bedoelde x86-processors dat ze met 64-bits integers kunnen rekenen. 32-bits processors kunnen al jaren probleemloos werken met 80-bits floating point getallen en 256-bits vectors (SSE). "Meer bits" is dus lang niet altijd gelijk aan "meer data"; vaak gaat het gewoon om een grotere nauwkeurigheid.

Zelfs de grotere integers zorgen er alleen voor dat de berekening sneller gedaan is als er ook daadwerkelijk gewerkt wordt met getallen groter dan 4 miljard. Je kunt niet ineens twee kleinere optellingen doen met één instructie omdat er twee keer zoveel bits zijn.

Met je slotzin ben ik het wel eens, maar dan niet om de redenen die je zelf noemt. Het gaat dan over extra registers en het opschonen van enkele overbodige instructies en andere vaagheden waar x86 al jaren mee vervuild is. Die vertalen zich weer naar een performancewinst van 10 tot 20%, zelfs als er helemaal niets met het "64-bits" wordt gedaan.

[Verwijderd]

Limiet ligt nu bij 4GB, meer dan genoeg voor elke consument.

De limiet ligt al sinds de 80386 op 64 TB, mits het geheugen netjes gepaged is. Op een 64-bit machine kan je alleen de hele rambam als 1 segment aanspreken. Ooooh, en is daar met SP2 juist niet een stokje voor gestoken .

[Verwijderd]

Twisted schreef (...)

Nee. Dat de itanium niet voor de consument is bedoeld, is een keuze van Intel geweest. Dat AMD64-spul het als consumergoed best doet, geeft aan dat ook de besten wel es de plank misslaan .

De x86 was lachen maar komt uit een ander tijdperk en voldoet niet meer. Dat AMD sedert de K5 het x86-gedachtengoed heeft vervangen door micro-programmering heeft zijn vruchten afgeworpen; een Opteron is bijna even spel als een x86-64 en dat met de helft minder transistoren EN halve kloksnelheid.

Het verhaal over DoomIII begrijp ik niet.

[Verwijderd]

Er is vast iemand die er meer inhoudelijk iets over kan roepen, maar de techniek van de Itanium is voor specifieke toepassingen superieur. Volgens mij is dat niet het draaien van Doom 3.

Daarnaast kan je al je huidige software weggooien. Dan doen mensen doorgaans ook niet al te graag...

[Luxx]

De Itanium zou prima doom3 kunnen draaien, als doom3 er voor geoptimaliseerd zou worden. Op het moment heeft Intel echter een Prescott core die ze veel goedkoper kunnen maken (1/4 van het oppervlakte van een "kleine Itanium") en daarom zou Intel wel gek zijn om nu de Itanium breed te lanceren.
Daarnaast is het zolang de software er niet klaar voor is, voor Intel onmogelijk om de Itanium breed te lanceren. Natuurlijk is dat een beetje een kip/ei verhaal. Intel heeft met de Itanium oude compatibiliteit min of meer heeft laten vallen (oude software draait wel, maar veel te langzaam*), en daarom heeft de Itanium een (verwacht?) aanloop probleem. Marktacceptatie duurt langer dan door veel mensen verwacht. Intel verwacht echter dat de preformance van de Itanium relatief harder zal groeien dan die van zijn x86 concurrent, daardoor zal de Itanium steeds aantrekkelijker worden voor de markt.

Daarnaast ondersteunen steeds meer bedrijven software voor de Itanium, en met de groei van open source zal de Itanium ook profiteren. Kortom, Intel is er van overtuigd dat de Itanium langzaam maar zeker goedkoper, en sneller kan worden dan een x86 processor. Op het moment 'wil' Intel echter de vraag naar itanium beperken tot het high-end gebeuren, en daarom rekenen ze een erg stevige prijs. Voor de budget markt is de Itanium gewoon nog te duur om te produceren.

*) X86 software kan door de introductie van de IA32EL, zowelzowel onder linux als in windows ongeveer even snel draaien als een gelijk geklokte Xeon. Goed genoeg om even te gebruiken, maar daar koop je geen Itanium voor!

[ferdinand]

Daarnaast is het zolang de software er niet klaar voor is, voor Intel onmogelijk om de Itanium breed te lanceren. Natuurlijk is dat een beetje een kip/ei verhaal, en aangezien Intel met de Itanium oude compatibiliteit min of meer heeft laten vallen (oude software draait wel, maar veel te langzaam).

Ik had begrepen dat die x86 emulatie nu veel beter draaide en zelfs goed meekon met redelijk recente P4's. Daarbij zou Intel een aantal Linux distro makers kunnen sponsoren om een Itanium Linux Distributie te maken. Gooi er een mooie emulatie in voor de programmas die niet geport kunnen worden en dan heb je toch iets redelijks dacht ik zo. Daar is je kip of je ei wat je maar wil.

[MrMr]

Hoezo sponsoren? Alle Itanium systemen zijn al (jaren) te koop inclusief een compleet native linux distro.
Ik denk niet dat de hardware of distro-makers het probleem zijn, hooguit een paar applicatie-verkopers die hun code niet hercompileren en een enkele OS leverancier die wat langzaam is.

[Verwijderd]

Mobiele supercomputers

Earthstation mobile.

[ferdinand]

aangezien de itanium techniek schijnbaar toch een stuk beter is dan x86 vind ik dat intel toch eens mag beginnen om de consument er voor warm te maken

Ik heb liever dat de itanium koeler word

[Olaf van der Spek]

aangezien de itanium techniek schijnbaar toch een stuk beter is dan x86

Waar haal je dat vandaan?

[Titusvh]

CMT is de techniek waarmee vier threads op de dual-core chip kunnen draaien. Niet geheel tegelijkertijd zoals bij SMT (HyperThreading) gebeurt, maar meer om de beurt; terwijl de een thread op data uit het geheugen wacht kunnen bijvoorbeeld instructies voor de andere thread uitgevoerd worden.

Hyperthreading is JUIST niet tegelijkertijd processen maar het benutten van CPU-tijd die een andere thread anders op data staat te wachten.
Dat kan ook niet anders want bijvoorbeeld de huidige HT-Pentium 4's zijn immers single-core!

SMT is dus niet HT. Maar juist 'echt' multi processen (Symetric Multiprocessing...)

[Edit:]
Ben wel benieuwd waar de C in CMT voor staat..

[Ruuddie]

[quote]
[Edit:]
Ben wel benieuwd waar de C in CMT voor staat..
[/quote]

[quote]
[..]De reden hiervoor is niet geheel duidelijk, maar mogelijk gaat het om extra ruimte voor de branch predictor of Coarse-grained MultiThreading. CMT is de techniek[..]
[/quote]
't Staat er echt hoor

[Wouter Tinus]

Een Pentium 4 heeft inderdaad één core, maar wel zeven execution units. De units die de ene thread niet gebruikt kunnen dankzij SMT / HyperThreading door een andere thread wél worden gebruikt, en zo kan een single-core processor dus wel degelijk voor twee threads tegelijk aan het rekenen zijn. SMT en SMP zijn anderen dingen!

[Vaudtje]

CMT is dus nog steeds geen SMP!
CMT doen, net als HT, twee verschillende dingen op een core. CMT is dus qua principe gelijk aan HT, alleen de implementatie is anders
Overigens:

De reden hiervoor is niet geheel duidelijk, maar mogelijk gaat het om extra ruimte voor de branch predictor of Coarse-grained MultiThreading

edit:
Maar ik heb lekker wel twee verschillende posts tegelijk gedubbelpost

[Verwijderd]

De x86 standard is ook helemaal niet slecht en heeft tot nu toe zijn diensten goed bewezen. AMD is nu met de 64bits extensie gekomen maar eigenlijk is die nog helemaal niet nodig. Het vornaamste wat er verandert met de 64 bits extensie is dat je meer geheugen kan aanspreken. Limiet ligt nu bij 4GB, meer dan genoeg voor elke consument.

what the f*ck ???

x86 is onwijs oud en totaal niet ontwikkeld voor de huidige PC`s het werkt wel en het wordt ook wel sneller maar echt efficient is het niet want een MAC draait op veel lagere clocks en behaald toch een aardige performance vergeleken met de huidige x86 CPUs en natuurlijk kan je het wel aanpassen dmv MMX, SSE, SSE2, SSE3 en 64 bits instructies maar dat zijn allemaal lapmiddelen

veel beter zou zijn als ze een totaal en compleet nieuwe standaard maken maar ja dat zal intel ook niet willen want die vangen dmv patenten toch aardig wat knaken van AMD en AMD alleen zal zoiets nooit kunnen bewerkstelligen, maar persoonlijk hoop ik dat ze overgaan naar een andere CPU die NIET x86 compliant is ookal heeft dat een gigantisch nadeel dat al je software ineens niet meer werkt

[microchip]

Maarjah, als ik lees wat er in dat bericht staat over IA32-EL, dan heb je toch eigenlijk geen hardware backwards compatibility nog nodig? Of begrijp ik het nu helemaal verkeerd?

En in de Itanium zat toch HELEMAAL geen x86 meer? Ik dacht dat het draaien van x86 software op een IA64 processor via software ging...

[Vaudtje]

beide stellingen zijn correct. Wat is je vraag?

[Vaudtje]

Ik heb eigenlijk het idee dat Intel wel degelijk op de lange termijn IA-64 als opvolger voor x86 ziet, juist omdat ze het zat waren om steeds lapmiddelen op die architectuur te bouwen. AMD, heeft juist wel weer een extra patch op x86 gemaakt om '1 lullig probleempje' (geheugen) op te lossen.

Doordat die concurrentie er is, kan Intel nu zijn (compatibility-breaking) technologie niet forceren, omdat er voor de conservatieve consumenten (alle Amerikaanse bedrijven bijvoorbeeld, omdat die nooit lange termijn investeringen doen) een alternatief is.

Misschien hadden we zonder AMD nu wel allemaal thuis een IA-64 desktoppie Dan had Intel zijn zin kunnen doordrijven en iedereen kunnen dwingen over te stappen, ondanks de eventuele problemen. (Ze hadden dan wel wat meer moeite in de IA32-EL gestopt)

[Cyberamp]

Montecito thread parallelism (TLP) raises with the dual core and Coarse-Grain multiple threading. With Montecito physically the 2CPU core, logically it becomes the 4CPU core vis-a-vis former Itanium2 being the 1CPU core.

8 cpu technologie word is feit! Als je een mobo hebt met 4 cpu sloten dan ben je binnen

http://www.silverpcs.com/category/70motherboards.quad4cpumotherboards/

Kijk eens op Geek.com:

http://www.geek.com/news/geeknews/2004Aug/gee20040831026740.htm

Whoa!

@modder: Hoezo offtopic? Lijkt me hartstikke relevant!

[Wick]

Is dat niet juist wat ze met IA-32EL doen?

[TD-er]

de TDP van de bijna twee miljard transistors tellende chip op 100 Watt is vastgesteld, 30 Watt láger dan dat van de huidige Madison-serie. Dit terwijl de kloksnelheid van de Itanium niet alleen verhoogd wordt van 2,0 naar 2,5GHz, maar er ook nog eens een hele tweede core aan de chip wordt toegevoegd. De overstap van 130nm- naar 90nm-productie werpt voor Itanium dus duidelijk meer vruchten af dan voor de Pentium 4.

Het afgegeven vermogen (warmte) van de processor is afgenomen, tov de voorganger.
De overige informatie die we hebben is dat de kloksnelheid van de core is toegenomen en het aantal cores is toegenomen.
Deze laatste feiten zeggen echter niets over dat ze mischien in de praktijk relatief veel staan te wachten, of dat mogelijk de branchprediction heel anders is uitgevoerd, of dat de pipeline minder vol gehouden wordt.
Het kan dus best zijn dat ze met deze nieuwe versie wat aanpassingen hebben gemaakt waarbij in de praktijk veel minder transistoren hoeven te schakelen.
Het is dus heel goed mogelijk dat ze de nodige statistiek eroplos gelaten hebben en bijv een snelheids-optimalisatie weggelaten hebben, die erg veel vermogen vraagt voor een vrij minimale snelheidsverbetering.
Wanneer ze bijvoorbeeld erachter gekomen zijn dat er voor de programma-code in de L1-cache best vaak een miss optreed, kun je vrij veel snelheidswinst en vermogen-reductie halen door deze langer in de cache te houden. (het kopieren van de ene cache naar de andere kost erg veel geschakel van transistoren)
Deze snelheidswinst kun je weer gebruiken om andere snelheidsverliezen te verdoezelen. compenseren.

Kortom het is IMHO helemaal niet zo duidelijk dat die afname van de TDP het gevolg is van de overstap van 130nm naar 90nm.

[pietje63]

Dit is een server cpu, servers staan 24/7 aan en er zitten vaak meerdere van deze monsters is, dan scheelt 30 watt stroom op jaarbasis aardig wat.

Ook als je bedenkt dat minder stroom meestal minder warmte is, en dus heb je minder goede koeling nodig etc etc.

[fallen_angel]

snelheid is niet alles hoor. hoe meer stroom hoe warmer je kast wordt dus hoe meer koeling je moet toevoegen.
denk eens aan een datacenter waar veel processorkracht nodig is, dan is warmte wel degelijk relevant.
Zodoende kan het goedkoper zijn om 100x een minder sneller en koelere processor aan te schaffen dan 80x een snellere en warme processor.
(denk aan zaken als airco en stroom verbruik)

[Wouter Tinus]

Natuurlijk is hij ook sneller. Het is echter nogal een goede prestatie om naast ~2/3 keer de rauwe rekenkracht en bijna een verviervoudiging van het aantal transistors ook nog eens een zuinigere chip te krijgen. Zeker gezien de eerdere kritiek op het 90nm-procédé van Intel toen Prescott uitkwam.