AMD van start met wedstrijd in poging multithreading te stimuleren

AMD heeft een wedstrijd opgezet om de ontwikkeling van multithreaded software te stimuleren. De wedstrijd heeft de naam Multicore Threadfest meegekregen en gaat 12 maart van start met een prijzengeld van 20.000 dollar.

De processorfabrikant heeft het bedrijf Topcoder in de arm genomen om de wedstrijd verder uit te werken. Multicore Threadfest is door AMD in het leven geroepen om de ontwikkeling van multithreaded applicaties voor multicoreprocessors aan te sporen. "Aangezien multicoreprocessors praktisch gemeengoed zijn geworden, willen we de softwareontwikkelaars steunen bij het inschakelen van de nieuwe hardware", aldus Earl Stahl, vice-president van Software Engineering bij AMD.

AMD is van mening dat de productiviteit van softwareonwikkelaars omhoog geschroefd kan worden. Door gebruik te maken van multicore-cpu's kan ingeklopte code sneller gecompileerd worden, waardoor een ontwikkelaar meer tijd aan de code kan besteden en er een efficiëntere ontwikkelingscyclus zou ontstaan. Multicore Threadfest wordt vanaf 12 maart elk kwartaal van dit jaar gehouden en de evenementen zullen 'enkele weken' duren. Ontwikkelaars kunnen hierbij een geldprijs van 250 tot 2500 dollar winnen.

Reacties (32)

[DingieM]

Het begint bij een besturingssysteem dat van nature al hevig multithreaded werkt EN de hardware continue en nuttig gebruikt.
Zelfs nu nog is het legendarische BeOS qua architectuur superieur aan de rest.
Alhoewel men programmeert in BeOS met C++, men dan ook wel met threads moet werken. Dus het concept - multithreading - blijft complex, zeker met dynamische programma's.

Hoop toch dat Haiku binnen afzienbare tijd praktisch te gebruiken zal zijn...

[El Cid]

Tja, het is al langer duidelijk dat het 'paralleliseren' van software, verre van triviaal is. Gelukkig zijn een aantal van de belangrijkste taken juist wel goed multithreaded te maken. Bij games bijvoorbeeld, wordt er veel met matrices gerekend, en dat kan goed parallel. Ook grafische programma's zoals Photoshop en 3ds Max kunnen hun taken goed verdelen over meerdere threads.

[.oisyn]

Bij games bijvoorbeeld, wordt er veel met matrices gerekend, en dat kan goed parallel

Euh, nee. In het algemeen heb je wel gelijk - matrices kun je goed parallel uitrekenen. Maar de matrices die games gebruiken zijn gelimiteerd aan 4x4 matrices, en die parallel verwerken geeft meer overhead dan dat het winst oplevert (het kost in feite ook maar een paar SIMD instructies om matrices te vermenigvuldigen). Er zijn natuurlijk wel bepaalde processen in een game die goed te parallelliseren zijn, maar gewoon "met matrices rekenen" is een slecht voorbeeld. En doorgaans hoef je ook niet heel veel matrices met heel veel andere matrices of vectoren te vermenigvuldigen (alleen voor rendering, maar dat doet de vertex processor van de GPU al).

[martinusbach]

Alleen 4x4 matrices in games? Dat lijkt me sterk. Als je differentiaalvergelijkingen numeriek gaat oplossen (physics berekeningen uitvoeren dus), heb je al heel snel veel grotere matrices. En die kun je inderdaad in stukken hakken en verdelen over meerdere cores, al valt het niet mee om de verschillende losse stukken (die ergens toch van elkaar afhankelijk zijn) weer aan elkaar te knopen (lastig te programmeren).

[.oisyn]

Physics in games is doorgaans niet zo exact als in de natuurwetenschap, en wordt er over het algemeen gekozen voor erg versimpelde numerical solvers die snel zijn, makkelijk te implementeren zijn en er voor het oog goed genoeg uitzien. Een leuk voorbeeld: een wateroppervlak dat realistisch golft als de speler er doorheen beweegt. Nou kun je natuurlijk dat oppervlak modelleren met een soort heightmap waarbij je idd differentiaal en integraalvergelijkingen op de vertices loslaat, maar in werkelijkheid gebruiken games gewoon een simpele blur kernel wat een realistisch-ogende rimpeling geeft. En dat wordt dan vaak nog op de GPU uitgerekend ook. Het meest time-consuming van physics in games is overigens meer de collision detection, niet zozeer de physics zelf. Maar er zijn natuurlijk altijd wel uitzonderingen .

[Reactie gewijzigd door .oisyn op 8 augustus 2024 18:16]

[RemcoDelft]

