HyperThreading open voor programmeurs

In dit persbericht heeft Intel definitief de aanzet gegeven tot HyperThreading. Met het in gebruik nemen van de nieuwe Intel Xeon processor voor dual- en multiprocessor opstellingen wordt namelijk ook de HyperThreading techniek geïntroduceerd. Om ontwikkelaars te helpen met het bouwen van geoptimaliseerde software voor deze nieuwe feature heeft Intel het Early Acces Program and Tools for the Intel Xeon Processor family gestart.

HyperThreading (SMT) technologie zorgt ervoor dat de processor door het operating systeem behandeld kan worden als twéé losse verwerkingseenheden. Zo kunnen meerdere afzonderlijke delen van een programma tegelijkertijd bezig zijn. Op die manier is een flinke perfomanceboost te behalen, Intel spreekt van zo'n 30 procent bij gebruik van multithreading applicaties. Daarnaast kan een server nog meer taken per klokcyclus uitvoeren en sneller reageren. Over het algemeen kan gezegd worden dat de snelheid waarmee multitasking wordt uitgevoerd verbeterd wordt. Richard Wirt - general manager van Intel's software and solution group - had het volgende erover te zeggen:

"As software developers optimize their products for the NetBurst microarchitecture and Hyper-Threading Technology, enterprise server customers will start seeing very significant system performance boosts and programs such as the Early Access Program, combined with our software development tools, will not only accelerate the optimization efforts of Hyper-Threading Technology, it will accelerate the adoption of NetBurst microarchitecture in the enterprise."

[...] Developers can now enroll in the EAP for the Intel Xeon processor family through the Intel® Developer Services Web site. For an annual fee, they will receive a package that includes remote access to Intel Xeon processor-based systems, on-line support from Intel and training. Once the application porting process is complete, the developer becomes eligible for a host of joint marketing and promotional programs with Intel.

Reacties (40)

[Verwijderd]

Vooral het OS zelf zou hier zeer goed gebruik van kunnen maken: low level OS taken kunnen dan efficient worden uitgevoerd zonder dat draaiende applicaties hier veel last van hebben.

[SvMp]

Dat is niet te zeggen omdat de OS kern zelf (op wat timertjes en interruptjes na) nauwelijks taken uitvoert. Ze zijn er wel, maar het is maar een heel klein deel van de processortijd die daarvoor gebruikt wordt. Het zal zelfs heel zonde van de processor-tijd zijn als één helft zich compleet op kernel-taken richt (en dan bedoel ik zaken die in de zgn. supervisor modes van de CPU uitgevoerd worden, "low level OS taken" is nog een vrij algemene term)

Als de OS kern écht iets gaat doen, is dat door invloed van buiten af, bijvoorbeeld als een applicatie een system call uitvoert. En de tijd die de kern daar aan besteed komt gewoon voor rekening van de thread die de betreffende system call bevat.

[mbravenboer]

Ik heb HyperThreading niet al te nauwkeurig bekeken, maar ik begrijp eigenlijk niet waarom programmeurs zich zo specifiek zouden moeten richten op HyperThreading zoals het kopje van dit nieuwsbericht suggereert (en de echte press-release in mindere mate).

Als ik het goed begrepen heb hoef je je namelijk helemaal niet specifiek met HyperThreading bezig te houden. Dat is ook juist het mooie van HyperThreading. Als je namelijk gewoon multi-threaded werkt waar mogelijk (en functioneel) zou je volgens mij gelijk al profiteren van HyperThreading . Het lijkt mij echter sterk dat je je ook specifiek op HyperThreading moet richten.

Hooguit kan je zeggen dat je nu nog meer rekening moet gaan houden met performance voordelen van multi-threading. Wellicht dat op dit moment multi-threading te vaak alleen wordt gebruikt als het ook echt noodzakelijk is.

