Codeplay claimt succes met 'autoparallelle compiler'

Op de Game Developers Conference te San Francisco heeft Codeplay een demonstratie gegeven van zijn Sieve-systeem, een C++-extensie voor parallel programmeren. Hoewel de informatie over de demo beperkt is, lijkt het systeem veelbelovend.

Hoewel moderne pc's steeds vaker over meer dan één rekenkern beschikken, is er nog maar weinig software geschikt om die functionaliteit te gebruiken. De meeste programmatuur is nog altijd gebaseerd op een sequentiële verwerking van de instructies, en heeft dus geen baat bij extra processors, cores of shaders. Bovendien is het schrijven van code die efficiënt van extra rekeneenheden gebruikmaakt bepaald niet triviaal. Codeplay beweert dat het voor beide problemen een oplossing heeft: met de Sieve-software hoeft een programmeur alleen nog maar aan te geven welke code geschikt is voor parallelle verwerking. De uitvoering van deze zogeheten 'Sieve-blokken' kan, als de compiler er overheen is gegaan, over een willekeurig aantal rekeneenheden worden verdeeld.

De code die parallel uitgevoerd mag worden, wordt door Codeplays Sieve-extensie geanalyseerd op variabelen die van andere stukken code afhankelijk zijn. Deze gegevens, gedefinieerd als 'data die buiten de scope van het Sieve-blok gedefinieerd is', mogen pas na uitvoering van de geparallelliseerde blokken gewijzigd worden. Het systeem kan code bakken voor x86-processors, de Ageia PhysX-natuurkundeprocessor en de in Sony's PS3 aanwezige Cell-processor. Een korte kennismaking is in pdf-formaat van de Codeplay-site te downloaden; voor hardcore-informatici is tevens een paper met de semantiek beschikbaar.

Op de Game Developers Conference werd een drietal tests uitgevoerd; CRC, Julia Ray Tracing en matrixvermenigvuldiging, die op twee quadcore Intel Xeon 5300-processors, oftewel op acht rekenkernen, werden uitgevoerd. Dat leverde winsten op van respectievelijk 739%, 789% en 660% op ten opzichte van het gebruik van een enkele core. Op een singlecoremachine bleek de geparallelliseerde code wel iets langzamer dan de sequentiële variant, maar met prestatieverliezen tussen de één en zes procent lijkt de performance hit erg mee te vallen. Hoewel er verder nog weinig over de gedraaide benchmarks bekend is, is de belangstelling voor oplossingen voor het efficiënt benutten van multicorearchitectuur groot. Het lijkt dan ook wel zeker dat Codeplay een systeem heeft om scherp in de gaten te houden.

Reacties (51)

Kijk, da's een hele mooie ontwikkeling. Alleen de voorbeelden die ze geven zijn Embarrassingly Parallel.

Dat wil zeggen dat de onderlinge threads geen enkele interactie met elkaar hebben.

Ga je echter iets doen als massive particle interaction of physics, dan heb je wel interactie nodig tussen de verschillende threads.

En daar zijn zo ontzettend veel verschillende technieken voor om dit efficient te krijgen dat dat onmogelijk in een generieke compiler te realiseren is.

Dus voor de 'simpele' parallelisatie is dit inderdaad een hele mooie ontwikkeling.

Maar voor parallele taken waar 'element interaction' nodig is is dit helaas niet geschikt.

Embarrassingly Parallel.

Niet alleen dat, de voorbeelden die ze geven zijn ook echt
"Embarrassing". Ik ga ook echt lekker veel games bouwen waar massaal CRC's in gebruikt worden, laat staan dat ik 400 miljoen Julia Sets als textures ga gebruiken...

Laat ze eerst maar eens een simpele game maken met die compiler, en 739% winst halen ten opzichte van een andere willekeurige compiler, daarna praten we weer verder...

"Dat leverde winsten op van respectievelijk 739%, 789% en 660% op ten opzichte van het gebruik van een enkele core."

winst? dus dat word bij de 100% opgeteld, dan kom je boven 800% en het waren 8 cores ipv een. Er zal dus wel 7,39x zo snel bedoeld worden.

Maar deze winsten zijn echt nice. Een hele goede ontwikkeling, als de programmeur zelf alles over losse cores moet verdelen is het heel erg lastig om dat even redig te doen en zullen er waarschijnlijk vaak 7 cores op de laatste wachten. Een computer kan dit allemaal wel even netjes nagaan

