AMD helpt ontwikkelaars een handje met multicores

Chipfabrikant AMD heeft dinsdag een nieuwe specificatie geïntroduceerd die ontwikkelaars moet helpen hun software beter gebruik te laten maken van multicores.

Door de specificatie, genaamd light-weight profiling (pdf), kunnen applicaties die zijn geschreven voor Java of .Net direct communiceren met de hardware. Zodoende ‘weet’ de software hoeveel rekenkracht er nog beschikbaar is. Applicaties moeten nu het besturingssysteem aanspreken om te kijken hoeveel rekenkracht er nog beschikbaar is. Lwp zorgt ervoor dat deze stap overbodig wordt door de applicatie direct te laten zien welke resources beschikbaar zijn.

Volgens AMD zijn dergelijke mogelijkheden vooral interessant voor runtime omgevingen als Java en .Net, die voor een groot deel van de applicaties worden gebruikt als ontwikkelomgeving.

‘AMD begrijpt de uitdagingen die ontwikkelaars hebben bij het ontwikkelen van multithreaded software’, zegt Earl Stahl, vicepresident softwareontwikkeling bij AMD. ‘We nemen daarom de stap om nieuwe methoden te evolueren en ons zo te verzekeren dat applicaties zijn geoptimaliseerd voor multicore-technologie.’

De lwp-specificatie is onderdeel van het recent geïntroduceerde AMD-initiatief ‘Hardware Extensions for Software Parallelism’. Volgens de chipfabrikant is lwp zo ontworpen dat het code in staat stelt dynamisch en realtime beslissingen te nemen om zo de lopende taken optimaal uit te voeren.

Reacties (38)

[H!GHGuY]

Ik heb even enkele stukken van de pdf doorgelezen en het lijkt me een nogal onvolledige stuntelige voorzet te zijn. Er zitten mijns inziens teveel gaten in:
- Nergens staat welke processoren dit effectief ondersteunen. Ik neem aan dat alle processoren die op dit moment op de markt zijn deze processor-instructies niet hebben. (Barcelona en varianten mss?)
- Er staat ook vermeld dat Windows Vista op dit moment APIC hooks verbiedt en ze dus nog een probleem op te lossen hebben. Ook een andere issue was niet gesupporteerd om Windows. Over linux geen woord te bespeuren.
- Er staan nog enkele andere belangrijke issues als "to be defined"

Misschien ligt dit aan mij maar dit is nogal een slordige draft om te publiceren.

[Verwijderd]

- Nergens staat welke processoren dit effectief ondersteunen. Ik neem aan dat alle processoren die op dit moment op de markt zijn deze processor-instructies niet hebben. (Barcelona en varianten mss?)

Al sinds de Pentium hebben x86-processors een CPUID-instructie.
Daar kun je oa opvragen hoeveel cores/threads je hebt.
Die APIC-functionaliteit vertelt je het een en ander over het aantal sockets/CPUs.
Dit bestaat ook al heel lang.

Ik krijg de indruk dat dit in de eerste plaats gewoon een stukje gestandaardiseerde code gaat worden op bestaande hardware.
Misschien dat AMD dan in de toekomst hun CPUID-instructie uitbreidt met nieuwe functionaliteit, die dan ook weer in deze library opgenomen wordt (de CPUID wordt sowieso bij bijna iedere nieuwe CPU verder uitgebreid).

Hoe dan ook, het idee spreekt me wel aan, en het lijkt me ook wel haalbaar.
Aangezien AMD ook .NET wil betrekken in dit idee, zal Microsoft zich vast wel behulpzaam opstellen tov die APIC-issues. Ze zouden daar bv een module voor kunnen bouwen, zodat ze het in eigen hand houden, en die aanbieden via Windowsupdate. AMD kan daar dan weer verder op bouwen.

[H!GHGuY]

Je hebt blijkbaar die pdf niet goed gelezen.

er komen 2 nieuwe instructies bij om LWP aan te sturen.
CPUID dient enkel om te kijken of de processor capabel is om LWP instructies te krijgen.

Waarschijnlijk zullen ze dus toch degelijk een driver moeten schrijven zoals je aangeeft.
En daar is dan reeds weer het einde van 'de applicatie kan rechtstreeks de hardware aanspreken'.

[martijnvanegdom]