Ik zie hier trouwens wel een gouden toekomst voor boeken over concurrent programming . Op dit gebied wil het nog weleens slecht gesteld zijn met de kennis van een programmeur .

[Verwijderd]

Om nog maar te zwijgen van het feit dat programma's die specifiek voor HT geschreven zijn misschien slecht(er) of helemaal niet zullen lopen op alternatieve CPU's (lees AMD). Misschien een zet van Intel om te proberen een deel van AMD's marktaandeel terug te krijgen?
Iemand enig idee hoe het hiermee zit? Lopen programma's specifiek gecompiled voor die HT technologie nog op andere procs?

[mbravenboer]

Variant van dezelfde vraag: kan je uberhaupt specifiek gebruik maken van bepaalde HyperThreading instructies?

Volgens mij is dit gewoon een campagne om programmeurs meer aan het multi-threaden te krijgen? .

[Cookie]

Dat vermoed ik ook, maar Intel gaat dat natuurlijk wel onder de marketingnaam HTT brengen. Lijkt me logisch. Daarnaast instrueren ze tegelijkertijd hoe P4 optimalisaties aan te brengen.

[mjtdevries]

He he. Eindelijk iemand die het snapt. (Wel typerend voor Tweakers dat die juist als Troll gemodereerd wordt)

Allereerst maar even wat spraakverwarring weghalen, want ik zie in de rest van de threads hyper en multithreading door mekaar gebruikt worden

- Hyperthreading is de technology waarbij 1 processor 2 threads uitvoert.
- Multithreading is een programmeer techniek waarbij 1 programma meerdere threads heeft. (bij voorkeur zodanig ontworpen dat de threads tegelijkertijd uitgevoerd kunnen worden en dus niet te vaak op elkaar hoeven te wachten)

Als je bij Intel de press-release leest, dan staat daar duidelijk de bevestiging van wat je al dacht:
Je hoeft je bij het programmeren NIET met Hyperthreading bezig te houden. Je moet gewoon zorgen dat je programma netjes MULTIthreaded is.

En dat hele PR-programma van Intel is gewoon een promotieprogramma voor multithreaded programmeren.

En dat is wel nodig ook, want over het algemeen is alleen server software multithreaded. Maar applicatie software voor workstations is dat veeeeeel minder.
En als je applicatie in de praktijk single threaded is maak je dus geen gebruik van die hyperthreading feature van je cpu.

Ik ben wel blij met dat initiatief want multithreading van programma's is ALTIJD nuttig. (ook op single processor systemen) En SMP heeft nou eenmaal de toekomst.
Nou nog hopen dat Intel ook kijkt dat drivers netjes multithreaded worden. Want dat is wat mij betreft nog een groot probleem voor SMP systemen. (zoals bv de beruchte SB Live problemen op SMP systemen)

[mbravenboer]

Bedankt voor de goede info .

Mijn gedachten gingen inderdaad exact dezelfde kant uit. Ik kon in de press-release nog niet zo duidelijk een antwoord vinden, dus het is wel mooi dat je het allemaal even duidelijk uiteenzet .

[mjtdevries]

De volgende twee passages uit de press-releases geven duidelijk aan wat er aan de hand is (Als je een beetje gewend bent aan de PR praat van dat soort bedrijven pik je de relevante secties er al snel uit):

Hyper-Threading Technology allows multithreaded operating systems and applications to view a single physical processor as if it were two logical processors. This technology can deliver up to 30 percent performance boosts of multithreaded applications, enabling faster e-Business transactions.....bla bla bla bla bla

While most server applications are multi-threaded and can achieve immediate performance benefits from Hyper-Threading Technology, Intel is working closely with developers to ensure that software applications take full advantage of the new technology and other features of the NetBurst microarchitecture.

De marketing blaat over Netburst moet je dan weer negeren, maar hier staat dus dat server applicaties wel multi-threaded zijn, maar de gewone applicaties in veel mindere mate.

[BramT]

