IBM bespreekt threading-technologie Power5-chip

Vandaag zal IBM op het Hot Chips Symposium te Palo Alto (Californië) uitleg gaan geven over de Simultaneous Multi-threading Technology die in de aanstaande Power5 processors verwerkt zal zijn, aldus eWeek. Mark Papermaster, directeur microprocessor design in IBM's Systems Group, verklaarde alvast dat deze threading-technology het de Power5-chip mogelijk maakt automatisch en dynamisch te kunnen schakelen tussen single- en multi-threaded mode. Deze zelfregulering geldt ook voor het benodigde vermogen, dat in de processor verdeeld kan worden ten behoeve van de verschillende processortaken, al naar gelang de prioriteit die software-instructies aangeven:

A key mechanism is the ability to dynamically switch the chip from a multi-threaded to single-threaded mode, he said. If an application programmer wants all the processor's resources devoted to a single thread, he needs only to insert an instruction call, Papermaster said.

In addition, the chip automatically can sense the work it is being asked to do, and can dynamically shift energy resources toward that job as needed and away from areas where demand is less, Papermaster said.

"The programmer doesn't have to do a thing," he said. "It will automatically adjust where the power goes."

Papermaster verklaarde dat SMT in de 64-bit dual-core Power5 de prestaties 'viervoudig' zou doen toenemen, doordat iedere core twee threads tegelijkertijd kan verwerken. De Power5 zou in de eerste helft van 2004 seriematig van de band moeten rollen, om eind 2004 in IBM's eServer iSeries en pSeries op de markt te verschijnen.

Reacties (21)

[Anoniem: 88387]

A key mechanism is the ability to dynamically switch the chip from a multi-threaded to single-threaded mode, he said. If an application programmer wants all the processor's resources devoted to a single thread, he needs only to insert an instruction call, Papermaster said.

Dit lijkt me handig voor doe vermaledijde SPEC benchmarks. op deze manier kijk je ook ineens heel anders aan tegen het voordeel van SMT technieken. Als je een benchmark hebt die maar 1 thread is dan zorgt SMT alleen maar voor overhead en een slechter resultaat. daarom is het slim als je voor zon singlethreaded benchmark de SMT even uit kunt zetten. en daarom presteert een Pentium 4 bijvoorbeeld ook beter als hyperthreading (een SMT implementatie van intel) uitgezet wordt voor een single threading benchmark. alle resources (execution units, rename registers) kunnen en masse ingezet worden voor die eene benchmarkthread. (uitzetten van hyperthreading in P4 is voor veel tweakers controversieel, niet terecht imho).

