Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

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.

Door

46 Linkedin Google+

Bron: PC Watch Japan

Lees meer

Reacties (46)

Wijzig sortering
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.
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.
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.
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.
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.
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!
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.
:) 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.
B-)
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
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.
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
Waarom is een arbiter beter dan een crossbar switch??
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 :D.
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.
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.
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... ;)
[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 :P
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!
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 :*)
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...
beide stellingen zijn correct. Wat is je vraag? :Y)
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 :P 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)
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.
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)
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.

Op dit item kan niet meer gereageerd worden.


Call of Duty: Black Ops 4 HTC U12+ LG W7 Samsung Galaxy S9 Dual Sim OnePlus 6 Battlefield V Microsoft Xbox One X Apple iPhone 8

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V. © 1998 - 2018 Hosting door True

*