mm.. en hiermee verpiept AMD het uitgangspunt van Java.. Java is hardware onafhankelijk bedoeld.. Daarvoor is het hele JVM en Just In Time Compile principe gebruikt.. Nu gaan we dus java apps krijgen die weer echt hardware afhankelijk zijn.. great.

"Applicaties moeten nu het besturingssysteem aanspreken om te kijken hoeveel rekenkracht er nog beschikbaar is. Lwp zorgt ervoor dat deze stap overbodig wordt door de applicatie direct te laten zien welke resources beschikbaar zijn."

Ook dit is niet leuk.. Dit soort dingen horen via het OS.. daar is een OS voor bedoeld.. Ik vind het echt goed dat AMD focus gaat leggen op multi-core ontwikkelen maar dan wel graag niet door software direct hardware te laten aanspreken.. daar is he OS voor en niks anders..

[Reactie gewijzigd door martijnvanegdom op 24 juli 2024 07:43]

[catfish]

lijkt mij niet, een Java prog blijft altijd binnen de VM
volgens mij willen ze dus gewoon de VM's van Java en .net aanpassen

even opgezocht:

The goal is to enable modules such as dynamic optimizers and managed runtime
environments to monitor the currently running program with high accuracy and resolution, thereby allowing them to report on performance problems and opportunities and fix them immediately.

het is dus een manier om de VM de recources beter te laten gebruiken

[Reactie gewijzigd door catfish op 24 juli 2024 07:43]

[BasieP]

Waarom?

Wanneer ik een programma schijf in C, en ik houd rekening met verschillende videoresoluties ben ik toch ook niet hardware afhankelijk?

Dat wil zeggen, tuurlijk ben je in feite afhankelijk van hardware, dat kan niet anders. Je moet gewoon aannemen dat je bepaalde dingen kunt doen. Niemand maakt zich er tegenwordig druk om dat je software resoluties van 1900 bij weetikhoeveel ondersteund. Dit is toch alleen maar mooi?

Zo is het ook met deze code. Het ondersteund de multicore AMD CPU functies. Dat is toch alleen maar mooi?

In dit geval maak je code die (INDIEN AANWEZIG) extra functionalteit/snelheid toevoegd aan je code.
Wanneer je de software dan alleen nog maar op AMD multicore cpu's kan draaien doe je als programeur echt wat fout.

[Reactie gewijzigd door BasieP op 24 juli 2024 07:43]

[danielsrje]

Ik denk dat martijnvanegdom bedoelde: platformonafhankelijk.

[kiang]

erm, neen

Ten eerste Java is bedoeld om volledig platform onafhankelijk te zijn, dat wil dus zeggen zowel onafhankelijk van het OS als van de hardware. (Eigenlijk zorgt het OS al dat apps sowieso hardware onafhankelijk kunnen werken, maar daar kom ik later op terug...)
AMD's hulp zal enkel effect hebben op hoe de VM (en dus niet de apps, die blijven hetzelfde) omgaat met de hardware.
Je zegt dat hardwareaanspreking eigenlijk via het OS moet gaan, en daar heb je een punt. Net zoals objectgeoriënteerd programmeren en virtualisatie maakt dit alles een stuk makkelijker. Maar vergeet niet dat dit ten koste gaat van performance.
Zo zal je bijvoorbeeld geen enkele 3D-game vinden die de hardware niet zelf aanspreekt, gewoon omdat het efficiënter is en beter te optimaliseren voor de applicatie.
Het resultaat zal dus zijn dat java vor het gebruik van multicores niet meer de weg app-->VM-->OS-->hardware maar app-->VM-->hardware moet afleggen, wat beter performance tot resultaat heeft.
Ik juich hierbij dus even voor AMD

[JKVA]

Multi core development is tot nu toe net als concurrency/threading een heel erg ondergeschoven kindje geweest bij Java en volgens mij ook .NET.

Een initiatief vanuit de hardwarefabrikanten is volgens mij een goed teken. Ik zie geen problemen qua platformonafhankelijkheid. JVM's bevatten namelijk sowieso platformafhankelijke code. Het feit dat AMD een voorzet doet voor uniformiteit op dit gebied juich ik voor 100% toe.

Nu nog hopen dat er uniformiteit komt tussen Intel en AMD, maar dat zal wel een utopie blijven.

[Ilmar]

Java weet ik niet, maar .NET bevat wel heel wat, vooral relatief eenvoudig te implementeren threading functies, 't zou heel mooi zijn als de runtime daar extra optimalisaties aan kan geven.