Ik verbaas me er nog steeds over dat iets als Firefox niet multithreaded is! Het werkt met meerdere tabbladen, wat kan de beperking zijn dat elk tabblad niet gewoon z'n eigen thread heeft? Als ik Firefox opstart, en 10 tabbladen laat herstellen, duurt dat een paar seconden. Dat lijkt me prima uit te smeren over m'n beide cores.
Zelfs als ik een nieuw window open, "wacht" dat window op activiteit van het andere Firefox-window, oftewel tabbladen werken niet onafhankelijk van elkaar, en dat lijkt me met multithreading prima op te lossen.
Ter vergelijking: als ik er een Firefox naast start, als andere user, krijgt het uiteraard wel een nieuwe thread! Vanwaar dan die keuze om het allemaal bij elkaar te betrekken?

[barfieldmv]

Waarschijnlijk word er wel met een 10 tal threads gewerkt maar zijn die zwaar van elkaar afhankelijk waardoor de wacht tijden ontstaan.

Zeker als je een filmpje start of een zware flash animatie moet dat wel multi threaded.

Opera
5 tabs 12 threads

Firefox
5 tabs 11-18 threads

Iexplore 8.0 beta
5 tabs 19-23 threads

Het aantal threads als je op refresh klikt stijgt ook nog eens snel.

[borft]

waarschijnlijk de standaard nadelen van multithreaden, zoals bijvoorbeeld synchronisatie, resource gebruik, complexiteit, etc..

[Rey Nemaattori]

Moet dat niet multiprocessing zijn?

Ik dacht nl. dat je threads niet op verschillende cores kan draaien, maar processen wel?

[jmzeeman]

Nee, threads kunnen ook gewoon op verschillende cores draaien. Een thread en een process hebben allebij hun eigen stack, programcounter, registers e.d. Het verschil tussen een process en een thread is dat een process ook een eigen memoryspace heeft en een thread binnen de memoryspace van zijn process draait.
@graey:
Inderdaad, ik denk zelfs dat je wel kan stellen dat vrijwel elk x86 OS met thread en process support dit ondersteund, aangezien dit onderdeel van het OS vrijwel volledig door intel wordt gespecificeerd in de IA32 system programming guide.

[Reactie gewijzigd door jmzeeman op 8 augustus 2024 18:16]

[Rey Nemaattori]

Ja, maar hoe share je een cache tussen 2 threads als ze allebei op een core zitten met eigen cache? (zoals in de wiki staat die H3llraiser aanleverde) Want de kracht van threads is toch juist dat je geen ander proces met program counter&mem space etc. etc. hoeft te laden.

[jmzeeman]

Als er een gedeelde cache is, share je de cache gewoon niet, dat is ook niet wenselijk aangezien beide threads andere code uitvoeren en dus andere gedeeltes van het geheugen in de cache willen hebben staan. Wat dan wel belangrijk is is dat het OS (of het programma) ervoor zorgt dat de threads bij taskswitches steeds weer op de zelfde core terecht komen.
De kracht van threads is dat het een stuk gemakkelijker en ook goedkoper(qua performance) is om te communiceren tussen de threads. De overhead van een process ligt hem vooral in de memory space en de informatie nodig voor address translation. Elke thread heeft wel degelijk een eigen programcounter deze geeft namelijk aan waar een thread in een programma is.

[H3llrais3r]

als ik dit artikel goed begrijp gaat het over Time slicing.....


http://en.wikipedia.org/wiki/Thread_%28computer_science%29

dat zou gaan over vroegere single core systemen.

nu willen ze het op Multi core systemen hebben. Het idee hier achter is om de programmeurs aan het denken te zetten om MultiCore (parallelle) programma's te schrijven. Dit wordt dezer dage weinig tot niet gedaan. het O.S. bepaald D.M.V. time slicing nogsteeds het dualisme wat er eigenlijk niet is. De schakeltijd van de processoren zijn zo klein dat het LIJKT of het multithreaded is.

EXAMPLE:

P4 northwood -> Windows + Media player + MS. office word.

als de media player continue de processor tijd zou op eisen omdat je, je mp3 zonder gestotter wil horen of streaming media zonder de lag wil zien, zou windows met zijn X-aantal background services vast lopen -> geen processor tijd, en zou je geen word document kunnen maken, de processor heeft daar gewoon weg geen tijd voor.
met time-slicing wel. -> deel draaiende programma's op in hele korte "Bursts" de threads worden dus wel tijdelijk gesuspend

[Reactie gewijzigd door H3llrais3r op 8 augustus 2024 18:16]

[onetime]

jammer, niet goed begrepen... (H3llrais3r)
wel de klok horen luiden maar niet de klepel weten te vinden.

als ik dit artikel goed begrijp gaat het over Time slicing.....

nee, het gaat over multithreading; een applicatie opdelen zodat het parallel kan worden uitgevoerd. (dat kan je op een single core simuleren dmv time slices, ja) dat gaat op een multi-core dus veel sneller, omdat het echt parallel gaat

[Squee]

