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

Door , , 17 reacties
Bron: Intel

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 productfamilieGedeeld cacheMultithreading
Itanium (L3) (SoEMT)
Xeon / Extreme Edition (HyperThreading)
Pentium 4
Pentium M
Moderatie-faq Wijzig weergave

Reacties (17)

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?.
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 :).
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..
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.
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.
SoEMT staat voor Switch on Event MultiThreading, dus het heeft inderdaad wel met multi-threading te maken.
Hyperthreading zat toch (ook) in de P4??
Nu nog wel, maar voor de dual-core varianten (behalve dan de Extreme Edition) wordt dat weer uitgeschakeld.
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).
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).
Is dit echt wel een feature? Of is het meer een workaround voor de hoge latencies van het intel platform?
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.
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...
MAAR... er werken wel mensen van intel aan gcc, wellicht zullen die zo tof zijn om deze features in gcc te planten :D

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.
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 ;))
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...

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True