Intel introduceert Helper Threads in nieuwe compiler

In de release notes van ICC 9.0 bèta is te lezen dat de nieuwe versie van Intels C++-compiler de mogelijkheid heeft gekregen om Helper Threads te genereren. Het doel van deze feature is om delen van een programma die eigenlijk nog helemaal niet geëxecuteerd hoeven worden toch alvast te draaien in een aparte thread, zodat de gegevens die waarschijnlijk even later nodig zullen zijn alvast in het cache komen te staan. De compiler kan zelf plaatsen in de code opsporen waar het nuttig is om de geheugenlatency op deze manier te reduceren. Het komt er op neer dat door het gebruik van Helper Threads applicaties die als één thread zijn geschreven kunnen profiteren van features zoals HyperThreading. In een paar jaar oude publicatie van het bedrijf over het concept worden de mogelijke prestatievoordelen uitgebreid besproken. Destijds zag men al dat bepaalde applicaties op een chip met HyperThreading 7% tot 45% sneller werden door te compileren met Helper Threads ingeschakeld. Voor toekomstige dual- en multi-core chips ligt het overigens een stuk moeilijker. Gedeeld cache en/of een vorm van HyperThreading is een vereiste om profijt te hebben van de techniek, en die features staan voor zover bekend niet gepland voor de notebook- en desktopsegmenten:

Dual-core productfamilie	Gedeeld cache	Multithreading
Itanium	(L3)	(SoEMT)
Xeon / Extreme Edition		(HyperThreading)
Pentium 4
Pentium M

Reacties (17)

[Luxx]

Voor toekomstige dual- en multi-core chips ligt het overigens een stuk moeilijker. Gedeeld cache en/of een vorm van HyperThreading is een vereiste om profijt te hebben van de techniek, en die features staan voor zover bekend niet gepland voor de notebook- en desktopsegmenten

Zou het niet gewoon kunnen zijn dat Intel dit deels ook doet als voorbereiding op Yonah, deze dualcore processor krijgt wel een gedeelde cache en zou dus optimaal moeten kunnen profiteren van deze techniek.
De 'eerstkomende' dualcores hebben vanwege gescheiden caches hier idd 'niets' aan, maar het duurt een flinke poos voordat software volledig van een nieuwe compiler gebruik maakt.

Wat ik me overigens wel afvraag is of deze techniek geen vertragingen op kan leveren voor systemen die er niet van kunnen profiteren, het aantal threads gaat immers omhoog, wat meer overhead op zou kunnen leveren.

Nu ik nog eens in die tabel staat, zie ik de term "SoEMT" staan, EMT was Intels naam voor 64bit x86, maar hier is het iets voor de Itanium, dus dat KAN er niks mee te maken hebben. Iemand die kan uitleggen wat het is?.

[Wouter Tinus]

Zou het niet gewoon kunnen zijn dat Intel dit deels ook doet als voorbereiding op Yonah, deze dualcore processor krijgt wel een gedeelde cache en zou dus optimaal moeten kunnen profiteren van deze techniek.

Yonahs cache is alleen gedeeld als een van de cores uitstaat, anders is het 2x1MB .

[Luxx]

Als ik even google kom ik tot de conclusie dat niet iedereen het daarover een is. Ook in je eigen artikel staat het niet erg duidelijk. Nergens een site die me uitsluitsel kan geven, helaas.

Daarnaast voelt het heel erg tegenstrijdig. Zodra een core de volledige bus tot zijn beschikking heeft, en ook nog eens niet op volle kracht hoeft te werken (anders zou de 2e core wel worden ingeschakeld) ga je hem ineens extra cache geven? Kan je beter nog wat extra stroomverbruik uitsparen en de extra cache ook uitschakelen, scheelt je bovendien ingewikkelde logica die bijhoudt welke cache bij welke core hoort..

[Wouter Tinus]

Cache verbruikt nu al nauwelijks iets, en waarschijnlijk bij Yonah nog veel minder dankzij de sleep transistors in het 65nm-procédé. Het zou dus gewoon zonde zijn om er geen gebruik van te maken. Ik begin nu alleen ook te twijfelen over die splitsing. Ik kan er ook geen uitspraak van Intel zelf over vinden in de IDF-presentaties, alleen dat hij in totaal 2MB cache heeft. Ik weet overigens niet wat ingewikkelder is, logica om het cache aan een andere core te koppelen of logica om twee cores tegelijk in hetzelfde cache te laten lezen, maar mijn gevoel zegt het laatste. Hoe dan ook zou het mooi zijn als het inderdaad gewoon shared blijkt te zijn.