Ik zie hier trouwens wel een gouden toekomst voor boeken over concurrent programming . Op dit gebied wil het nog weleens slecht gesteld zijn met de kennis van een programmeur .

Bij ons op school is multi-threading programmeren 1 van de eerste dingen die je leert. Echt leuk (lees = makkelijk, dus snel klaar, dus snel aan het bier) is het niet...

Imho zouden compilers op 1 of andere manier altijd multi-threading in een progje moeten bouwen. Ok, dit klinkt krom en lijkt misschien alsof ik er geen zak vanaf weet, maar volgens mij kan je (het OS, compiler, whatever) "makkelijk" bepaalde (en alleen BEPAALDE) threads verdelen over meerde threads. Als je ziet hoe sommige progjes gescreven zijn tenminste...

[SvMp]

Een (voor Intel) betrekkelijk nieuwe technologie, die mij erg goed denken aan "smp on one chip".

Wat ik niet zo goed begrijp is dat ze dit ontwikkelen en introduceren voor een 32-bits processor, de Xeon, terwijl we nu aan de voet van een 64-bits PC tijdperk staan. Intel kan dat gedaan hebben omdat ze langere tijd hebben gewerkt aan deze technologie en het hebben ontwikkeld op een platform waar ze jaren lang ervaring hebben (32-bits i86), maar waarom ze het nou nu nog implementeren op een 32-bits processor terwijl de 64-bits opvolgers klaar liggen snap ik niet.
Voor een werkstation kan ik het mij nog wel enigszins voorstellen, want daar doet de 64-bits architectuur heel langzaam zijn intrede, maar de Xeon en ook een technologie als Hyperthreading is bedoeld voor servers, en het is voor Intel niet verstandig om in die sector te lang aan te klooien met 32-bits technologie. (daar is concurrentie van oa. de Ultra Sparc)

[Beaves]

maar de Xeon en ook een technologie als Hyperthreading is bedoeld voor servers, en het is voor Intel niet verstandig om in die sector te lang aan te klooien met 32-bits technologie. (daar is concurrentie van oa. de Ultra Sparc)

Tussen workstation en de high-end server wereld zit nog een mid-end server markt, en daar is de Xeon voor bedoeld. En aangezien die markt heel erg groot is, is het voor Intel heel erg handig om daar een CPU te introduceren die HTT gebruikt. Overigens heeft Intel zo'n beetje alleenrecht in die mid-end servermarkt. Sun, IBM en andere zitten een markt hoger en AMD (nog) een markt lager.

IA-64 is bedoeld voor de high-end markt, dus die moet met Sun en IBM concureren. En aangezien IA-64 staat nog maar in de kinderschoenen en is nog niet geschikt voor een brede inzet. Intel moet nog veel ervaring opdoen met IA-64 en de markt is nog niet klaar voor IA-64. Het zal dus nog wel even duren voordat IA-64 ook in de mid-end servermarkt verschijnt.

[SG]

intel heeft de Netburst Xeon gepositioneerd tot nu toe als Workstation Proscessor.

De (PIII)Xeon met grote Cache als Server CPU's

Bij servers spelen L1/L2/L3 Cache grotes 'n hele belangrijke rol.

Bij Workstations 'n minder grote rol.

[Appesteijn]

Maar hoe kan 1 proc. die 2 proc.'s simuleert, nu beter presteren dan gewoon 1 processor? Het simuleren brengt toch ook overhead met zich mee?

[nospam]

Omdat de processor in staat is bepaalde instructies parallel uit te voeren, maar hier niet altijd de kans toe krijgt omdat het OS maar één thread tegelijkertijd toegang geeft tot de processor(-tijd).

[SvMp]

Bijna goed, maar "bepaalde instructies" is imho niet helemaal de juiste term om hier te gebruiken omdat dit meer verwijst naar een technologie die al wat langer bestaat.

Ik zou eerder zeggen "bepaalde threads".