Je shared zo'n cache ook niet, maar je hebt wel een cache-coherency protocol om te zorgen dat de caches van de andere cores geupdate worden. Een multithreaded applicatie die de hele tijd in het zelfde stukje address-space zit te lezen/schrijven vanuit alle threads zal dus ook niet echt veel baat hebben bij een multicore, omdat er steeds gecommuniceerd moet worden tussen de caches.

[graey]

Volgens mij kan windows (en linux trouwens ook) verschillende threads netjes toewijzen aan verschillende cores...

[Reactie gewijzigd door graey op 8 augustus 2024 18:16]

[dasiro]

inderdaad, je kan dit zelfs als user ook zelf doen door in taskmanager de afinity van een proces toe te wijzen aan een bepaalde core. Echt veel doet het niet echt, maar da's iets anders

[Verwijderd]

Van een process inderdaad, maar niet van een thread.

[H3llrais3r]

Ik denk dat ze wel degelijk multiThreading bedoelen:

Kijk hier maar
http://en.wikipedia.org/wiki/Multithreading

[brompot758]

Door gebruik te maken van multicore-cpu's kan ingeklopte code sneller gecompileerd worden, waardoor een ontwikkelaar meer tijd aan de code kan besteden en er een efficiëntere ontwikkelingscyclus zou ontstaan.

Met 'make -j 2' of een andere waarde die je aantal cores weergeeft kan dat al heel lang. Maar aangezien een beetje normale programma compile (nee niet een Linux kernel) tegenwoordig ook single threaded seconde werk is omdat je alleen de gewijzigde sources maar compileert zie ik de winst niet zo.

Alleen bij grote programma's die ik wel compileer maar niet zelf aan ontwikkel op dat moment (libraries en zo) gaat het beduidend sneller. Maar dat is meestal eenmalig compileer werk.

[Verwijderd]

Xcode ondersteunt al lange tijd dat je de compile kan uitsmeren over meerdere Macs mbv XGrid technologie.

Ook als ik WebKit compile dan staan beide cores flink te stampen, maar toch duurt het ongeveer nog 15 minuten om een build te krijgen.

[Sh1va]

@ Jawad:

http://tweakers.net/gallery/sys/16461

Hoe kan in jij godsnaam een CPU overklokken als je het verschil tussen een geluidskaart en een HDD niet eens weet? (geluidskaart: HDD:1.2TB SamSung)

On topic:
Nu ben ik zelf geen programmeur, maar wat ik wel weet is dat AMD en Intel constant bezig zijn elkaar te overtroeven met hun multi-core processors, ik als gebruiker van een dual-core AMD merk er bar weinig van. Slechts enkele games, zoals bijv. Quake 4 of Supreme Commander profiteren van meerdere cores. Ik vind het dus ook een goed idee dat AMD deze wedstrijden organiseert. En als intel klantgerichter wil werken dan kunnen ze beter goed naar de underdog kijken.

[GENETX]

Opzich alle nieuwe games gebruiken het wel, ETQW, UT3, Crysis etc etc zijn allemaal multicore.

[Daisuke]

Niet om Jawad te verdedigen, maar in zijn profiel staat

"Geluidskaart: (Lees: staat niks bij)"
en dan pas "HDD: 1,2TB SamSung"

Dus eerst lezen, dan posten.

[eijckron]

De ultieme oplossing voor al die extra cores in de thuis situatie lijkt me toch de mogelijkheid om meerdere schermen, keyboards en muizen aan te sluiten zodat de PC door meerdere personen tegelijk gebruikt kan worden. Ik vind het ook erg vreemd dat Microsoft dat niet als feature in Vista heeft zitten.

[Sh1va]

De ultieme oplossing voor al die extra cores in de thuis situatie lijkt me toch de mogelijkheid om meerdere schermen, keyboards en muizen aan te sluiten zodat de PC door meerdere personen tegelijk gebruikt kan worden. Ik vind het ook erg vreemd dat Microsoft dat niet als feature in Vista heeft zitten.

Daar zou ik zelf niks aan hebben, ik heb liever dat al mijn applicaties van alle cores gebruik kunnen maken als dat nodig is (bij zware belasting een extra core gebruiken). Maar het zou wel de ideale gebruikerstest zijn om te zien of je pc "echt" optimaal van multi-thread gebruik maakt.

[TheLunatic]

Als het niet is om op te scheppen, wat is dan de meerwaarde van je post? En wat heeft overclocking te maken met programmeren voor multithreading? Ik kan ook een snellere fan op m'n processor schroeven en m'n voltages opkrikken, maar dat maakt me nog geen programmeur.

Wat die tekst betreft: misschien moet je even de directie bellen, die passen het meteen voor je aan!

[4ourty2]

Ten eerste.
Overclocken heeft niks met multi-threading te maken .
Ten tweede:
Dit lijkt mij juist wel een opschepperige post.
Ten derde:
Wat is de meerwaarde van jouw post?

Ontopic:
Dit vind ik een goed initiatief van AMD alleen vind ik de geldprijzen die te winnen zijn wel vrij laag.