[i-chat]

treading is natuurlijk leuk maar de vraag is deels ook naar welke core, als je als ap slecht of geen zicht hebt over hoeveel resources je op dat moment krijgt, is 't efficief treaden natuurlijk een probleem,

[JKVA]

En dan maakt een specificatie (al is het voor een beperkte set processors) het voor JVM bouwers gemakkelijker om dergelijke low level optimalisaties door te voeren. Die wil ik niet als applicatieontwikkelaar allemaal kennen (tenminste, ik wil ze wel kennen, maar niet MOETEN kennen).

De JVM kan al veel zaken optimaliseren, zoals het reordenen van instructies, maar op dit niveau is er volgens mij nog niet veel gebeurd.

Het zou mooi zijn als Intel, AMD en de andere hardwarebouwers naar een uniforme interface gaan. Daar heeft iedereen baat bij (vooral applicatieontwikkelaars), maar ik ben bang dat ze dat niet willen, uit angst dat ze gevoelige informatie met de concurrenten gaan delen of zichzelf vastpinnen aan een dergelijke specificatie.

[Bacchus]

Dat zou ik eigenlijk juist lekker door het OS laten uitzoeken, daar zit je scheduler in ahgi. De VM geeft alleen maar een paar threads op die hij wil laten draaien.

[Quacka]

Als je goed leest dan lees je dat nu het besturingssysteem gevraagd wordt hoeveel processorkracht beschikbaar is.
Wanneer je die stap er tussenuit haalt dan zorg je ervoor dat e.e.a. minder platformafhankelijk geschreven hoeft te worden. Dit lijkt mij dus een grote vooruitgang.

Ik lees nergens dat dit ervoor zal zorgen dat een java-applicatie alleen met AMD-processors gebruikt kan worden. Hooguit dat het sneller is met een amd-processor. Maar een nieuwtje: De snelheid van een applicatie is nu al best afhankelijk van de hardware van de gebruiker. Dat is dus niets nieuws.
Overigens kan het ook zijn dat e.e.a. werkt voor AMD maar ook voor Intel.

edit:
Wat ik bedoel, martijn, is dat je (ga ik vanuit) linux op een compleet andere manier zal moeten aanspreken, dan dat je windows aan moet spreken.
Wanneer je die stap over kan slaan door het direct aan de hardware 'te vragen', dan moet het toch beter gaan. Je hoeft wat dat betreft dan geen onderscheid te maken tussen Linux, windows (etc).
Alleen is het dan wel gewenst dat alle hardware-producenten die techniek dan ondersteunen. Maar als er niemand begint, dan gebeurt er hoe dan ook niets.
Uiteindelijk nemen de bedrijven vaak genoeg technieken van elkaar over.

[Reactie gewijzigd door Quacka op 24 juli 2024 07:43]

[martijnvanegdom]

Nee die stap is juist meer platform afhankelijk!

Stel ik heb een App die vraag nu aan linux de rekenkracht op.. Linux draait op i386 / x86_64 , PPC en nog een heel stelletje platform.

Stel ik heb een App die aan de hardware om de rekenkracht en ik gebruikt de AMD methode.. Dan ben ik gelimiteerd aan AMD hardware of op zijn minst aan i386 / x86_64.. Ik weet niet hoe je er bij komt dat die platformonafhankelijker zou zijn..

btw.. met platform (hardware) word niet het OS bedoeld maar de architecteur van de hardware

[i-chat]

wat jij zegt klopt echter maar te dele, want wat je er bij vergeet is, dat in software de ene keuze de andere niet uitsluit, als deze amd tool echt zo goed is, kun je als developer, best kiezen om deze functie wanneer aanwezig te beruiken, en de standaard als dit nie werkt...

dacht geeft SLECHTS op bepaalde systemen een snelheids winst, en dat is alleen maar mooi, vooral als deze amd (en misschien ook intel) functie in de JRE word ingebouwd, zodat 't daarmee generieker word voor java. (en een zelfde voor NET natuurlijk)

[roy-t]

Psuedo code:

If processor vendor = AMD then
'lalala ikg a nu direct aanspreken
End if

Net zoals

If operatingsystem = Linux then
'doe de linux manier/linux dll van het checken van resources per core
else:
'doe de windows manier
End if

duzzz? dan kan 1 ifje er nog wel bij lijkt me!