[edit: typo's]
[edit: beaves]

beaves als jij beweert dat SMT zin heeft voor een singlethreaded benchmark ben je behoorlijk lost. Voor een single threaded benchmark heeft SMT/hyperthreading zelfs nadelige effecten. dat is mijn punt.

[Beaves]

kunnen en masse ingezet worden voor die eene benchmarkthread. (uitzetten van hyperthreading in P4 is voor veel tweakers controversieel, niet terecht imho).

Wel terecht, sinds de Pentium 4 een nieuwe core stepping heeft, de C stepping, is de prestatie van HTT toegenomen vergeleken met de eerste HTT implementatie in de Xeon.

Die eerste implementatie had inderdaad het nadeel dat het in de meeste gevallen niets sneller of zelfs langzamer was, maar dat nadeel is bij de C stepping weg. De P4 3,06 GHz was trouwens de eerste met de nieuwe versie van HTT. Zie dit en dit nieuws.

Benchmarks wijzen uit dat ook de normale gebruiker nu profijt heeft van HTT aangezien alle applicaties die mensen thuis gebruiken er op vooruit gaan kwa snelheid aangezien HTT nu ok bij single-threaded software nut heeft.

Of het in een server nut heeft, die vaak maar 1 of twee taken heeft moet je altijd eerst testen, dan zie je snel genoeg of je HTT wel of niet moet gebruiken.

edit:

Ik ben niet lost, zie mijn voorbeeld over single threaded software en ook de reactie onder mij. HTT heeft dan geen nut, maar zeker ook geen nadeel.

Dat is mijn punt...

[hardwareaddict]

Juist in de dual en quad Xeon servers heeft SMT niet altijd voordelen.

Laat ik dat statistisch simpel bewijzen.

Een server idled veel (niets nieuws voor lezers mag ik hopen). Dan hop knal ineens start iemand zijn programma die 2 threads heeft en die in principe 2x de volle cpu wil pakken.

Ondanks allerlei fixes in het OS, betekent dit dus het volgende. Er zijn 4 states mogelijk.

Laten we fysieke en logische processors uit elkaar houden voor de beide fysieke processors A en B en logische processors 1 en 2 op elke cpu:

State 1 en 2 (zelfde maar dan B1 en B2 op run):
A1 : Run B1 : Idle
A2 : Run B2 : Idle

State 3,4,5,6 (op elke fysieke processor 1 thread) :
A1 : Run B1 : Run
A2 : Idle B2 : Idle

In geval van states 3 t/m 6 is er niks aan de hand.
Er is dan EXTRA computing power aanwezig omdat je voor andere threads van andere software dus extra threadslices krijgt.

In geval van states 1 en 2 is je applicatie dus zwaar de pineut omdat je namelijk op 1 fysieke processor loopt. Dus dat is hooguit 10% sneller als 1 processor. Kortom dat is 1.1 / 2 = 55% van de werkelijke snelheid van de CPU.

Met andere woorden SMT is niet zaligmakend. Dit komt puur en alleen omdat de P4 niet geschikt is als SMT cpu. De processor heeft te weinig resources om een grote winst eruit te halen.

Pas als SMT een enorme speedup geeft is de techniek interessant.

De beste vorm van SMT heet geen SMT, maar dat zijn dus gewoon 2 cores op 1 processor die. Dat is al heel oud en staat bekend onder de naam CMP.

MVG

[mjtdevries]

Juist een server heeft altijd een heleboel taken. Daar is HTT in eerset instantie voor gemaakt. (1 applicatie staat niet gelijk aan 1 taak. Server applicaties zijn over het algemeen goed multithreaded geschreven)

Voor een normale gebruiker is het inderdaad ook verstandig om HTT aan te zetten, maar niet om de reden die jij noemt. Het is namelijk niet zo dat alle applicaties er op snelheid op vooruit gaan, maar het probleem dat single threaded applicaties er in snelheid op achteruit gaan is opgelost.
HTT voor de thuisgebruiker is nu dus een feature geworden die in 90% van de gevallen niets oplevert, en in 10% van de gevallen gunstig is. Maar aangezien het nooit ongunstig is, is er dus geen reden het niet aan te zetten.

[eijckron]

En wanneer heeft MS dat dan wel uitgevonden?

In 1984 had de Amiga al Processes en Tasks waarbij een Task aardig overeenkomt met wat we tegenwoordig een Thread noemen.

[Anoniem: 25679]

is dit nou gewoon een copy van intels techniek??

[TheGhostInc]

Het idee is al heel oud:

Laat onderdelen van een CPU die niks staan te doen, alvast een andere opdracht (thread) verwerken.

A key mechanism is the ability to dynamically switch the chip from a multi-threaded to single-threaded mode

Dit is bij de Intel's weer anders, hierbij wordt de CPU gedraaid in een bepaalde modus, en is alleen tijdens het opstarten de mogelijkheid dit te veranderen.

* 786562 TheGhostInc

[Anoniem: 48318]

A key mechanism is the ability to dynamically switch the chip from a multi-threaded to single-threaded mode, he said.

Leuk voor licenties die gekoppeld zijn aan het aantal processoren (aangenomen dat P5's in multithreaded mode ook zichzelf naar het OS presenteren als 2 procs).
Oracle voor deze server kost nu 65000 per jaar, en nu 40000 oh, en nu 72000....

[Beaves]

Leuk voor licenties die gekoppeld zijn aan het aantal processoren (aangenomen dat P5's in multithreaded mode ook zichzelf naar het OS presenteren als 2 procs).

Gelukkig werkt het niet zo, naar mijn weten gebruikt Oracle en alle andere die afhankelijk van het aantal CPU's de licentieprijzen berekenen, het aantal fysieke CPU's en niet het aantal logische CPU's, want anders zou je inderdaad rare situaties gaan krijgen.

Een MT CPU, die dus uit meerdere logische CPU's bestaat zou dan flink in het nadeel zijn, de gebruiker moet evenveel betalen als bij een dual CPU opstelling terwijl de winst bijna altijd minder is. Dat zou er dus voor zorgen dat niemand dan MT zou gebruiken.

Daarnaast maken alle moderne OS'en ook onderscheid tussen logische en fysieke CPU's, want anders krijg je daar ook problemen. Als je bijvoorbeeld Windows 2000 Professional draait (die nog geen onderscheid maakt als ik het goed heb) kan je maar 1 MT CPU gebruiken omdat Windows die als twee fysieke CPU's ziet.

Maar daar is dus aan gedacht en de fabrikanten kijken naar het aantal fysieke CPU's, niet naar de logische.

[blade181]

Dan zullen ze dit ook wel de software voor moeten gaan schrijven om van deze mogelijkheden gebruik te maken, zoals in de linux kernel.

[boner]

mag ik even in de herinnering brengen dat MS de 'uitvinder' is van de thread. Voor die tijd waren er processen. Dus complete processen die per stuk een (time)slice kregen. MS heeft toen de Thread bedacht, een lichtgewicht uitvoering. Een proces kan meerdere threads opstarten.

Dus is het niet een beetje ongepast om hiervoor LINUX, tuurlijk gebruikt klinux ook threads, als boegbeeld te gebruiken.....

[Anoniem: 53692]

Uh, was dat niet IBM zelf? Met OS2-2.21 had ik in 1992 al threading in huis...

edit:

Hmm, en Amiga was nog eerder, begrijp ik uit de post van Eijckron...

[Anoniem: 89533]

Inderdaad heeft MS geen threading uitgevonden. En natuurlijk zat dat allang in the Amiga, al noemde ze dat multi-tasking.

Misschien bedoel je dat belachelijke
'Appartment Threading' van Microsoft: een truuk om thread-unsafe VB componenten toch enigsinds in parallel te laten draaien in 1 process-ruimte.

Over threads en IBM gesproken: weet iemand of Java Operating-System native threads gebruikt of een JVM-thread simulatie.

Wel handig om te weten of zo'n processor wel nut heeft bij Java componenten.

[Anoniem: 88387]

de threads die boner bedoelt zijn software threads. op processornivo wordt met veel kortere codefragmentjes gewerkt. de relatie software threads en processor threads is absoluut niet 1 op 1. dus MS threads ongelijk aan threads begrip in Symmetrical Multi Threading.

[Anoniem: 89533]

Volgens mij kunnen bij SMT alleen 2 threads uit hetzelfde process tegelijk draaien. Dit zijn dus threads die ondersteund en gestuurd worden door het Operating System.

Dit is dus het verschil tussen een multi-processor en SMT. Een multi-processor machine presteerd d dus optimaal als er meerdere processor intensieve zaken draaien: dan zitten ze elkaar ook niet in de weg.

Een SMT presteerd optimaal met 1 process en meerdere threads, zoals een database service.

[voodooless]

the chip automatically can sense the work it is being asked to do

Spannend, een chip die weet wat hem te doen staat Zou ie ook staken als hij teveel werk krijgt?

Maar even serieus: Dit klint allemaal erg goed. En over een jaar ofzo zal Apple deze CPU's ook in hun nieuwe Gx computers gaan inzetten. Op deze manier zullen ze waarschijnlijk wel redelijk op de hoogte van AMD/Intel kunnen blijven, of ze misschien wel voorbij gaan streven.

[blade181]

Dan zullen ze ook wel ff hun MacOS moeten herschrijven of aanpassen om deze mogelijkheden te ondersteunen anders heb je er ook weinig aan.

[ATS]

Ik denk dat het vooral in het aanpassen van de compilers zal gaan zitten, en niet direct in het aanpassen van de software zelf (behalve dat die 64 bits moet gaan worden, wat in het geval van de linuxkernel al gedaan is).

[ronny]

Als ze deze in de Appels gaan stoppen weet je zeker dat ze Intel en AMD voorbij racen.
Dit is namelijk de volledige Power processor en niet de simpele afgelijde die nu in de Appel's wordt gebruikt.
het zou echter ook een duure Appel worden omdat deze dingen nogal wat kosten en meer de concurent van de Itanium is ipv P4

[cougare]

denk dat er een foutje in de tekst staat. Mr. Papermaster is plots de Papermate geworden

IBM weet trouwens altijd wel mensen aan te trekken met gepaste namen

[Anoniem: 87825]

Yep, de Paulachip (voor audio geloof ik), Fat Agnus etc. Allemaal losse chips, die geloof ik ook naast elkaar werkten! Daarom waren die Amigaatjes met hun lage kloksnelheden best rap.

edit:
Oeps, ik geloof dat eijckron iets anders bedoelt?