Bepaalde instructies tegelijk uitvoeren kan namelijk al sinds de aller eerste Pentium I, toen de x86-CPU's twee pipelines en execution units kregen.

[.oisyn]

nospam heeft wel degelijk gelijk

de cpu's kunnen idd al heel lang meerdere instructies parallel uitvoeren, maar er is altijd maar 1 stroom aan instructies geweest (een thread dus), waar de operanden van de ene instructie weer afhankelijk zijn van de uitkomst van de vorige enz.

Bij hyperthreading gaat het er juist om dat 1 cpu in principe 2 threads gaat uitvoeren, zodat de tweede thread gebruik gaat maken van de niet gebruikte units van thread 1. Op zicht draait dit natuurlijk niet zo lekker als multithreaded met 2 cpu's, aangezien de threads op sommige momenten gewoon moeten wachten, maar de units van de cpu worden zo wel veel vaker en efficienter benut, en dat ook ten koste van slechts 1 cpu

Op die manier kun je dus behoorlijke snelheidswinsten halen bij multithreaded applicaties en multitasking operating systems

[Beaves]

Omdat er fisiek in de core twee CPU's zitten die dus gebruikt kunnen worden in de nieuste CPU's. De CPU emuleert dus geen tweede CPU, die zit er dus in. (Ok, niet echt twee core's, maar om het niet al te moeilijk te maken, het zijn er ongeveer twee. AMD komt met de Hammer wel met twee echt twee verschillende CPU's in een core).

Het OS (bijvoorbeeld Win2K), ziet overigens wel twee fisieke CPU's, dus als je dual Xeon draait, ziet het OS vier CPU's.

(Klein detail is dat de huidige P4 alang HTT aan boord heeft, Intel heeft het alleen uitgeschakeld voor ons als consument).

[marsattacks]

Ik geloof niets van dat "HTT zit al op de P4, maar is niet ingeschakeld" verhaal. Kan iemand mij uitleggen waarom Intel in godsnaam dure die-space zou verspillen aan features die toch niet gebruikt worden? De enige verklaring die ik daarvoor kan geven is dat het misschien wel erop zat maar gewoon niet werkte voor de huidige batches CPU's, en dat ze het daarom maar uitgeschakeld hebben. Een beetje zoals de 486/486SX situatie destijds.

[Beaves]

Ik geloof niets van dat "HTT zit al op de P4, maar is niet ingeschakeld" verhaal. Kan iemand mij uitleggen waarom Intel in godsnaam dure die-space zou verspillen aan features die toch niet gebruikt worden?

De reden daarvoor is de prijs. Het is voor Intel goedkoper om alvast wat feature's in een CPU te bouwen die ze later inschakelen dan dat ze na een jaar een hele nieuwe CPU + productielijn moeten ontwikkelen en opbouwen.

Het is overigens heel duidelijk dat de P4 HTT heeft, aangezien het aantal transistoren precies even groot is als bij een Xeon (met dezelfde hoeveelheid cache). Intel heeft alleen wat lijntjes doorgelaserd bij de consumenten P4.

Als de huidige oplossing duurder was geweest, had Intel daar echt niet voor gekozen.

[Cookie]

Beaves, weet je nu wel 100% zeker dat Intel dat heeft gedaan met fusen van lijntjes? Of is dat een aanname die je met stelligheid brengt? Voor hetzelfde geld ligt het aan BIOS/Chipset/Socket. Als je ergens een linkje hebt waar dit staat, dan zie ik die graag.

[jiriw]

Intel past die uitschakeltrukjes al veel langer toe hoor...
Niet alleen om delen van een CPU uit te schakelen als ze slecht of niet presteren(zoals al eerder gepost) maar ook om markttechnische redenen.

De 486 SX werd niet alleen "gemaakt" uit 486-sen met een kapotte FPU (Floating point unit), maar ook uit goede 486-sen omdat er meer vraag was naar goedkope 486 SX CPU's .... Jammer voor die goede FPU's.
Doorfikken die handel!!