[Verwijderd]

Het moet dan ook in het OS blijven zitten.

Het artikel suggereert het anders maar het blijft vooral een OS taak.

Requirements
The following are requirements for LWP to operate properly with modern operating systems (OS):
1. Identifiable: The OS must be able to detect whether LWP is available and, if so, which profiling features are present.
2. Globally Enabled: The OS must enable LWP if it wants to allow programs to interact with it. By enabling LWP, the OS commits to context switching the profiling state. By enabling profiling interrupts, the OS commits to handling them.
3. Secure: No data on the operation of the OS may “leak” to any user process. No data on the operation of one user process may leak to any other process.
4. Separable: The hardware mechanisms for LWP do not interact in any way with the existing performance counters or instruction-based sampling.

Zolang je target OS er geen ondertsteuning aan geeft heb je er niets aan.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 07:43]

[Verwijderd]

mm.. en hiermee verpiept AMD het uitgangspunt van Java.. Java is hardware onafhankelijk bedoeld.. Daarvoor is het hele JVM en Just In Time Compile principe gebruikt.. Nu gaan we dus java apps krijgen die weer echt hardware afhankelijk zijn.. great.

Ik denk dat het vooral gaat om dingen als detecteren van het aantal CPUs en het aantal cores.
Dit doe ik in mijn C++-applicaties ook. Ik weet namelijk dat mijn code het beste loopt als ik evenveel of minder threads heb dan het aantal cores. Mijn code is zo geschreven dat ik het aantal threads dat ik wil gewoon als parameter kan meegeven (de gebruiker kan dit ook aanpassen als hij wil).
Ook kan ik rekening houden met eventuele NUMA-configuraties, en het geheugen lokaal per CPU/thread indelen, om het zo efficient mogelijk te maken.

Op dit soort details heb je bij Java en .NET tot dusverre geen zicht. Het zou een goede zaak zijn als hier een standaard voor zou komen. Dat betekent dus helemaal niet dat je Java-code platform-afhankelijk wordt.
Denk eerder aan zoiets als:
for (int i = 0; i < LWP.getNrOfCores(); i++)
addWorkerThread();

[humbug]

Als ik even naar J2EE kijk kun je dit prima afregelen via de settings van de applicatieserver. Al ben ik het niet met je eens dat je even veel threads als cores moet hebben. Vaak staan threads op andere zaken te wachten (andere servers, IO) waardoor het juist zinvol is om meer threads te hebben. Tuurlijk als je puur een uur aan het rekenen bent kun je best wel eens gelijk hebben, maar de meeste applicaties doen een hoop meer.

[Verwijderd]

Ik heb het hier over een enkele applicatie die veel rekent, inderdaad, en waar ik de workload opdeel in zoveel stukjes als dat ik cores heb, en dan voor ieder stukje een identieke thread opstarten.
Een multithreaded job, zogezegd. Ik doe maar 1 ding, maar wil dat zo snel mogelijk doen.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 07:43]

[narcan]

Het zou het mooiste zijn als de abstractie begint op cpu niveau, een virtuele cpu dus aka vpu en daarop de kernel waar de process/task scheduler zaken als parallelisme kan regelen. Ben je van dat hele hardware gezeur af..

[RoBBS]

Ik denk dat er een heleboel multicore gebruikers blij worden als er echt eens een massa aan software beschikbaar komt die multithreaded werkt. Ikzelf merk de meeste vooruitgang tijdens het gebruik van linux maar dat komt natuurlijk door de modulaire opzet. En zo'n 3 jaar na de introductie van multicore's mogen de windows gebruikers er natuurlijk ook wel eens van genieten.

Wat ik me alleen afvraag, is het geen riskante zet om de programmatuur zelf de beschikbare resources te laten inzien (en beheren?). zonder een overkoepelend systeem dat de verdeling bijhoudt kan er wel eens eea misgaan toch?

[catalisator]

ja maar daar moet de programmeur dan weer ff rekening mee houden en dus moeten checken, daarbij komt dat het wel een handeling scheelt. want als hij nu aan windows vraagt hoeveel recourses er nog beschikbaarzijn moet windows de aanvraag verwerken uitvoeren en rapporteren, nu kan je software zelf even kijken hoeveel recourses er beschikbaar zijn, scheelt dus ook weel een hoop tijd en je hou daarmee weer wat meer "windows " over om andere dingen te doen.