op naar de "heelergveel"core x86

een singlecoremachine bleek de geparallelliseerde code wel iets langzamer dan de sequentiële variant, maar met prestatieverliezen tussen de één en zes procent lijkt de performance hit erg mee te vallen.

Lijkt me geen probleem om ervoor te zorgen dat er helemaal geen performance hit is. Je zorgt er gewoon voor dat de code met Sieve-blokken alleen uitgevoerd worden na een controle of er meerdere rekenkernen aanwezig zijn. (ok, ok, die check is dan een hele kleine performance hit... ) Anders gebruik je de "niet-geoptimaliseerde" code.

dit hoeft toch helemaal niet meer, er zijn bijna geen single cores meer te koop, binnen 1 à 2 jaar heeft elke "moderne" pc 2 of meer cores

Dit zou een keuze bij het compileren moeten zijn, anders heeft het geen zin. Waarschijnlijk heeft de gecompileerde code ook een vertraging door het compileren.
Er moeten dus gewoon twee programma's aangeboden worden en dan in een batch programmatje kijken of er meerdere rekenkernen zijn. of gewoon bij het installeren even kijken welke van de twee geïnstalleerd moet worden.

WTF, alsof dit nieuw is... in HPF (high performance fortran) werkt dit al jaren (sinds 1993) zo...

"alleen maar aangeven wat parallel uitgevoerd kan worden..." dat is juist de hele clou! Je wilt dat de compiler dat zelf ziet...

edit:
@tw-is back: ik neem aan dat je op mij reageert: ja. daar is een commando voor.

Ik vind trouwens ook nog een oude extensie voor C: MPI (Message Passing Interface, sinds 1994). Werkt ook heel goed...

edit2: @.oisyn
Ja, maar dat is ook niet echt nieuw: je kan die MPI extensie ook zo automatiseren... maar goed... compiler is compiler... hoe automatischer, hoe beter, niet? behalve voor de mensen die geoptimaliseerd code schrijven dan, zoals ik.

@Bitage: jij roept toch ook maar "zoiets" "als het geen nieuws was, zou het er niet staan"

edit3:
@die twee onder mij: ja, ik weet er iets meer van dan de gemiddelde boer, ze geven geen MSc. Computer Engineering diploma's aan jan en alleman. Ik vind het dus heel knap dat jullie weten dat ik "de ballen verstand" heb van computer architecture, terwijl dat juist mijn specialiteit is. Maar goed, Ik weet niet wat jullie probleem is, maar ik mis in jullie afzeikverhaal in ieder geval de concrete onderbouwing.

edit4:
@oisyn: heb je door dat je mij beschuldigd van dat ik doe alsof ik het allemaal zo goed weet, terwijl jij dat zelf aan het doen bent? Ik stel alleen aan de kaak dat ik zo op het eerst gezicht niet zie wat hier nieuw aan is. Extensies voor C die parallelle systemen ondersteunen bestaan al. Het enige wat ze hebben gedaan is de compiler iets aangepast. Eigenlijk meer een soort "macro". Maar wat krijg ik voor reacties? Mensen die reageren alsof ik hun moeder heb beledigd.
En verder: als mensen met een WO diploma maar een theoretische onderzoekers zijn, die niets waard zijn in de praktijk, waarom krijgen ze dan wel meer betaald dan HBOers? Ik weet niet welke WOer jou ooit het leven zuur heeft gemaakt, maar jou standpunt is echt onredelijk.

Maar goed een voorbeeld: (hun voorbeeld)
sieve {for (int i=0; i<n; i++) {a [i] = b [i] - f;}}
is in HPF gelijk aan:
_forall (i=0:n)
__a(i) = b(i) - f
_end forall
Dit voorbeeld is, zoals al werd gezegd, embarrassingly parallel. Ik vraag mij bijvoorbeeld af wat de compiler doet met zoiets als:
sieve {for (int i=2; i<n; i++) {a [i] = a \[i-1] + a\[i-2] ;}}
en dat is nog een relatief simpel probleem. Neem bijv. een N-body probleem en het wordt nog complexer. Je kan het partitioneren, maar je blijft de randen houden... veel dataverkeer... lost die compiler vast niet zelf op...
In andere gevallen, bijvoorbeeld wanneer n heel klein is, kost het distribueren van de data over al de CPU's meer tijd dan berekening op 1 CPU had gekost... wanneer de programmeur verwacht dat de compiler dat voor hem uitzoekt en dat dus niet gebeurt, zal zijn code trager draaien.
Als je het tweede voorbeeld ziet, zie je trouwens dat je de code ook moet omgooien voor deze extensie...