[Verwijderd]

Ok, niet echt twee core's, maar om het niet al te moeilijk te maken, het zijn er ongeveer twee

Inderdaad, het zijn twee instructie pipelines.

[Verwijderd]

lijkt me niet plok, zie wat SvMp hierboven postte:

Bepaalde instructies tegelijk uitvoeren kan namelijk al sinds de aller eerste Pentium I, toen de x86-CPU's twee pipelines en execution units kregen.

[Cookie]

Omdat er fisiek in de core twee CPU's zitten die dus gebruikt kunnen worden in de nieuste CPU's. De CPU emuleert dus geen tweede CPU, die zit er dus in. (Ok, niet echt twee core's, maar om het niet al te moeilijk te maken, het zijn er ongeveer twee.

Eh, wel/niet twee fysieke cores; wat ik van HTT begrepen heb, zorgt het ervoor dat ongebruikte delen van de cpu tijdens het verwerken van een thread, nu worden ingeschakeld voor het simultaan verwerken van een tweede thread. HTT verdeelt a.h.w. de threads over alle coredelen, zodat voor het O.S. net is alsof de core zich als zijnde twee cores gedraagt.

Dat in- en uitschakelen van coredelen gaat btw ook - op een geheel ander manier - zorgen voor stroombesparing in de nieuwe Intel Banias processor, die voor 2003 op stapel staat.

[Darkvater]

Met het in gebruik nemen van de nieuwe Intel Xeon processor voor dual- en multiprocessor opstellingen wordt namelijk ook de HyperThreading techniek geïntroduceerd

Ik denk dat dit al genoeg is als antwoord

[paknaald]

Wat ik me afvraag of AMD hier ook een antwoord op zal hebben. Gezien de voorsprong in Mhz van Intel kan zij m.i. veel meer profiteren van multi-threading dan AMD. Ik denk dat deze ontwikkeling op de langere termijn de kloksnelheden tussen de two groten weer dichter bij elkaar zal brengen.

[Beaves]

Ik denk dat deze ontwikkeling op de langere termijn de kloksnelheden tussen de two groten weer dichter bij elkaar zal brengen.

Ik denk het niet, simpelweg omdat de P4 ontwikkeld is met het oog op kloksnelheden met als nadeel een lagere IPC. AMD gaat daarintegen voor een hogere IPC tegenover een lagere kloksnelheid.

De P4 haalt ondanks HTT hele hoge snelheden, want de Willamete en Northwood hebben altijd al HTT aan boord gehad, alleen is dat niet ingeschakeld. HTT is dus geen remmer qua kloksnelheden, daarom zullen de huidige verschillen ook zo blijven qua kloksnelheid.

[Arthur]

AMD schijnt bezig te zijn met Hammers die fysiek twee cores per processor hebben. "Echt" SMP dus op één chip, dat zou je best als antwoord/alternatief op HyperThreading kunnen zien.

Of iig voor zover * 786562 ArthurS

[SG]

Dual core zou AMD antwoord zijn met de Sledge Hammer op intels HTT Xeon volgens geruchten.

Alleen is AMD niet zo Ad Rem en zal het antwoort pas in 2003 komen.

En intel moet met z'n Netburst architektuur 'n duidelijke Clock voorsprong hebben om z'n IPC Performance verlies te compenseren.

[Shaidar]

[omg-modus en ook een beetje heel fel overbodig]

antwoorT ????

[/omg-modus en ook een beetje heel fel overbodig]

[Verwijderd]

Weer eens een goede zet van Intel want doordat
ontwikkelaars hun software zodanig afstemmen dat de kracht van hyperthreading meteen kan worden benut zodra de eerste Xeon processors op de markt komen.
Waardoor mensen sneller de bereid zijn om de Xeon processors tekopen aangezien de nieuwe functies al (volledig) ondersteunt worden door software en dat alles er dus uit gehaalt word wat er in het dingetje zit!

En dat zorgt natuurlijk weer voor betere prestaties.
Wat de consument weer aanzet tot kopen!!

[SG]

Eerst moeten die ontwikkelaars die HTT optimalisaties onder de knie krijgen dat duurt even.

Dan moeten ze dat toepassen bij de volgende en huidige software project Dat duurt ook weer even project cycle.

Dan Moet je die nieuwste versie van je favoriete SMP HTT optimized dan nog kopen en gebruiken dat duurt ook weer even.

Praten we hier over 3Mnd of 6, of zelfs 'n jaar of 2.

Maar in iedergeval leverd HTT ook out of the box al wat extra SMP performance ook al is de software er nog niet voor HTT-optimized.

[joho]

Volgens mij ziet iedereen over het hoofd wat de achtergrond van HyperThreading is. Het ontwerp van een CPU is een afweging van het aantal transistors (afmeting, dus kostprijs van de chip) tegen de gerealiseerde performance.

Twee cores op een chip levert dan geen winst, twee maal zo groot, net geen twee maal zo snel. Een CPU als de P4 heeft een groot aantal 'execution units' (verwerkings eenheden) voor bewerkingen als optellen, aftrekken, vermenigvuldigen enz.

Features als 'instruction re-ordering' en 'speculative execution' zijn ook een investering in extra transistoren om deze verwerkings eenheden aan het werk te houden. HyperThreading is ook zo'n feature. Ten koste van extra transistoren die een extra CPU 'state' (de boekhouding van de huidige toestand) bijhouden kan gebruik worden gemaakt van de verwerkingseenheden die niets te doen hebben.

HyperThreading valt blijkbaar voordelig uit in de transistor count/performance gain afweging.

[sonix666]

He he, eindelijk iemand die het daadwerkelijk begrijpt.

Ik werd al ziek van een discussie die ik op aces hardware hield met een bepaald iemand en die maar niet inzag waarom Intel Hyperthreading introduceerde en waarom je niet gewoon twee processoren zou kopen.

Ik kon die persoon maar niet aan zijn verstand brengen dat Hyperthreading niet als vervanging van meerdere processoren diende, maar alleen bedoeld is om de effectieviteit (performance) van de processor te verhogen.

Welke gek zou 30% extra performance afwijzen voor dezelfde prijs?!?!?

[dataworm]

Wat is eigenlijk het verschil tussen Intel's HyperTreading en dat zoals we het kennen van Mainframes?

[Verwijderd]

<Bezopen mdoe> Goed, ik las eerder vandaag over het AmigOS emulatie wat bemoeilijkt werd door de hoeveelheid chips (processors?) die de oorspronkelijke amigacomputer bezat. Wat wel bleek is dat dmv deze multi-processorachtige omgeving de performance enorm omhoog ging, dat lijkt me ok wel logisch want ipv dat een programma eerst dit uitvoerd, dan dat, dan weer dat...etc, kan ie alles tegelijk uitvoeren. Mijn visonaaire vraag over dit hele gebeuren is dan ook: Waarom maakt intel niet 1 processor die bv. 30 P2's in zich heeft? Heb je zelfs backwards compatitbbiltity, op p2 niveau, en als er wel volledig gebruik van gemaakt zou kunnen worden dan is dat toch veeeeel sneller dan enige andere proc van dit moment...

[tikimotel]

Volgens mij, zit hyperthreading al gewoon in de P4 alleen zal je alle programma's welke je wilt versnellen met deze techniek moet herschrijven en opnieuw compileren...
Dat dicht lassen (disable-en) van de hyperthreading techniek op de P4 daar geloof ik niets van, er werd door Intel gezegd dat hyperthreading van de programmeur een geheel nieuwe techniek van programmeren vereist ipv het zgn platprogrameren meer naar half-parallel...