[Luxx]

Ik kan er ook geen uitspraak van Intel zelf over vinden in de IDF-presentaties, alleen dat hij in totaal 2MB cache heeft. Ik weet overigens niet wat ingewikkelder is, logica om het cache aan een andere core te koppelen of logica om twee cores tegelijk in hetzelfde cache te laten lezen, maar mijn gevoel zegt het laatste.

Ik weet heel zeker dat een echte gedeelde cache veel ingewikkelder is, het levert echter wel behoorlijke potentiele snelheidswinst op. Het toevoegen van 1 extra MB cache aan een core die het rustig aan doet, zal nauwelijks extra snelheid opleveren.

[Korben]

SoEMT staat voor Switch on Event MultiThreading, dus het heeft inderdaad wel met multi-threading te maken.

[Verwijderd]

Hyperthreading zat toch (ook) in de P4??

[Wouter Tinus]

Nu nog wel, maar voor de dual-core varianten (behalve dan de Extreme Edition) wordt dat weer uitgeschakeld.

[TheDukemaster]

Inderdaad dus daar zou het ook mee moeten werken. Echter de Dual-Core P4's krijgen geen HT, alleen de EE versie.(vandaar de rode krijsjes bij P4 in het tabelletje, want die slaat op DC cpu's).

[jnice]

dit lijkt me wel enigszins aan de late kant, projecten die dit zullen gaan gebruiken komen uit als er al weer andere features zijn (met een andere implementatie).

[Gogar]

Is dit echt wel een feature? Of is het meer een workaround voor de hoge latencies van het intel platform?

[daft_dutch]

Jammer windows gebruikers
jullie zullen deze feature pas kunnen gebruiken in longhorn + 1
Want het moet gecompileert worden voor een HT processor
en ik denk dat een processor zonder HT het niet kan draaien of langzamer wordt. (tenzij longhorn een HT processor vereist en ze alles gaan hercompileren)

ik als debian gebruiker heb nooit zo veel zin om paketten te optimalizeren. op processor trekkende apps na dan

maar dit moet de gentoo gebruikers hart sneller doen kloppen.

[mxcreep]

Ehmmm...dit hele verhaal gaat op voor Intels eigen compiler...alle packages binnen linux / bsd systemen zijn over het algemeen gecompileerd dmv gcc.
Wil je compilen met de intel compiler ipv gcc zul je ten eerste de compiler moeten kopen en ten tweede een aantal zaken moeten gaan aanpassen om daar gebruik van te kunnen maken, zoals een andere libc en in veel gevallen zul je makefiles moeten aanpassen of specifieke opties moeten meegeven om een andere compiler dan gcc te kunnen gebruiken. Doelmachines voor de binaries moeten ook de intel libc geinstalleerd hebben.

Dus helaas gaat jou verhaal voor linux / bsd gebruikers ook niet zomaar op...

[Superstoned]

MAAR... er werken wel mensen van intel aan gcc, wellicht zullen die zo tof zijn om deze features in gcc te planten

in GCC 4 zou dat niet zo moeilijk moeten zijn, als ik het goed begrepen heb is gcc 4.x veel geschikter voor 'higher level' optimalisaties dan gcc 3.x.

[84hannes]

met een zeker 'risico' dat een deel van dat werk niet voor niets is. Alsof je voor een open boek tentamen alvast gaat leren, zodat je tijdens het tentamen eerder klaar bent, maar 90% van de stof voor niets hebt geleerd...

[jp]

Momenteel doet je processor dat ook al met branch prediction. Daarbij neemt je CPU een (gecalculeerde) gok wat de volgende beslissing van het proces zal zijn.

Heel simpel gesteld, als je binnen een for- of while- lus bezig bent, is de kans veel groter dat je IN de lus blijft, dan dat je uit de lus springt, dus gaat de CPU "alvast" wat rekenwerk daarvoor doen.

Dit lijkt me daar een uitbreiding op.
(Al is compilerbouw zeker niet mijn specialiteit )