Misschien moet je de bron even lezen, dan wordt het al een stuk duidelijker. Je kunt wel een compiler bouwen die dit uitvogelt, maar dit is lang niet zo efficient als het zou kunnen zijn omdat de compiler alleen weet wat de code zou moeten doen, niet wat uiteindelijk de bedoeling is.

De hulp die de programmeur bij dit Sieve systeem moet bieden is minimaal. Hij hoeft alleen maar de juiste codeblokken te markeren waarvan hij het niet erg vindt dat de resultaten pas aan het eind van het totale blok gegarandeerd klaar zijn. Dat helpt het systeem bij het analyseren van het programma en zo worden de taken verdeeld over de beschikbare cores, en kan daarnaast informatie geven over wat te doen om je code beter parallelliseerbaar te maken. Dit alles staat echt in schril contrast met het werk dat je moet verzetten om zelf te zorgen dat je code over meerdere threads verdeeld wordt.

hoe automatischer, hoe beter, niet? behalve voor de mensen die geoptimaliseerd code schrijven dan, zoals ik.

Oh please . Het is wel te horen dat jij nog nooit aan grote commerciële projecten hebt gewerkt. En ik wed dat je alleen maar *denkt* dat je code optimaal is omdat je *iets* van assembly afweet, maar eigenlijk de ballen verstand hebt van hoe ondeterministisch en complex hedendaagse CPUs zijn waardoor jouw schijnend optimale code eigenlijk vol zit met memory- en pipeline stalls. Get a life en wees niet zo naïef door te denken dat jij het allemaal wel beter weet.

.edit2: lol, jij denkt serieus dat een master in computer engineering iets zegt over praktijkervaring? Als je al niet eens snapt dat je op een universiteit wordt opgeleid tot onderzoeker met een theoretische achtergrond, dan denk ik idd dat ze die diploma's aan Jan en Alleman geven ja . Zeker als je hier ook nog eens gaat roepen dat dit "niet nieuw is" terwijl je je schijnbaar niet in hebt verdiept wat dit nou eigenlijk doet.

Desalniettemin ging ik uit van je galery page hier op t.net, daar stond geen software development aangevinkt terwijl je schijnbaar wel de moeite hebt genomen om het in te vullen. Dat, icm "elektrotechniek" bij de opleiding en je professionele ervaring met server- en netwerkbeheer doet mij vermoeden dat je met hele andere dingen bezig bent dan op professionele basis geoptimaliseerde software te schrijven. Klik trouwens gerust op mijn galery page om erachter te komen wat ik in mijn dagelijkse leven doe. Kom met keiharde voorbeelden ipv gaan lopen zwaaien met je papiertje, want dat zegt idd geen zak.

Mijn onderbouwing staat er trouwens al, in de eerste twee alinea's van deze post. Je MPI argument houdt geen stand omdat dat vereist dat je je code omgooit voor dergelijke extensies, net als bij OpenMP ben je nog op een te low-level manier bezig met het parallelliseren, waar ze ook voor zijn ontworpen. De changes voor Sieve zijn echter minimaal en werken juist op een hoog niveau, door je applicatie te analyseren en te doorgronden, om zo te bepalen hoe jouw -sequentieel opgezette- code paths kunnen worden geparallelliseerd, en je bovendien hints te geven over de te verwijderen dependencies om het nog beter parallelliseerbaar te maken.

Het feit dat jij denkt dat dit al bestaat door met HPF of en MPI te komen geeft eigenlijk al aan dat je er geen idee van hebt wat dit nou eigenlijk doet en wat het doel ervan is. En het spijt me zeer, maar daar gaat je diploma je ook niet bij helpen.

ik zou niet zomaar iets roepen, als dit niet nieuw was hadden ze allang die oude methode gebruikt