dus ik denk goed bezig, ik ben geen amd fan, maar dit is zeker wel een goede straat om eens even onder de loep te nemen.

zoals ik in het vorrige amd bericht ( de lening van 1,5 miljard ) al schreef, laten we eerst maar eens kijken waar amd over 1 a 1 1/2 jaar staat.!

[Rey Nemaattori]

Tis niet hardware afhankelijk...je kan 't nogsteeds zonder AMD dualcore draaien

Netzoiets als HT optimalisatie bij software enige jaren terug. 't draaide prima op AMD en VIA processoren, alleen op een P4 met HT liep het nét ietsjes beter....zo ook deze ontwikkelomgeving.

[catalisator]

ja maar er staat ook niet dat ze hardware afhankelijk zijn jongens, er staat alleen dat het prog zelf uitkanlezen hoeveel recourses er nog vrij zijn en wat hij dus KAN gebruiken.!

[captain007]

Mwah, dit vind ik niet echt handig, aangezien dit niet voor Intel Multicores opgaat. Als ik wil weten hoeveel cores een CPU heeft, kan ik nog beter via Windows de Systemaffinity opvragen dan deze AMD interface gebruiken. Dat werkt tenminste op zowel Intel als AMD systemen wat je software niet te platformafhankelijk maakt.

@sinsester:
Bij de AMD64 standaard is het zo dat Intel die grotendeels heeft overgenomen als EMT64. Echter ontbreken daarbij enkele instructies, dus het verbaast mij niets dat dit een AMD only feature is.

[Reactie gewijzigd door captain007 op 24 juli 2024 07:43]

[Sinester]

het zal vast niet zo zijn dat het opeens niet meer op een intel werkt...
het is hoogstens zo dat het op een amd net even wat beter gaat.

ik kan trouwens niet terug vinden of dit alleen voor amd multi cores opgaat of voor multi cores in het algemeen?

[BasieP]

jij moet je kennis eens bijspijkeren.
Zowel Java als .NET zijn redelijk snelle omgevingen, die voor normale applicaties niet onder doen voor C++ apps.

Je zit gewoon onwaarheden op een nogal flamerige manier te spuien..

[Xenan]

SuperDre schrijft wel wat op een flamerige toon maar toch heeft hij wel gelijk. .NET en Java draaien trager dan native C++. Ik programmeer in beide dus heb vergelijk.

Het is waar dat bepaalde routines vrijwel net zo snel draaien als native, maar andere zaken gaan juist weer supersloom.

Probeer maar eens in een .NET applicatie een tabel van meer dan 1000 records te cutten en te pasten naar Excel. Dat duurt tientallen minuten! Zonder .NET is het een kwestie van seconden. Overigens denk ik niet dat dit aan C# zelf ligt maar aan de bibliotheken.

Daartegenover staat dat C# veel sneller en makkelijker programmeert dan C++.

[humbug]

In principe is native natuurlijk sneller dan een systeem met een VM als java en .net. Echter, in praktijk zijn de verschillen redelijk klein. Jou copy paste probleem ken ik namelijk bv totaal niet. Gewoon een kwestie van onhandige code dus.

Theoretisch heeft de JIT compiler van Java/.Net trouwens ook een voordeel boven native apps. Doordat de compiler kan leren hoe bepaalde functies in praktijk gebruikt worden kan er beter geoptimaliseerd worden in vergelijking met de statische afweging die de C++ compiler moet maken. Hierdoor zou de applicatie dus uiteindelijk effectiever (en dus sneller) kunnen zijn dan een C++ applicatie. In praktijk komt dit echter niet (of nauwelijks) voor.

Uiteindelijk zijn de performanceverschillen over het algemeen irrelevant en is performance dan ook geen echt argument meer om de keuze op te baseren.

[Rey Nemaattori]

euh...mijn ervaring met java is anders...ma goed dat kan ook aan de ontwikkel omgevingen hebben gelegen....

[the_shadow]

Ik weet niet hoe het met .Net zit, maar als je een Java programma een beetje degelijk in elkaar steekt, dan draait het na het laden van de JVM als een tierelier. Als je het hebt over Java GUI's dan geef ik je volledig gelijk, die werken vaak minder soepel dan de native GUI's (hangt vaak ook nog eens af van de ontwikkelaar, er zijn immers wel programma's op de markt die een goede GUI in Java hebben).