Steeds vaker duikt de stelling op dat programmeurs moeten leren omgaan met tientallen, honderden of duizenden threads. Sun heeft met de Ultrasparc T2 laten zien dat dat een hele kudde relatief trage threads in veel servertests effectiever kan zijn dan een paar hele snelle, mits deze voldoende gebruikt worden.
Op dezelfde lijn gaat men voorlopig nog even door. Recent is aangekondigd dat de opvolger van de T2 maar liefst 256 threads krijgt verspreid over 16 cores. Al langer bestaat het plan om servers met vier en acht sockets uit te brengen, wat betekent dat het voor het eerst mogelijk wordt om relatief kleine servers met 2048 threads te bouwen.
Hoewel de "T3" op 45nm gebakken zal worden, is het bijna onmogelijk dat Sun het aantal threads kan verviervoudigen zonder het verbruik opnieuw te verhogen en/of in te boeten op de prestaties per thread. Het zal interessant zijn om te zien wat voor compromissen het bedrijf heeft gesloten om deze volgende stap te zetten en hoe zich dat laat vertalen naar prestaties.
Slimme steen
Zelfs Sun is echter niet van mening dat ieder probleem opgelost kan worden met meer threads. De 'Rock'-processor, die in 2009 moet verschijnen, valt weer terug naar een bescheidener aanpak met vier cores, die ieder vier subcores hebben met twee threads, voor een totaal van 32 threads per chip. Daarnaast zijn er nog 32 zogenaamde 'scout threads' die proberen vooruit te lopen op de hoofdthreads om er voor zorgen dat data alvast in de caches wordt geladen. Naar verluidt kunnen de scouts ook verruild worden voor normale threads, zodat de software er 64 ziet.
Naast betere prestaties per thread door de hogere kloksnelheid van 2,3GHz en de scout threads zal Rock ook een feature introduceren die het samenwerken van de threads voor programmeurs makkelijker maakt: transactioneel geheugen. Dat houdt in dat de geheugencontroller een serie van lees- en/of schrijfopdrachten kan doen die pas zichtbaar worden voor andere threads zodra de hele serie is voltooid. Een half resultaat uitlezen is dus sowieso niet mogelijk en als twee transacties met elkaar conflicteren (bijvoorbeeld als ze naar dezelfde plek schrijven) wordt er één automatisch afgebroken en herstart.
Voor programmeurs is dit een uitkomst: in plaats van iedere keer dat twee threads elkaar kunnen kruisen de prijs van een 'lock' te betalen, zorgt transactioneel geheugen ervoor dat de prestaties alleen lijden op het moment dat het écht fout dreigt te gaan. Deze feature is geen eindoplossing voor de problemen die komen kijken bij het schalen naar meerdere threads, maar wel een stap in de goede richting die mogelijk ook zijn weg naar andere architecturen zal vinden.