@ het aepje hierboven: idd het staat er, dus het is nieuws, en dus roep jij zomaar iets over oude methodes. je moet echt niet gaan denken dat je opeens de über-computer-knowledge-lord bent omdat je denkt dat je iets van dat HPF gedoe afweet. echt, als het zou werken, zou er niet iets nieuws uitgevonden worden

Wat dat betreft is er nog een ouder voorbeeld, in OCCAM http://en.wikipedia.org/wiki/Occam_programming_language kon dit al in de jaren 80.
het verschil is vooral dat je bijna je normale code kan gebruiken.
Maar het is nog steeds niet origineel, want ook Rapidmind heeft een soortgelijk product:
http://www.rapidmind.net/technology.php

Sorry, was deze thread helemaal vergeten. Irritant trouwens dat je je follow-ups steeds erbij edit ipv dat je gewoon een nieuwe post maakt, dat discussiert een stuk makkelijker. Ik wil de discussie laten voor wat het is, maar nog wel even reageren op dit stukje:

En verder: als mensen met een WO diploma maar een theoretische onderzoekers zijn, die niets waard zijn in de praktijk, waarom krijgen ze dan wel meer betaald dan HBOers? Ik weet niet welke WOer jou ooit het leven zuur heeft gemaakt, maar jou standpunt is echt onredelijk.

Je interpreteert mijn post weer helemaal verkeerd en je legt woorden in mijn mond. Waar zeg ik dat onderzoekers niets waard zijn in de praktijk? Nergens. Ook schijn je te denken dat ik het heb over WO vs. HBO, ook dat is niet het geval. Ik heb het over opleiding vs. praktijk. Opleiding is over het algemeen theoretisch. Op een opleiding leer je dat quicksort en mergesort het best zijn omdat ze O(n log n) zijn. In de praktijk leer je dat O(n log n) lang niet altijd beter performt dan een (theoretische) O(n²), en dat je dus bij een kleine n beter voor een shellsort kunt gaan. Als jij derhalve denkt dat je wel optimale code schrijft omdat je WO gedaan hebt zit je er gewoon naast, en wapperen met je diploma heeft dus totaal geen zin.

Overigens, ik ben dan wel Ing. maar ik heb ook WO gedaan, mind you. Alle vakken gehaald met goede cijfers, maar ben er vlak voor m'n scriptie mee gestopt wegens het kunnen krijgen van mijn droombaan (meewerken aan de 3d engine van Tomb Raider: Legend en upcoming games). Ik denk dus allesbehalve minachtend over WOers, ik zeg slechts dat een opleiding alleen ook niet alles is.

Nu nog een aanpassing dat je ook Code kan draaien op een X1k kaart en G80 kaarten.

Ik weet niet wat voor een instructies de cell allemaal kan doen maar die reken units kunnen zeker niet alles. Dus misschien is er ook iets te maken voor de moderne VGA kaarten.

En de dingen die de vga kaarten dan niet kunnen dan aan de cpu geven of zo. Ik weet niet in hoeverre dat mogelijk is ? Of misschien laten kijken of bepaalde code op een VGA kaart gedaan kan worden. Want als dat kan zal hij vele malen sneller zijn dan een quad core.

Ontzettend off topic:

SPU's zijn in sommige opzichten nog veel beter dan de PPU die er in zit.

DMA in, DMA uit en processing tegelijk draaien. M.a.w: ik doe 3 dingen tegelijk. De PPU kan dat absoluut niet.

Simpel voorbeeldje: Memcpy op een SPU. Ik moet de eerste PPU implementatie nog tegenkomen die dit sneller kan dan een SPU. Op de SPU is dat een simpele DMA transfer, op de PPU mag je het allemaal zelf overhengelen.

Er is gewoon een C/C++ compiler voor de SPU's, dus ja, ze kunnen wel degelijk hetzelfde als de PPU. Over het algemeen draait normale C++ code iets langzamer op een SPU, maar dat maakt niet uit, want je hebt er 6!

Weer een klein beetje on topic:

Wat betreft de claim dat CodePlay een compiler heeft die x86 code kan produceren, PhysX code _en_ Cell PPU / SPU code?

Ik schat dat het gewoon een frontend parser is die weer C / C++ genereert die weer door de standaard compiler gecompileerd wordt.

Anders petje af hoor, dat je voor 4 architecturen een compiler weet te ontwikkelen en onderhouden.

edit: typo's

Ik weet niet wat voor een instructies de cell allemaal kan doen maar die reken units kunnen zeker niet alles. Dus misschien is er ook iets te maken voor de moderne VGA kaarten.

De SPUs kunnen geen koffie zetten nee, maar ze hebben wel de vrijheid van normale CPUs (met als nadeel dat ze alleen direct bij hun 256k local store kunnen, maar er zijn ook instructies om main mem reads en writes te schedulen). Dit itt de shaders op een GPU, die veel meer gelimiteerd zijn in wat ze doen. Het is ook niet dat elke shader een apart programmaatje draait. Het zijn wel meerdere threads, maar ze voeren allemaal (of iig in groepen) dezelfde code uit.

Onderaan in het artikel staat Coldplay. Dat moet Codeplay zijn denk ik. Heb Coldplay nog niet zien softwarebrouwen.

Edit: Het is aangepast.

Maar wel nette software, alleen snap ik niet hoe dit het ei van columbus is voor al onze threadingprobleempjes met meerdere processors. Dan is het wel heel knap gemaakt.

Ik heb het paper even gelezen. Het is nog niet zo knap als je misschien zou denken als je dit bericht leest.

Het principe is simpel; Je vertelt de compiler dat een stuk code parallel moet worden uitgevoerd (zoals bij OpenMP bijvoorbeeld ook). Vervolgens bekijkt de compiler welk deel hij parallel kan doen. Daarbij worden
zoveel dependencies als mogelijk gebroken. (Vandaar ook de naam sieve, wat "zeven" betekent) Tussenresultaten worden in een dependency wachtrij weggeschreven. Na afloop van het block worden deze afgewerkt zodat het resultaat ontstaat dat oorspronkelijk bedoeld was.

CodePlay kan bijvoorbeeld nog niet omgaan met optimalisaties voor delayed writes en kan ook nog geen delen ondersteunen, omdat in dat geval delingen door nul dependencies zouden ontstaan die ze schijnbaar nog niet op kunnen lossen.

Ray-tracing is natuurlijk ook een slecht voorbeeld; daar zijn vrijwel geen dependencies, omdat het per scanline uitgevoerd kan worden.

Leuk, maar ik ben nog niet helemaal overtuigd.

Inderdaad niet zo bijzonder als ze het laten klinken. Als je zelf iets multithreaded maakt moet je OOK kijken welke delen in aanmerking komen. Zorgen dat variabelen die buiten de thread af en toe gelezen moeten worden protected zijn op de juiste momenten is wat het moeilijk maakt. En dat is NOOIT te automatiseren, tenminste niet verder dan het nu al is: de programmeur geeft aan op welke plekken dingen gelocked moeten zijn.

Zij kunnen alleen grafieken maken (X&Y)
maar het is al aangepast zie ik (zag het ook, maar na F5 niet meer)

Het systeem kan code bakken voor x86-processors, de Ageia PhysX-natuurkundeprocessor en de in Sony's PS3 aanwezige Cell-processor.

En daarna nog voor de grafische kaarten.

Als het kan op die Ageia dan moet het op een Graka ook niet zo moeilijk zijn daar deze ook als physx kaart kunnen worden gebruikt.

Die opmerking klinkt me in de oren als mannen en vrouwen kunnen allebei praten, vrouwen kunnen menstrueren dus mannen kunnen het ook.

Dat ze beide physics kunnen berekenen, betekent nog niet dat de achterliggende architectuur niet compleet anders is, lijkt me. Zo makkelijk te porten zal het dus wel niet zijn. Bovendien kan een videokaart wel physics berekenen, maar kan het die informatie niet terugsturen naar de CPU, hij kan het alleen maar weergeven. Als ik het mij goed herinner was dat het grootste verschil tussen graka physics en Ageia PhysX.

Een mooie framework als ik het zo lees, maar het 'auto' gedeelte van de 'autoparallelle compiler' moet dus wel handmatig worden geholpen:
- Het ontwerp dient rekening te houden met het kunnen opdelen van blokken
- De programmeur moet handmatig aangeven wat parallel uitgevoerd kan worden

Dit framework houdt dan rekening met synchronisatie als het gaat om gebruik van gedeelde variabelen en zorgt dus voor het aanmaken van parallele rekentaken.

De ontwerper / programmeur dient dus nog steeds iets goeds neer te zetten, en kan er dus nog steeds een zooitje van maken of de efficientie te niet doen door lekker veel externe data afhankelijkheden waardoor de andere parallele blokken geblokkerd worden...

Hoe dan ook: als framework in handen van een goede ontwerper / programmeur een prachtig hulpmiddel

Een C++ programmeur help zo-ie-zo al de compiler. Wil je automatisch garbage collection dan die je __gc aan je procedure definitie toe te voegen.

Verder worden veel code delen alleen gecompileerd als aan en conditie wordt voldaan zoals '#IF WIN32'

En verder is het natuurlijk ook niet zo lastig om een
sieve block aan je code toe te voegen. Vanwege de complixiteit van threading en asynchoon programmeren worden weinig lussen parallel uitgevoert.

Games maken veelvuldig gebruik van lossen en matrix structuren. En in dat opzicht vallen ook de prijzen van de compiler mee.

Wil je automatisch garbage collection dan die je __gc aan je procedure definitie toe te voegen.

Sorry hoor, maar programmeurs die garbage collection nodig hebben kunnen beter thuis blijven.. .

Sorry hoor, maar programmeurs die garbage collection nodig hebben kunnen beter thuis blijven.. .

Beetje een onnozele opmerking. Er zijn situaties waarin garbage collection niet alleen heel erg handig is maar ook nog eens efficienter dan handmatige memory management. Denk aan algoritmes die een enorme hoeveelheid kleine allocaties uitvoeren in stukken code waar runtime performance het enige criterium is. Een garbage collector met voldoende mogelijkheden tot sturing kan in zo'n situatie de overhead van deallocatie uitstellen tot een punt waarop voldoende CPU tijd over is.

Om nog maar niet te spreken over het beperken van leaks, dubbele frees etc...

Een beetje boute uitspraak.

Wees blij dat je tools aangeboden krijgt en basale werkzaamheden uit haden nemen. Ik moet er niet aandenken dat ik m'n huidige werk in assembly moet verrichten. Een automatische GC is ook een van die tools.

Of zoals Don Box zei: "Hier heb ik een rode en een blauwe pil. als je de rode pil neemt kom je in de realiteit terecht (de wereld van assembly), als je de blauwe pil neemt blijf je in de Matrix virtuele wereld waarin je allerlij 'coole wapens hebt, en waar je kunt vliegen etc. (automatische GC!). Geef mij maar de blauwe pil, wie wil er nu in assembly programmeren!?"

Natuurlijk geen reden om 'stom' te programmeren. Maar een automatische hulp bij het paralleliseren zou erg welkom zijn.

Denk aan algoritmes die een enorme hoeveelheid kleine allocaties uitvoeren in stukken code waar runtime performance het enige criterium is.

Als dat het geval is moet je niet iedere bit opnieuw dynamisch alloceren maar meteen een voldoende groot buffer alloceren en dat steeds hergebruiken. Dat is efficienter dan een gc.

@johanw910
Mee eens, garbage collection is rete handig aangezien het de ontwikkeltijd enorm kan verminderen en ook de kans op fouten, maar als performance een issue is dan is op een goede manier zelf implementeren van memory management sneller. Overigens zijn er sandbox tools waarmee memory leaks prima te volgen zijn...

Jij doet alles met assembly?

Goede ontwikkeling, als dit niet al te moeilijk te gebruiken is voor de ontwikkelaar kan dit zijn/haar leven een stuk makkelijker maken.

Ik zou wel graag wat meer benchmarks willen zien, zoals bijvoorbeeld de implementatie van dit in een bestaande reken-intensieve applicatie. Maar resultaten van meestal meer dan 700% (oftewel 7/8ste van het theoretisch maximale) zijn in ieder geval veelbelovend.

Je kunt theoretisch op N processoren meer dan Nx sneller rekenen doordat vanaf een zekere N de data-set waarop je rekent in je CPU cache past.

Erg merkwaardig, als je een programma op 16 nodes uitvoert en je een speedup meet van 30x...

Auke

Is dit niet hetzelfde als OpenMP?

http://en.wikipedia.org/wiki/OpenMP

Nee, bij OpenMP moet je zelf aangeven wat en hoe er verdeeld wordt over meerdere cores, het zal je code niet analyseren zodat iets wat lijkt op een enkele thread verdeeld wordt over meerdere threads. Het werk wat je bij Sieve moet doen is veel en veel minder.