[alg] Gebruik maken van multiple cores

[MBV]

LauPro schreef op maandag 10 november 2008 @ 17:55:
[...]
Het is gewoon pertinent onwaar dat mensen geen snelheidsverschil merken bij een dual core tov single core systeem. Als je een OS zou schrijven waar alles in 1 thread draait (non-smp) dan heb je gelijk, alleen de huidige moderne OS'en zijn nu eenmaal smp en dus is er per definitie een snelheidswinst met multi core systemen vs single core. Verder is het single core concept in de grotere rekencentra al decennia afgeschreven, het is gewoon de initiatiefloosheid van de processorfabrikanten dat er nu pas (afgelopen jaren) multi core processoren op de markt zijn, die hadden 10 jaar geleden al moeten bestaan. Toen moest iedereen namelijk dure 2way systemen kopen met exotische chipsets voor een beetje performance.

Ik zei dus ook: upgraden vanaf een Core2Duo. Met 2 cores kan het OS+services op 1 core draaien, en jouw applicatie op de andere. Met 2 tot een aantal zware apps tegelijk kan zelfs 3-4 cores nuttig zijn. Maar daarboven zal de software multithreaded moeten worden om performancewinst te halen.

[...]
Dan heb je de strekking van op opmerking niet helemaal begrepen, want Java bijvoorbeeld is de afgelopen tijd hard op weg om alle Java software gewoon per definitie threadable te maken en ook veel functies te bieden die de developer ondersteunen. Tevens loopt QT imo erg voorop als het gaat om toolkitintegratie van threads.

Ok, dan was jouw 'fingerpointing' nog zinlozer dan ik al dacht. De tools ondersteunen het dus nog breder dan ik dacht, dus het is nu tijd om het in de applicaties te gaan toepassen.

[...]
Je ontkracht jezelf een beetje, je hebt altijd een threadmanager nodig als je een deftige threaded applicatie hebt, ik ben van mening dat dat een taak is van het platform danwel de toolkits.
[...]

En die zijn er ook. Als ze er niet zijn is het niet eens zo moeilijk om er eentje te schrijven, volgens mij. De vraag is of hij dan beter wordt dan die van windows

Ik zou het niet weten en eerlijk gezegd zelf zo'n oude koe lekker laten liggen .
[...]

Punt 1: heel veel code is nog in Fortran/COBOL geschreven, helaas. Porten is lastig, dus dan moet je iets anders doen.
Punt 2: het was een high-level taal die eigenlijk niet eens veel meer met Fortran/Cobol te maken had. Door de constructies die erin zaten was het heel eenvoudig om multi-threaded te schrijven. Eenvoudiger dan in C.

Daar is toch niets mis mee? Hell er zijn zelfs libs die gewoon nog niet threadsafe zijn, wat heeft het dan in godsnaam voor een nut om je applicatie alvast te threaden, het blijft een keten met afhankelijkheden.

Als die er zijn, maak je een singleton om zo'n lib heen, zodat er maar 1 functie tegelijk aan kan roepen. Hoe heette dat pattern ook al weer? Anyway, dat kost even een paar minuten om die code te schrijven, of een kwartiertje voor een regex die X functies onder elkaar zet.

[...]
Ik heb het nergens over het automatiseren van optimalisaties maar wel dat de implementatie van bijvoorbeeld een threadmanager in toolkit/platform hoort te zitten en niet in de applicatie (ja uitzonderingen daargelaten). Als je op deze manier geforceerd expliecite multithreading (zoals Confusion dat zo mooi zegt) gaat invoeren dan voorspel ik een hoop ononderhoudbare code. Het staat buiten kijf dat als je threads wil toepassen in je applicatie de architectuur en de datastructuren in je applicatie wel threadsafe moeten zijn (wat vaak ingrijpende consequenties heeft).
[knip]
Paralleliseerbaar maken is iets waarbij je door je platform/toolkit moet worden ondersteund anders blijf je wielen opnieuw uitvinden.

Je legt net zelf aan mij uit dat de toolkits er prima op voorbereid zijn, wat is het nou En anders zoek je toch een betere toolkit op, zoals Qt.

[.oisyn]

Soultaker schreef op vrijdag 14 november 2008 @ 15:48:
Overigens zitten in in de Windows C library wel minder/andere dingen dan in glibc. glibc bevat behalve de standaard C library ook allerlei POSIX en gereleateerde functies zoals sockets, terminals, process control, enzo. Windows heeft daar vaak hele andere API's voor die in andere libraries zitten (b.v. winsock voor sockets). Daarintegen zitten in de MSVCRT wel weer allerei C++ functies die juist weer niet in glibc zitten. Al met al is de vergelijking dus een beetje van appels met peren.

Ik snap het doel van je alinea niet, tenzij je gewoon aan het nitpicken bent. Het ging om thread-safety van standard libraries. Wat boeit het welke dingen daarin staan. Ik mag hopen dat de C++ runtime libraries van GNU ook thread-safe zijn. En de win32 API is verder ook thread-safe. Het feit dat ik even dacht dat glibc alleen over de CRT ging maakt m'n punt toch verder niet minder valide, of wel? Dus waarom appels en peren, het gaat toch allebei om standaard support libraries, met beide zo goed als dezelfde inhoud?

[ Voor 47% gewijzigd door .oisyn op 14-11-2008 16:47 ]

[Soultaker]

Het gaat me er om dat het niet zo zinnig is om te zeggen "library X is niet threadsafe" als je niet aangeeft waar het probleem 'm dan in zit; een C library met wat unsafe legacy functies lijkt mij geen probleem als die beperkingen duidelijk gedocumenteerd zijn. Een C library waarvan malloc()/free() niet threadsafe zijn, is veel meer problematisch.

Daarom vroeg ik ook aan Exirion om welke functies het dan ging; als het een of andere rare API is die niet eens in MSVCRT zit, dan gaat de vergelijking wat dat betreft niet op (vandaar: appels met peren).

Ik mag hopen dat de C++ runtime libraries van GNU ook thread-safe zijn.

Wat betreft de GCC implementatie zijn bijvoorbeeld alle methoden op container classes alleen thread-safe (en reentrant) zolang meerdere threads op verschillende instanties van de containers werken, en moet je anders zelf synchroniseren; dat is ook by design. Is het dan thread safe of niet?

[.oisyn]

Is het dan thread safe of niet?

Tja daar kun je natuurlijk hele discussies over voeren. Ik vind de functies threadsafe als ze niet intern een een of andere (niet threadsafe) resource aanspreken die een andere thread ook aanspreekt, ongeacht de parameters die je meegeeft. Als je vervolgens die threadsafe functie vanuit meerdere threads aan gaat roepen met gelijke parameters (zoals bijv. de this-pointer) dan is dat in veel gevallen natuurlijk vragen om moeilijkheden.

[flowerp]

MBV schreef op maandag 10 november 2008 @ 13:06:
[...]
Sterker nog: zij zijn eerst. MySQL schaalt best aardig tot iets van 8 cores, MSSQL vast nog veel beter, en PostgreSQL heeft al helemaal geen moeite met veel cores. De DB kan vaak prima schalen over meerdere cores.

Dat is waar, maar vanuit een bepaalde hoek. MySQL en PostgreSQL kunnen alleen schalen over meerdere cores voor verschillende queries. Beiden kunnen niet 1 enkele grote query over meerdere cores verdelen, ook al zie je als programmeur dat dat logisch gezien wel zou moeten kunnen. Oracle en MSSQL kunnen dat wel, en kunnen dat ook al geruime tijd.

Iniedergeval voor PostgreSQL zijn er zelfs voor de middellange termijn geen plannen om dit te ondersteunen. De wil is er wel, maar de mankracht en gedeeltelijk de expertise mist gewoon (blijkt uit mailinglists en is me ook vertelt door een PG comitter die ik op een conference tegenkwam).

Er zijn wel wat add-on dingetjes voor PG die dit een beetje mogelijk maken, maar automatisch gaat het allerminst. Zelf je query opsplitsen en in je Java/PHP/C++/etc code weer samenvoegen kan soms een oplossing zijn, maar gooit wel al je transactionele garanties de deur uit.


[/quote]
maar dat effectief maar 2 cores werden gebruikt o.i.d. omdat de zware taken maar zelden werden uitgevoerd. Dan zat iemand dus minuten te wachten op resultaat, terwijl er 7 cores iets uit hun neus haalden
[/quote]

Inderdaad, dat blijft een probleem. Nu kan het niet optimaal gebruik maken van de cores nog een beetje 'opgevangen' worden door het feit dat IO traag is (ook al zou je programmatisch alle 8 cores benutten, dan gaat IO vaak een bottleneck vormen in DBs). Aangezien SSD's er aan zitten te komen en ik deze in de toekomst groot wil gaan inzetten, zal de IO bottleneck een stuk minder worden en zal de CPU weer een bottleneck vormen. Het niet gebruiken van alle 8 cores voor 1 probleem zal dan -nog- zwaarder wegen...

[MBV]

IO is bij databases heel vaak geen bottleneck meer. De meeste relevante queries (geen historische statistieken, waar mensen best wel even op willen wachten) komen uit het geheugen, en daar geldt zeker dat de processor de bottleneck is. Een beetje database-server heeft flinke hoeveelheden RAM, toch?

offtopic:
en bij MySQL moet je echt uren en uren prutsen met de parameters, gebruikt hij alsnog maar 512MB van de 4GB

[flowerp]

MBV schreef op zaterdag 15 november 2008 @ 11:20:
IO is bij databases heel vaak geen bottleneck meer. De meeste relevante queries (geen historische statistieken, waar mensen best wel even op willen wachten) komen uit het geheugen, en daar geldt zeker dat de processor de bottleneck is. Een beetje database-server heeft flinke hoeveelheden RAM, toch?

Dat valt nog absoluut tegen. De DBs waar ik mee werk zijn niet extreem groot (in de range van 100 tot 200 GB) en het geheugen is juist wel redelijk groot (enkele machines met 32GB en enkele met 48GB RAM voor de 200GB DB). Dat wil zeggen, ongeveer een kwart van de DB past volledig in het geheugen.

Je hebt natuurlijk gelijk dat zeer veel recent opgevraagde data door het geheugen wordt opgevangen. Als je een nog niet eerder uitgevoerde (zware) query draait kost dat b.v. 30 seconden, daarna nog maar 5 a 6 seconden. In dit voorbeeldje wil je wellicht toch snellere I/O om de cold performance te verbeteren. 30 seconden blijft lang, zeker als gemiddeld de data die op deze query betrekking heeft zo'n half uur in het geheugen blijft. Het verkeerspatroon dat wij zien zorgt er voor dat ongeveer na een half uur grote gedeeltes van de cache alweer vervangen zijn door andere data. Die 5 a 6 seconden die je bij caching nog ziet, is een mooi voorbeeld van een geval waar het gebruik van meerdere cores deze tijd nog zou kunnen verkleinen.

Daarnaast, blijven we zien dat I/O over de hele mix van alle operaties toch een bottleneck blijft en writes moeten natuurlijk sowieso zo snel mogelijk naar je storage gaan.

[MBV]

Inderdaad, er zijn applicaties waarbij dat niet zo werkt. Welke database werken jullie nu mee? De verschillende caching-stragieën van verschillende databases kunnen natuurlijk veel uitmaken in zo'n situatie. MSSQL wint veel benchmarks omdat ze zo ongeveer al het geheugen voor cache alloceren.

Writes wil je inderdaad zo snel mogelijk hebben: voordat de COMMIT geslaagd is

[flowerp]

MBV schreef op zaterdag 15 november 2008 @ 13:37:
Inderdaad, er zijn applicaties waarbij dat niet zo werkt. Welke database werken jullie nu mee?

PostgreSQL (8.3) op Linux. Linux alloceerd al het beschikbare geheugen hoe dan ook voor caching, nog onafhankelijk van je DB caching instellingen.

[H!GHGuY]

flowerp schreef op zaterdag 15 november 2008 @ 13:41:
[...]
PostgreSQL (8.3) op Linux. Linux alloceerd al het beschikbare geheugen hoe dan ook voor caching, nog onafhankelijk van je DB caching instellingen.

Je DB mag niet rekenen op de cache van linux wanneer het om writes gaat. Er zal dan meestal ook wel een sync/fsync of equivalent gedaan worden. Je wil niet dat je DB alsnog corrupt gaat omdat je OS de boel heeft gecached wanneer de stroom uitvalt. toch?

[Confusion]

H!GHGuY schreef op zaterdag 15 november 2008 @ 13:52:
Je DB mag niet rekenen op de cache van linux wanneer het om writes gaat.

Het ging dan ook over een read cache. Als een Linux systeem een tijdje draait, is al het geheugen gealloceerd als cache.

Je wil niet dat je DB alsnog corrupt gaat omdat je OS de boel heeft gecached wanneer de stroom uitvalt. toch?

Dat ligt maar helemaal aan de database. Afhankelijk van de performancewinst die een write-cache levert kan je er voor kiezen het risico van een corrupte database te accepteren. Niet voor iedere applicatie is het verlies van een transactie ernstig; het ligt aan de kosten die het verlies van zo'n transactie opleveren tegenover de kosten van het performanceverlies om de writecache uit te schakelen.

[ Voor 5% gewijzigd door Confusion op 15-11-2008 14:00 ]

[flowerp]

.oisyn schreef op vrijdag 14 november 2008 @ 17:40:
[...]
Als je vervolgens die threadsafe functie vanuit meerdere threads aan gaat roepen met gelijke parameters (zoals bijv. de this-pointer) dan is dat in veel gevallen natuurlijk vragen om moeilijkheden.

Inderdaad, ik denk dat het eerder ging om 'hidden' global dependencies. Daar ging het om functies, maar in de object wereld zou zich dat vertalen als: ik maak in 2 aparte threads een nieuwe instantie aan van een object, maar als ik een call doe naar een method van die objecten blijken ze toch iets (intern) te delen.

Qua threadsafeness van objecten (en feitelijk ook globale functies) heb je diverse mogelijkheden om dit op te lossen. In Java kun je b.v. alles synchronized maken, maar dat is dikwijls schieten met een kanon op een mug. Veel beter is het dikwijls om de situaties dat iets geshared wordt expliciet bij te houden, en dan in een critical section de operaties op het shared object uit te voeren (dit dus in plaats van alle operaties op het object synchronized maken).

In sommige gevallen, met name als het om een kleine hoeveelheid data gaat, is het maken van copies een betere strategie. Je hebt dan 1 source van je data en elke (parallele) client die erom vraagt krijgt een copie.

Vanaf Java 5 (al weer enkele jaren oud) is er zoals al eerder gezegd, veel support in de std lib bijgekomen. Zo heb je b.v. dingen als de ConcurrentHashMap, die je bijna zonder meer kunt sharen en waarbij binnen een bepaalde limiet geen locking plaats vind voor concurrent operaties:

A hash table supporting full concurrency of retrievals and adjustable expected concurrency for updates.[...] However, even though all operations are thread-safe, retrieval operations do not entail locking, and there is not any support for locking the entire table in a way that prevents all access. [...]

Retrieval operations (including get) generally do not block, so may overlap with update operations (including put and remove). Retrievals reflect the results of the most recently completed update operations holding upon their onset.

Deze ConcurrentHashMap (en de gelijkwaardige varianten voor andere structuren), kan ik ondertussen niet meer uit mijn parallelle applicaties wegdenken. Het process van het opdelen van je logica en algortimes in delen is amper veranderd hierdoor, maar de implementatie is echt veel makkelijker geworden.

Het zelfde verhaal geldt voor dingen als de BlockingQueue, een conceptueel simpel ding, wat vele parallelle operaties veel makkelijker maakt. Ook dingen als de CyclicBarier en de Exchanger kan ik al bijna niet meer zonder. Zie http://java.sun.com/j2se/...rent/package-summary.html.

Specifiek zou ik ook nog even op de concurrent.locks package willen wijzen. Java heeft vanaf het begin altijd al het synchronized keyword gehad, echter dit ding is redelijk all-or-nothing, Met de programmatische varianten in de locks package kun je veel meer, zoals testen of de lock er al is en een timeout opgeven hoe lang je wilt wachten op de lock.

Zonder al deze hulpjes (dus feitelijk alleen met synchronized, Object.wait en Object.Notify) is parallel programmeren inderdaad niet altijd makkelijk, maar door slim gebruik te maken van het geen de std lib biedt wordt het echt veel meer behapbaar

[Alarmnummer]

Confusion schreef op maandag 10 november 2008 @ 12:51:
[...]

Ik voel eigenlijk zelden de noodzaak tot expliciete multithreading. Ik heb nog nooit een applicatie multithreading gemaakt omdat ik uit performance overwegingen voor 1 gebruiker zijn load over meerdere cores wilde spreiden. De enige reden om applicaties multithreading te maken was om asynchrone communicatie met andere systemen mogelijk te maken, om de responsiviteit te verhogen.

Je kan je cores toch prima benutten door gebruikers parallel af te handelen?

Wat als je meer cores hebt dan concurrent gebruikers. 10 concurrent gebruikers met 100 cores waarbij iedere gebruiker op een core draait heeft een load van 10%. Een nieuwere cpu (met dus meer cores) zal geen snelheids winst opleveren. Dus uiteindelijk heeft de 'thread per user' schaalbaarheids problemen.

[oeLangOetan]

Microsoft heeft zijn oplossingen voor concurrency voorgesteld op PDC, nu zijn de videos beschikbaar, je kan ze hier (http://blogs.msdn.com/pfxteam/) bekijken. Vooral de C++ implementatie lijkt me zeer interessant.

[Confusion]

Alarmnummer schreef op donderdag 20 november 2008 @ 11:20:
Wat als je meer cores hebt dan concurrent gebruikers. 10 concurrent gebruikers met 100 cores waarbij iedere gebruiker op een core draait heeft een load van 10%. Een nieuwere cpu (met dus meer cores) zal geen snelheids winst opleveren. Dus uiteindelijk heeft de 'thread per user' schaalbaarheids problemen.

Uiteindelijk wel, maar je loopt denk ik eerder tegen een andere limiet op: die van de nuttige CPU capaciteit per user. Als ik maar 10 concurrent gebruikers heb, waarom zou ik dan een processor met 100 cores kopen (of als ik niet minder kan kopen: jammer dan, maar dan zal het ook niet veel kosten, in tegenstelling tot andere serveronderdelen, die wel beperktende factoren vormen)? Ik moet wel erg mijn best doen om per user een volle core in beslag te nemen. De latency in de communicatie met andere servers is meestal veruit de belangrijkste factor in het bepalen van responsiviteit.

[MBV]

@Confusion: juist daar kan multithreaded een rol spelen. Als je niet alles sequentieel afhandelt, maar opdeelt in mooie kleine blokjes en die parallel doet, zal het makkelijker zijn om de HDD en netwerkverbindingen vol te krijgen, toch? Nu zal je vaak hebben dat hij eerst iets op zijn hdd zoekt, daarna rekent, daarna netwerk, daarna rekenen, en daarna weer netwerk. Als je met parallelle threads werkt zal dat vaker overlappen

[Confusion]

MBV schreef op dinsdag 25 november 2008 @ 10:10:
@Confusion: juist daar kan multithreaded een rol spelen. Als je niet alles sequentieel afhandelt, maar opdeelt in mooie kleine blokjes en die parallel doet, zal het makkelijker zijn om de HDD en netwerkverbindingen vol te krijgen, toch? Nu zal je vaak hebben dat hij eerst iets op zijn hdd zoekt, daarna rekent, daarna netwerk, daarna rekenen, en daarna weer netwerk. Als je met parallelle threads werkt zal dat vaker overlappen

Ik heb het over situaties waarin alle I/O al concurrent gedaan wordt, voorzover mogelijk. Waarin je dus alleen nog concurrency toevoegt om algoritmen te parallelliseren die keiharde rauwe CPU power nodig hebben. Die heb ik nog nooit nodig gehad en ik vraag me af of ik dat ooit nodig ga hebben.

[MBV]

Ik voorzie dat binnenkort (binnen 5 jaar) I/O een veel kleinere bottleneck gaat worden met SSD's, belachelijk goedkope raid-oplossingen, enzovoort. Ook worden netwerken steeds sneller, dus de bottleneck gaat weer naar de CPU toe.

[Exirion]

MBV schreef op dinsdag 25 november 2008 @ 12:13:
Ik voorzie dat binnenkort (binnen 5 jaar) I/O een veel kleinere bottleneck gaat worden met SSD's,

Ik zie dat juist niet gebeuren. De weg vinden naar de juiste geheugencellen en de data naar een CPU sturen blijft een relatief langzaam proces. Of je het nu over primair geheugen of secundair geheugen hebt, de CPU is nogsteeds altijd sneller. Vandaar ook meerdere lagen caching.

De snelheid van geheugen neemt toe, maar de capaciteit minstens zo snel. En de snelheden van CPU's stijgen ook nogsteeds gestaag, dus al met al is er weinig reden om aan te nemen dat de geheugenbottleneck snel gaat verdwijnen.

[flowerp]

Exirion schreef op dinsdag 25 november 2008 @ 13:20:
[...]
En de snelheden van CPU's stijgen ook nogsteeds gestaag

Die stijgen juist amper meer... daar over gaat nu juist deze hele thread!

De geheugen snelheid neemt toe voor enkele sequentiële accesses, de I/O neemt toe voor gewone enkele reads of writes, maar de CPU snelheid voor sequentiële neemt dus niet toe. Omdat 'jullie' geen gebruik willen maken van meerdere cores (even gegeneraliseerd ), zal jullie code dus op 1 core blijven draaien en zullen andere dingen dan de CPU voor die code relatief sneller worden.

Totdat...

Juist, de bottleneck weer bij de enkele core op de CPU komt te liggen.

[.oisyn]

flowerp schreef op dinsdag 25 november 2008 @ 22:09:
[...]


Die stijgen juist amper meer... daar over gaat nu juist deze hele thread!

Lees nu Exirion's post nog een keer. De geheugenbottleneck gaat niet verdwijnen, want CPU's worden sneller. Niet in de lengte (GHz'en en instructions-per-clock), maar in de breedte (meer cores).

[flowerp]

.oisyn schreef op dinsdag 25 november 2008 @ 22:17:
[...]

Lees nu Exirion's post nog een keer. De geheugenbottleneck gaat niet verdwijnen, want CPU's worden sneller. Niet in de lengte (GHz'en en instructions-per-clock), maar in de breedte (meer cores).

Misschien las ik het niet helemaal goed, lange werkdag, zie code dansen voor m'n ogen (letterlijk ), maar uhm, het is toch zo dat als je single threaded code blijft schrijven, dat dan een steeds groter percentage van je CPU niets aan het doen is. Cores die niets te doen hebben en idle staan of zelfs sleepen (in nieuwere CPU ontwerpen) hebben ook geen bandbreedte nodig.

In een extreem geval hebben we over 10 jaar een 128 core CPU, waarvan er +- 126 zich in de sleep toestand bevinden. Je hebt dan effectief in 2018 een dual core CPU zoals in 2008 (aangenomen dat over 10 jaar de single core performance nog steeds niet significant is toegenomen, wat bij een 128 core ding wellicht geen gekke aanname is). Echter, in die 10 jaar is de geheugen snelheid en je I/O subsysteem sneller als nu.

Dus

- Effectief zelfde CPU snelheid als nu (met 2 cores actief dus)
- Veel sneller geheugen + veel sneller I/O subsystem
------

-> bottleneck komt weer bij de CPU te leggen. Tenzij een significant gedeelte van die 128 cores echt gebruikt gaat worden, dan zal de memory bottleneck misschien alleen maar relatief groter worden. Alleen hebben een behoorlijk aantal programmeurs dus helemaal geen trek om parallel te programmeren. Lees maar een paar posts in de deze thread terug. Men denkt dat er wel genoeg users zijn (geen argument voor op de desktop), of dat mensen altijd wel genoeg applicaties draaien (is waar, maar 128?).

[.oisyn]

flowerp schreef op dinsdag 25 november 2008 @ 23:01:
maar uhm, het is toch zo dat als je single threaded code blijft schrijven, dat dan een steeds groter percentage van je CPU niets aan het doen is.

Klopt, maar dat gaat in het geheel niet in tegen wat Exirion zei, namelijk dat geheugen gewoon een bottleneck blijft. Natuurlijk, als je dingen inefficient gaat gebruiken dan zal de bottleneck verschuiven, maar dat is altijd al zo geweest. Overigens geloof ik niet dat geheugen op hetzelfde niveau komt als de L1 of zelfs ook maar L2 cache van een CPU.

[MBV]

Ik denk wel dat het L2- en L3-cache nog veel groter gaan worden. Daar zit de afgelopen jaren een vrij constante stijgende lijn in. Dus daar gaat het eerste stuk van je bottleneck. Vervolgens blijken geheugensnelheden nog steeds constant op te lopen (videokaarten voorop), met een vrij constante latency (timings worden steeds hoger met hogere kloksnelheid). Daar gaat het tweede stuk van je bottleneck.
Het probleem bij geheugen komt dus te liggen bij de toegang krijgen ertoe. Ik weet niet precies hoe dat werkt: is het niet zo dat de processor een blok opvraagt, nog een blok opvraagt, en dan antwoord krijgt? Als dat zo is, dan helpt parallel programmeren dus ook om de bottleneck in je geheugen te verhelpen

[.oisyn]

MBV schreef op woensdag 26 november 2008 @ 01:17:
Ik denk wel dat het L2- en L3-cache nog veel groter gaan worden. Daar zit de afgelopen jaren een vrij constante stijgende lijn in. Dus daar gaat het eerste stuk van je bottleneck.

Maar je krijgt ook steeds meer geheugen, en meer cores. Oftewel, de onderlinge verhoudingen blijven vrijwel gelijk. We hebben trouwens al jaren geen L3 meer gehad, de Core i7 herintroduceert 'm weer.

[MBV]

De verhoudingen blijven niet gelijk: t.o.v. 1 core worden de geheugens en caches groter en sneller, zodat de bottleneck bij die ene core komt te liggen (als je geen gebruik maakt van multi-threading). En dat was precies het punt wat ik wilde maken tegenover o.a. Confusion.

Ik pakte L2- en L3-cache trouwens samen, omdat ze allebei ongeveer hetzelfde effect hebben: de bottleneck van het RAM aanpakken.

[ Voor 9% gewijzigd door MBV op 26-11-2008 10:30 ]

[Exirion]

MBV schreef op woensdag 26 november 2008 @ 01:17:
Ik denk wel dat het L2- en L3-cache nog veel groter gaan worden. Daar zit de afgelopen jaren een vrij constante stijgende lijn in.

Ik weet niet waar jij je gegevens vandaan haalt maar dit klopt over het geheel genomen niet. Je moet alles in verhouding bekijken. Als we even teruggaan naar een high-end 386 van begin jaren 90, dan hebben we het over een machine met 4MB RAM en 32KB cache (off-chip weliswaar, maar goed). Dat is een verhouding van 0.78% cache. Gaan we daarna met een sprong naar een Pentium in 1995 dan hebben we bijvoorbeeld een high-end P133 met 256KB pipeline burst cache en 16MB RAM. Dat is 1.56%.

Daarna is de hoeveelheid geheugen in computers rap gestegen richting het niveau van 4GB voor een leuke mainstream PC van nu. Bekijken we dan de 8MB cache van een actuele high-end C2D, dan is er nogsteeds maar 0.2% cache aanwezig. En dan kan dat snelle cache zijn, maar in 1998 had ik m'n Celeron 300A ook al op 450MHz draaien met de 128KB cache geclockt op de CPU clock. En 128MB geheugen was op dat moment nog duur en relatief veel.

Kortom: geheugensnelheden en cache sizes blijven achterlopen.

[MBV]

Je leest nog steeds over hét punt van mijn verhaal heen. Mijn visie op de toekomst qua computersnelheid:
- processorsnelheid blijft per core gelijk
- cachehoeveelheid groeit
- geheugen hoeveelheid/snelheid groeit, latency blijft gelijk
- harde schijf snelheid/grootte groeit
Doordat de processorsnelheid per core achterloopt op de ontwikkeling, zal die ene core bij single-threaded applicaties de bottleneck gaan vormen, omdat de rest van de beperkingen een voor een worden weggenomen.

offtopic:
had ik dat nou zo heel slecht verwoord in mijn vorige posts?

[ Voor 7% gewijzigd door MBV op 26-11-2008 11:21 ]

[Exirion]

MBV schreef op woensdag 26 november 2008 @ 11:20:
Je leest nog steeds over hét punt van mijn verhaal heen. Mijn visie op de toekomst qua computersnelheid:
- processorsnelheid blijft per core gelijk
- cachehoeveelheid groeit
- geheugen hoeveelheid/snelheid groeit, latency blijft gelijk
- harde schijf snelheid/grootte groeit
Doordat de processorsnelheid per core achterloopt op de ontwikkeling, zal die ene core bij single-threaded applicaties de bottleneck gaan vormen, omdat de rest van de beperkingen een voor een worden weggenomen.

offtopic:
had ik dat nou zo heel slecht verwoord in mijn vorige posts?

Je bekijkt het wat mij betreft te simplistisch, want veel systeemonderdelen kun je niet volledig los van elkaar beschouwen. Het is maar net wat voor systeem het is: delen de cores hetzelfde geheugen? Hebben de cores hun eigen geheugen verbonden met bussen? Hoe wordt er in de caching van de cores omgegaan met concurrency? In hoeverre moet de programmeur zorgen dat bewerkingen op data in de verschillende cores non-concurrent zijn?

Het is net als met een project: laat er 5 mensen op werken en het is in 2 maanden klaar. Maar zet je er 10 mensen op, dan gaat het niet ineens 2 keer zo snel. Zo is het ook met multiprocessor systemen: de overhead neemt toe, en daar gaat nou net de hele discussie in dit topic over.

Dan speelt er nog een ander issue: snelle caches zitten on-chip. Kun jij ineens veel grotere en snellere caches produceren, dan is het vrijwel zeker dat de CPU core op de chip net zoveel complexer en sneller kan worden. Die schaalt dus mee met de cache trends. Warmte en die-size zijn de grootste vijanden hier, en voor beide moeten die overwonnen worden.

Het is in ieder geval absoluut niet zo dat je kunt garanderen dat de processing cores de bottlenecks gaan vormen.

[EfBe]

MBV schreef op woensdag 26 november 2008 @ 11:20:
Je leest nog steeds over hét punt van mijn verhaal heen. Mijn visie op de toekomst qua computersnelheid:
- processorsnelheid blijft per core gelijk
- cachehoeveelheid groeit
- geheugen hoeveelheid/snelheid groeit, latency blijft gelijk
- harde schijf snelheid/grootte groeit
Doordat de processorsnelheid per core achterloopt op de ontwikkeling, zal die ene core bij single-threaded applicaties de bottleneck gaan vormen, omdat de rest van de beperkingen een voor een worden weggenomen.

De bottleneck is nu disk I/O ivm de steptijd van de hdd kop(pen). Dit wordt erger naar gelang er meer parallelle taken runnen die disk I/O nodig hebben. Je kunt dus wel een snellere disk nemen die sequentieel sneller leest, maar bij een groei van het aantal parallelle taken die disk I/O nodig hebben is die aanwinst in sequentiele snelheid zelden zichtbaar, omdat veel tijd verloren gaat aan stepping.

Ik voorzie dan ook dat parallelle taken wel parallel disk I/O gaan aanvragen, maar er een scheduler tussen wordt gezet die de requests sorteert zodanig dat er zo weinig mogelijk stepping plaats vindt. Alleen dan kun je de werkelijke bottleneck oplossen in hedendaagse computers: de inmens triest trage harddisk.

[MBV]

Exirion schreef op woensdag 26 november 2008 @ 11:40:
[...]

Je bekijkt het wat mij betreft te simplistisch, want veel systeemonderdelen kun je niet volledig los van elkaar beschouwen. Het is maar net wat voor systeem het is: delen de cores hetzelfde geheugen? Hebben de cores hun eigen geheugen verbonden met bussen? Hoe wordt er in de caching van de cores omgegaan met concurrency? In hoeverre moet de programmeur zorgen dat bewerkingen op data in de verschillende cores non-concurrent zijn?

Ik zet hem inderdaad wat simplistisch neer, maar ik denk dat het in grote lijnen wel klopt. Ik weet ook wel dat er overhead komt kijken bij multithreaded programmeren. Maar onafhankelijk van de antwoorden op jouw vragen blijft staan dat de processortijd steeds meer de bottleneck gaat worden, en je dus dezelfde performance houdt als nu wanneer je niet multi-threaded gaat programmeren.

Het is net als met een project: laat er 5 mensen op werken en het is in 2 maanden klaar. Maar zet je er 10 mensen op, dan gaat het niet ineens 2 keer zo snel. Zo is het ook met multiprocessor systemen: de overhead neemt toe, en daar gaat nou net de hele discussie in dit topic over.

Een paar mensen in die discussie hadden als stelling dat het onzin was om meer dan 1 core te gebruiken. Stel je nou eens voor dat je met 4x zo veel processors maar 50% extra snelheid krijgt door slecht schaalgedrag. Als je 128 cores hebt, zou het desondanks zonde zijn om het niet te doen: anders kunnen die 127 cores alleen maar neuspeuteren.

Dan speelt er nog een ander issue: snelle caches zitten on-chip. Kun jij ineens veel grotere en snellere caches produceren, dan is het vrijwel zeker dat de CPU core op de chip net zoveel complexer en sneller kan worden. Die schaalt dus mee met de cache trends. Warmte en die-size zijn de grootste vijanden hier, en voor beide moeten die overwonnen worden.

Het is in ieder geval absoluut niet zo dat je kunt garanderen dat de processing cores de bottlenecks gaan vormen.

Als je meer cache op een processor kan krijgen, betekent dat waarschijnlijk dat ze de productie weer een stapje kleiner hebben gemaakt. Dat betekent dat de processor weer groter kan worden, dus meer cores naast elkaar, en niet dat de snelheid groter wordt. Ik heb dus ook bewust niet gezegd dat de caches sneller gaan worden: L2-caches draaien nu al op kloksnelheid (toch?), sneller heeft dus geen zin

En garanderen kan ik niks, maar verwachten wel. En dat is dus precies wat ik daarnet heb opgeschreven

EfBe schreef op woensdag 26 november 2008 @ 13:00:
[...]

De bottleneck is nu disk I/O ivm de steptijd van de hdd kop(pen). Dit wordt erger naar gelang er meer parallelle taken runnen die disk I/O nodig hebben. Je kunt dus wel een snellere disk nemen die sequentieel sneller leest, maar bij een groei van het aantal parallelle taken die disk I/O nodig hebben is die aanwinst in sequentiele snelheid zelden zichtbaar, omdat veel tijd verloren gaat aan stepping.

Je kan ook een SSD kopen

Ik voorzie dan ook dat parallelle taken wel parallel disk I/O gaan aanvragen, maar er een scheduler tussen wordt gezet die de requests sorteert zodanig dat er zo weinig mogelijk stepping plaats vindt. Alleen dan kun je de werkelijke bottleneck oplossen in hedendaagse computers: de inmens triest trage harddisk.

Dat is wat er nu nog ontbreekt in de diverse OS'en: een I/O scheduler. Hoe vaak crasht windows niet bijna omdat er een programma heel veel data van de HDD probeert te lezen, en de rest er dus niet meer bij kan? In de goede volgorde afvragen wordt nu trouwens al gedeeltelijk door de HDD's geregeld met NCQ.

Om dat goed te regelen zal je trouwens ook weer parallel moeten gaan werken: zorgen dat je programma niet op de HDD hoeft te wachten maar alvast verder gaat met verwerken van andere dingen, en zoveel mogelijk HDD-requests naast elkaar zet om de I/O scheduler een optimale oplossing te laten vinden

[ Voor 22% gewijzigd door MBV op 26-11-2008 13:47 ]

[Exirion]

MBV schreef op woensdag 26 november 2008 @ 13:42:
Maar onafhankelijk van de antwoorden op jouw vragen blijft staan dat de processortijd steeds meer de bottleneck gaat worden

Leg uit, want ik kan dit niet afleiden uit wat ik zelf zei.

Een paar mensen in die discussie hadden als stelling dat het onzin was om meer dan 1 core te gebruiken. Stel je nou eens voor dat je met 4x zo veel processors maar 50% extra snelheid krijgt door slecht schaalgedrag. Als je 128 cores hebt, zou het desondanks zonde zijn om het niet te doen: anders kunnen die 127 cores alleen maar neuspeuteren.

Je snapt mijn punt niet. Een multi core oplossing heeft met andere problemen te maken dan een single core systeem. In die problemen speelt de inter-core communicatie, caching en memory access een grote rol, wat dus inhoudt dat die weldegelijk een belangrijke rol blijven spelen. Zodoende is het absoluut niet gezegd dat de cores zelf de bottleneck vormen.

Als je meer cache op een processor kan krijgen, betekent dat waarschijnlijk dat ze de productie weer een stapje kleiner hebben gemaakt. Dat betekent dat de processor weer groter kan worden, dus meer cores naast elkaar, en niet dat de snelheid groter wordt.

Alweer mis je mijn punt. Ik zeg: temperatuur en die size zijn een beperking. Naarmate caches meer ruimte krijgen, is het inderdaad waarschijnlijk dat de miniaturisatie is vergroot. Jij zegt dan dat er nog meer cores passen. Ik zeg: de cores die er zitten kunnen hoger geclockt worden, en dan is jouw hele statement onderuit gehaald. Die core snelheden kunnen meeschalen met de cache sizes en snelheden.

[Confusion]

Exirion schreef op woensdag 26 november 2008 @ 14:42:
Alweer mis je mijn punt. Ik zeg: temperatuur en die size zijn een beperking. Naarmate caches meer ruimte krijgen, is het inderdaad waarschijnlijk dat de miniaturisatie is vergroot. Jij zegt dan dat er nog meer cores passen. Ik zeg: de cores die er zitten kunnen hoger geclockt worden, en dan is jouw hele statement onderuit gehaald. Die core snelheden kunnen meeschalen met de cache sizes en snelheden.

Overigens gaan beide over niet al te lange tijd tegen een harde fysische limiet aanlopen: eerst kunnen transistoren niet meer kleiner, omdat ze uit een minimaal aantal atomen moeten bestaan om hun eigenschappen te behouden. 1nm ~ 3 atomen. Dat vormt een harde limiet op processorcapaciteit per oppervlak.

Als je er vervolgens in slaagt om processoren ruimtelijk uit te breiden (hetzij door losse processoren/cores later aan elkaar te breien, hetzij door de hoogte in te gaan, hetzij op andere manieren), dan ga je tegen de lichtsnelheid aanlopen. Zelfs met 3x10⁸ m/s kan je in een 1/4 nanoseconde maar 7.5 cm afleggen. Tel daar bij op dat signalen in electronica met pakweg de halve lichtsnelheid bewegen en de conclusie is dat delen die meer dan ~4 cm. uit elkaar liggen niet met elkaar kunnen communiceren binnen 1 kloktik. Dezelfde beperking zorgt er voor dat het lastig is de frequentie van een enkele core op te blijven schroeven: de electrische lading in de transistoren moet tijd krijgen om te vloeien.

De tijd die het feitelijke signaaltransport nodig heeft is in werkelijkheid groter dan het theoretisch benodigd minimum, als de afstanden groter worden. Zeker als je naar tientallen cores toe wilt, is dat iets dat een rol gaat spelen, nog los van de overhead van de datasynchronisatie. Je loopt dan tegen het probleem aan dat ze in de wereld van de supercomputers heel goed kennen: het datatransport tussen de verschillende processoreenheden is vaak de bottleneck.

[.oisyn]

En als we tegen die limieten aan lopen kunnen we onze computers nog altijd verder van onze aarde stallen zodat ze voor ons sneller lijken te lopen

[MBV]

Exirion schreef op woensdag 26 november 2008 @ 14:42:
Je snapt mijn punt niet. Een multi core oplossing heeft met andere problemen te maken dan een single core systeem. In die problemen speelt de inter-core communicatie, caching en memory access een grote rol, wat dus inhoudt dat die weldegelijk een belangrijke rol blijven spelen. Zodoende is het absoluut niet gezegd dat de cores zelf de bottleneck vormen.

In een multicore-omgeving zullen de processors samen nooit de bottleneck kunnen vormen. Maar als je maar 1 van die cores gebruikt zal dat wel het geval zijn, denk ik: de rest van het systeem wordt dan zo ingericht dat je 128 cores vol kan trekken, als je dan maar 1 core gebruikt zal de rest van het systeem volledig overkill zijn.

Alweer mis je mijn punt. Ik zeg: temperatuur en die size zijn een beperking. Naarmate caches meer ruimte krijgen, is het inderdaad waarschijnlijk dat de miniaturisatie is vergroot. Jij zegt dan dat er nog meer cores passen. Ik zeg: de cores die er zitten kunnen hoger geclockt worden, en dan is jouw hele statement onderuit gehaald. Die core snelheden kunnen meeschalen met de cache sizes en snelheden.

De recente geschiedenis laat andere afwegingen van de processorbouwers zien: meer snelheid vereist zoveel meer stroom, dat het efficienter is om meer cores op 1 die te proppen, dan de snelheid te verhogen. Misschien dat ze over een paar jaar de 6 GHz nog halen, maar veel meer verwacht ik niet. Je krijgt problemen met signaaloverdracht: hoe hoger de snelheid, hoe preciezer de lengte van signaal'kabels' overeen moet komen. Ik kan er natuurlijk hopeloos naast zitten

Confusion schreef op woensdag 26 november 2008 @ 15:31:
[verhaal over atomen en lichtsnelheid]

Dat bedoelde ik dus Maar zeg eens Confusion: ben je overgelopen? Vorige pagina zei je nog dat de omgeving de beperking vormt, niet de processorkracht? Ik denk dus dat de eenvoudigste oplossing voor Intel en AMD is om meerdere (relatief) kleine modules te koppelen op de een of andere manier. Kijk maar naar de roadmaps.

[H!GHGuY]

MBV schreef op woensdag 26 november 2008 @ 16:04:
[...]
In een multicore-omgeving zullen de processors samen nooit de bottleneck kunnen vormen. Maar als je maar 1 van die cores gebruikt zal dat wel het geval zijn, denk ik: de rest van het systeem wordt dan zo ingericht dat je 128 cores vol kan trekken, als je dan maar 1 core gebruikt zal de rest van het systeem volledig overkill zijn.

Als je slecht programmeert kan een multi-core omgeving wel degelijk een bottle-neck vormen.
Als 2 processoren telkens op hetzelfde geheugen werken (bvb dezelfde mutex locken en unlocken) dan creer je overhead via de cache. Er was een tijd geleden een "what all programmers should know about memory" artikel op lwn.net.

vb:

C++:

//thread1 (affiniteit op core 1)
while (true)
{
   x = produce();
   pthread_mutex_lock(&queuelock);
   enqueue(x);
   pthread_mutex_unlock(&queuelock);
}
// thread2 (affiniteit op core 2)
while (true)
{
  pthread_mutex_lock(&queuelock)
  x = dequeue();
  pthread_mutex_lock(&queuelock)
  consume(x);
}

Deze code kan enorm contraproductie werken en mogelijk zelfs trager worden op een multicore.

De andere core moet telkens de cachelijn waarin de mutex zich bevindt locken en dat kan de nodige vertraging opleveren. Bovendien zit het net gequeue'de element in de cache van processor 1. Dit overhevelen aan processor2 zorgt ervoor dat die processor zijn cache moet vullen en tegelijk weer synchronisatie moet doen met de andere cache.
Erger nog: doe je dit op bvb een 16-core systeem met 8 producers en 8 consumers dan kun je behoorlijke performance degradaties zien.

[oeLangOetan]

H!GHGuy, fork-join + work stealing lost de probleem netjes op door elke cpu zijn eigen queue te geven en daarboven een workscheduller te zetten. Er zijn 100en voorbeelden te vinden wanneer concurrency misloopt als je de verkeerde werkmethode gebruikt, maar hetzelfde geld voor sequentiele programmas.
Er zijn de laatste jaren zeer veel frameworks verschenen die concurrency makkelijker maken maar je moet altijd een stukje controle loslaten, je hebt geen directe toegang tot threads en moet hogere abstracties gebruiken.

[MBV]

H!GHGuY schreef op zaterdag 29 november 2008 @ 19:41:
[...]


Als je slecht programmeert kan een multi-core omgeving wel degelijk een bottle-neck vormen.
Als 2 processoren telkens op hetzelfde geheugen werken (bvb dezelfde mutex locken en unlocken) dan creer je overhead via de cache. Er was een tijd geleden een "what all programmers should know about memory" artikel op lwn.net.

Ik moet in dit topic echt heel goed opletten op wat ik zeg. Kunnen we alsjeblieft die arme miertjes met rust laten?
Ik bedoelde dus te zeggen dat de processorkracht van de multicore processor nooit de beperking zal zijn, maar eerder de apparatuur er omheen. Continue hetzelfde geheugen aanspreken is daar wel het ultieme voorbeeld van

Mijn stelling: De individuele cores van een computer zullen niet veel sneller meer worden dan ze nu zijn, de groei zal in de breedte komen. In de toekomst zullen systemen dus met 128 cores worden uitgerust, en de componenten daar omheen zullen sneller worden om die groei te faciliteren. Door single-threaded te programmeren zal je de bottleneck op die ene processor leggen waar jouw programma op draait, met als gevolg dat het programma wat je schrijft nooit (veel*) sneller zal draaien dan nu mogelijk (met het snelste geheugen/schijf/...).

*Door bottlenecks op geheugensnelheid e.d. weg te nemen, en door groei van de snelheid van processors (6GHz zou 2x zijn), zal je nog iets van 5x zo snel kunnen draaien als nu, maar dat is veel minder dan de groei aan verwerkingskracht van de systemen.

offtopic:
En dan hoop ik dat die niet multi-interpretabel is

[epic007]

EfBe schreef op woensdag 26 november 2008 @ 13:00:
Ik voorzie dan ook dat parallelle taken wel parallel disk I/O gaan aanvragen, maar er een scheduler tussen wordt gezet die de requests sorteert zodanig dat er zo weinig mogelijk stepping plaats vindt. Alleen dan kun je de werkelijke bottleneck oplossen in hedendaagse computers: de inmens triest trage harddisk.

Hier waren ze in 1969 ook al mee bezig: http://portal.acm.org/citation.cfm?id=321550

Tegenwoordig heb je met SATAII (300MB/s) en RAID toch redelijk snelle harddisk toegang. Ik kan op dit moment weinig toepassingen bedenken die en continue veel I/O nodig hebben, en continue veel processor power nodig hebben. Alleen misschien in wetenschappelijke omgevingen..

[ Voor 3% gewijzigd door epic007 op 02-12-2008 16:32 ]

[Depress]

Ik ben nieuw in deze discussie en heb even de laatste paar replies gelezen.

Maar is het niet zo dat met de hedendaagste hoeveelheden RAM geheugen programma's vaak al totaal zijn ingeladen in het geheugen(Zo niet, kan een programma hier op anticiperen, welleswaar door de programmeur gedaan dan wel door compiler of zelfs OS).

Dit zal dat de OI vanaf de HD beperken, en met de opkomst van de SSD wordt toch ook het laatste van de langzaamheid van de drive vrijwel weggenomen?

Dit terug koppelend naar de algehele discussie is lijkt me het voor sommige simpele taken niet rendable om alles te gaan uitwerken in threads. Maar een beetje algoritme kan toch al snel veel winst maken als dit multithreaded is. Waarom dan eigenwijs blijven en toch op core blijven programmeren. Het komt alleen maar de user-experience tengoede omdat alles veel vlotter werkt. Mits goed uitgevoerd natuurlijk.

[Confusion]

MBV schreef op woensdag 26 november 2008 @ 16:04:
Dat bedoelde ik dus Maar zeg eens Confusion: ben je overgelopen? Vorige pagina zei je nog dat de omgeving de beperking vormt, niet de processorkracht?

De komende tien jaar nog wel. Zie bijvoorbeeld ook http://tech.slashdot.org/article.pl?sid=08/12/05/0051238: de beperking voor taken die veel CPU power vereisen is nog steeds datatransport en dat wordt erger door meerdere cores. Over acht jaar rakelen we deze discussie wel weer op en zien we verder . Of eerder, als we praktische problemen tegenkomen die we niet op kunnen lossen. Ik verwacht niet dat me dat gaat gebeuren.

[MBV]

Je spreekt jezelf nu tegen: doordat je met meerdere cores werkt wordt de I/O een bottleneck. Dat is logisch, ben ik het helemaal mee eens. Ik denk dat als je maar 1 core blijft gebruiken die ene core de bottleneck wordt, omdat de I/O wordt opgeschaald om de meerdere cores te kunnen faciliteren.

Maar goed, ik heb afgelopen week de verwerkingstijd van een compiler omlaag heb gebracht van 2 uur naar 6 minuten zonder meerdere threads te gebruiken (voor elk bestand een JVM starten, nee da's handig
). Ik denk dus dat de meeste applicaties met slimme algoritmen e.d. veel meer geholpen worden dan met meerdere cores. Een O(n^2) algoritme op 128 cores kan langzamer zijn dan een O(log n) algoritme op 1 core (wat dan weer langzamer is dan O(log n) op 128 cores )

[ Voor 3% gewijzigd door MBV op 07-12-2008 13:01 ]

[.oisyn]

MBV schreef op zondag 07 december 2008 @ 13:01:
Maar goed, ik heb afgelopen week de verwerkingstijd van een compiler omlaag heb gebracht van 2 uur naar 6 minuten zonder meerdere threads te gebruiken (voor elk bestand een JVM starten, nee da's handig

En als je wél meerdere threads had gebruikt had het dus nog sneller kunnen zijn. Ik vind het eigenlijk een beetje een loze opmerking. Een beter algoritme is een optimalisatie. Gebruik maken van meerdere cores is óók een optimalisatie. 't Is niet zo dat het gebruik van de een de ander uitsluit. En natuurlijk zijn veel applicaties niet voldoende geoptimaliseerd, maar dat is niet waar deze thread om gaat.

[MBV]

Inderdaad, dat was wat ik bedoelde. Veel applicaties zijn nog zo slecht geoptimaliseerd dat de winst op 1 core groter kan zijn dan multi-threading. Ik ga eens kijken of ik vandaag tijd heb voor een multi-threading implementatie

[Confusion]

MBV schreef op zondag 07 december 2008 @ 13:01:
Je spreekt jezelf nu tegen: doordat je met meerdere cores werkt wordt de I/O een bottleneck. Dat is logisch, ben ik het helemaal mee eens. Ik denk dat als je maar 1 core blijft gebruiken die ene core de bottleneck wordt, omdat de I/O wordt opgeschaald om de meerdere cores te kunnen faciliteren.

De I/O vormt al jaren de bottleneck en als je met meerdere cores werkt, dan wordt dat erger. Er lijkt me daarom alle reden om te verwachten dat I/O de bottleneck blijft en je altijd meer CPU-power tot je beschikking hebt dan je nodig hebt. Zoveel meer, dat je door gebruik van gebruikelijke synchronisaties (thread-per-user, asynchrone I/O, een handvol threadpools) al voldoende spreiding krijgt. Ik wacht wel tot ik duidelijke signalen heb dat mensen het probleem in de praktijk tegenkomen .

[flowerp]

flowerp schreef op zondag 09 november 2008 @ 14:56:
Daarnaast zijn quad-cores ook een absolute commodity geworden, hoewel ze nog steeds niet zo wijdverspreid zijn als de dual cores. Een zeer snelle quad-core kost momenteel bij een computer winkel om de hoek (b.v. Mycom) slechts zo'n 179,- (zie http://www.mycom.nl/Products/654.aspx?View=0). l

Tevens geeft deze shop een makkelijk overzicht van hun aanbod, hier een overzicht van de CPUs die ze aanbieden per aantal cores:

code:

Aantal cores
1x  3
2x 16
3x  2
4x  8
(totaal 29 cpus)

Maar weer eens een tussentijdse update. Slechts enkele maanden later ziet het beeld bij Mycom er nu zo uit:

code:

Aantal cores
1x  2
2x 10
3x  1
4x 12
(totaal 25 cpus)

Er zijn nu meer quad cores leverbaar dan dual cores. Het gemiddeld aantal cores bij deze winkel is dan ook van ruim 2.5 naar bijna 3 gegaan.

Voor servers zijn momenteel de eerste hexacore CPUs ook al weer leverbaar; de 6 core (3x2) Dunnington (zie oa Wikipedia: Xeon en http://arstechnica.com/ha...ore-xeon-monster-chip.ars). Ook AMD komt dit jaar nog met een 6 core chip en de 8 en 12 cores zitten duidelijk in de pijplijn (zie http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3457).

Ik denk dat dit jaar nog net het jaar is waarbij men de extra cores nog als een extra'tje ziet om achtergrond taken op te draaien, maar dat vanaf 2010/2011 het toch eindelijk gaat doordringen dat computers meerdere cores hebben en dat die niet uit zich zelf werk gaan zitten doen.

[.oisyn]

Reken je de Core i7 tot een 4-core of een 8-core? 't Is een 4-core, maar met SMT. 8 Hardware threads dus. En in vergelijking met de P4 heeft hyperthreading nu een stuk meer nut

[flowerp]

.oisyn schreef op zondag 01 februari 2009 @ 22:28:
Reken je de Core i7 tot een 4-core of een 8-core? 't Is een 4-core, maar met SMT. 8 Hardware threads dus. En in vergelijking met de P4 heeft hyperthreading nu een stuk meer nut

Das waar ook Nee, ik had de Core i7 voor het gemak tot de 4-cores gerekend (wat het feitelijk natuurlijk ook is zoals je al zegt). Echter, voor je software is het wel degelijk iets meer dan een quad core. We zijn het 8-core tijdperk dus al met 1 voet(je) binnengetreden

[Alarmnummer]

Ik ben al een tijdje bezig met een Software Transactioneel geheugen implementatie speciaal voor Java:

http://code.google.com/p/multiverse/

Het is voornamelijk bedoelt om inzichten op te doen (en om te experimenteren met erg interessante techieken). Maar ik denk dat STM/HTM wel een belangrijke tool in de toolbox kunnen worden voor concurrency control. Old school concurrency is gewoon te lastig.

Probeer het volgende maar eens te doen met old school concurrency:

code:

atomic{
    Object item = queue1.peek();
    if(item != null)
        return item;

    item = queue2.peek();
    if(item != null)
        return item;

     retry();
}

Of nu met een orElse:

code:

atomic{
    {
          return queue1.pop();
    }OrElse{
          return queue2.pop();
    }
}

Gaan slapen op waitssets van verschillende locks is niet mogelijk.

Of anders dit:

code:

atomic{
   toQueue.push(fromQueue.pop());
}

Zorgen dat dit atomic is en isolated (dus ook geen observatie mogelijk is dat het item op geen van beide queues zit) is al een drama.

Het is de bedoeling dat mbv instrumentatie normale pojo's deel uit kunnen maken van een STM. Zie de site voor een voorbeeld hoe eenvoudig het zou kunnen zijn om concurrent code te schrijven.

Verder zitten er wel een paar leuke zaken in zoals de mogelijkheid tot flashback queries, geen kosten voor immutable structuren, readers don't block writers en andersom, transaction level read consistency, etc. Ik ga waarschijnlijk op JSpring 2009 een presentatie erover geven.

In code dat atm nog niet in subversion zit ben ik al begonnen met een efficientere heap implementatie waarbij bv de updates (herbalanceren) over meerdere cores verdeeld kan worden of waar je het herbalanceren wat minder strikt gaat doen. Is allemaal via interfaces gescheiden van de implementatie en bij de implementaties via policies te tunen.

[ Voor 69% gewijzigd door Alarmnummer op 12-02-2009 08:15 ]

[Alarmnummer]

Mijn proposal is goedgekeurd. Wie mij wil zien ijlen over Transactioneel Geheugen moet naar J-Spring 2009 gaan (in april in Bussum).

Ik heb ook op J-Fall 2008 gesproken en dat was een erg leuke ervaring (presentatie is ook als goed beoordeeld).

[.oisyn]

Er is volgende week donderdag in Nieuwegein een seminar van Intel over parallel programming. Gaat iemand ernaartoe?

---

Intel Multi-Threading Seminar (Nieuwegen, Holland) 8th October 2009
Participate in Intel’s full-day free seminar about the topic:
“How How to write bugfree and performance optimized parallel (threaded ) applications (Turning a serial into a parallel application)”
You will get an in-depth technical overview on concepts about writing parallel apps. The seminar will also show you how the latest Software Development Tools from Intel help in this process.
This event is organized together with our partner Sequint and is entirely in English.
The first 10 registrants will get a book about multicore programming‘ Threading Building Blocks’.
We will also run a raffle where the participants can win a Dual Core Notebook that will be handed out at end of the seminar.

For registration please go to www.sequint.nl/intel/seminar

The agenda

08:30	Think Parallel – Intel’s Best Practices for parallel software development Types of parallelism, Rules & Methodologies, Tools
09:30	Application end-to-end development using Intel Parallel Studio Overview on the 4 major design phases
11:30	Using Intel VTune Performance Analyzer to spot code optimisation opportunities
12:00	Lunch
13:00	How to produce optimised code with Intel Parallel Composer
13:30	Expressing Parallelism with Intel Parallel Compos Various alternatives to create threaded applications
14:00	Coffee
14:15	Expressing Parallelism (continued)
15:30	Using Intel Parallel Inspector to pinpoint Program Inefficiencies and Threading Bugs
16:00	Using the Intel Parallel Amplifier to performance Tune Threaded Software

Address :
Mercure Utrecht Nieuwegein
Buizerdlaan 10 3435 SB NIEUWEGEIN – NETHERLANDS
More information
Sequint 010 - 458 89 36
Seminar is FREE

[Alarmnummer]

.oisyn schreef op woensdag 30 september 2009 @ 17:23:
Er is volgende week donderdag in Nieuwegein een seminar van Intel over parallel programming. Gaat iemand ernaartoe?

Als ze dit bericht eerder hadden verstuurd was ik er heen gegaan, maar ik zit dan op cursus. Dus

[flowerp]

flowerp schreef op zondag 01 februari 2009 @ 23:07:
Das waar ook Nee, ik had de Core i7 voor het gemak tot de 4-cores gerekend (wat het feitelijk natuurlijk ook is zoals je al zegt). Echter, voor je software is het wel degelijk iets meer dan een quad core. We zijn het 8-core tijdperk dus al met 1 voet(je) binnengetreden

Recent zijn we het octo core tijdperk dan toch echt binnengetreden, en wel met de Intel XEON 7500 aka Beckton aka Nehalem-EX: Wikipedia: Xeon . Dit zijn 8 echte cores en 16 threads.

Dit is dan wel een CPU uit de XEON MP serie, wat voor X86 wel duidelijk de duurdere variant is (paar duizend euro per stuk), maar vergeleken bij IBM POWER hardware zijn hiermee nog wel zeker 'goedkope' servers te bouwen. Voor ~€ 10k heb je b.v. een Dell server met 2x8 cores @ 2.26 Ghz (http://configure.us.dell....x2y&c=us&l=en&s=bsd&cs=04). Dat zijn dus 16 hardware cores en 32 threads in een entry level server.

Voorderest zien we dat de voorspelde revolutie uit de eerste posts in dit topic, van 3.5 jaar geleden, deels wel en niet is uitgekomen.

De clock is sinds toen inderdaad niet toegekomen. Deze blijft nog steeds schommelen tussen grofweg 2 en 3.6Ghz. Dat sommige tweakers destijds beweerde dat multi-cores onzin waren en dat Intel de clock binnenkort gewoon weer omhoog zou gooien is nog steeds geen waarheid gebleken.

Helaas gaat de multi-core revolutie dan wel weer vrij traag, zodat het meer een voortkabbelende evolutie is dan echt een revolutie. Aan de ene kant is voor de desktop de quad core tot een bodem prijs gedaalt (AMD 99,- Intel 137,-), zijn hexa cores ook niet bijzonder duur bij AMD (179,-) en zijn er nu zelfs al mobile quad cores. Aan de andere kant zijn de meeste laptops, mac mini- en iMac achtige computers nog steeds allemaal dual core.

Gecombineerd met de nog steeds grote installed base van dual cores, maakt dit dat nu 3.5 jaar later nog steeds veel programmeurs absoluut geen rekening met parallelisme houden. 'De meeste computers hebben namelijk slechts 2 cores, en die extra core kan mooi gebruikt worden voor wat achtergrond werk van het OS enzo", is nog steeds een veelgehoorde uitspraak.

Ik denk nu zelf dat dit besef bij de massa van concurency en het normaal vinden om parallelisme te gebruiken in code pas echt gaat doorbreken als de meeste computers zo'n 8 tot 16 cores hebben en 32 en 64 core CPUs beschikbaar zijn. Op de snelheid waarmee de ontwikkelingen nu gaan kan dit nog wel makkelijk een jaar of 5 a 6 duren.

[Sebazzz]

flowerp schreef op vrijdag 07 mei 2010 @ 22:41:
[...]
en zijn er nu zelfs al mobile quad cores.

Zelfs nu? Ik heb sinds vorig jaar augustus een mobile quad core in me laptop, dus ze bestaan al een hele tijd.

Wat betreft het parallel programmeren, het zal nog even niet te merken zijn, maar .NET 4 heeft veel uitbreidingen op gebied van threading gekregen. Onder andere PLINQ en TPL.

[ Voor 9% gewijzigd door Sebazzz op 07-05-2010 23:10 ]

[Grijze Vos]

Verreweg de meeste applicaties die wij maken zijn web applicaties. Aangezien elke request daar effectief in zijn eigen thread draait, is parallellisme niet echt nodig. Volgens mij is door de bank genomen toch relatief veel development web-based in de wereld.

Is dat niet de voornaamste reden voor de lage interesse voor multi-threading?

[ Voor 13% gewijzigd door Grijze Vos op 07-05-2010 23:20 ]

[Confusion]

flowerp schreef op vrijdag 07 mei 2010 @ 22:41:
De clock is sinds toen inderdaad niet toegekomen. Deze blijft nog steeds schommelen tussen grofweg 2 en 3.6Ghz. Dat sommige tweakers destijds beweerde dat multi-cores onzin waren en dat Intel de clock binnenkort gewoon weer omhoog zou gooien is nog steeds geen waarheid gebleken.

De laatste CPU's van Intel en AMD bevatten technieken die het mogelijk maken de TDP van een/enkele cores op te krikken, als de andere cores niet gebruikt worden. Dat is het eerste signaal dat men wel degelijk aan het terugkomen van de overstap naar meer cores. Het is inmiddels helder dat consumenten niet op meerdere cores zitten te wachten, omdat het voor hun dagelijkse CPU-gebruik geen vooruitgang biedt. Ze geven liever geld uit aan een iPad, waar ze veel prettigere gebruikerservaringen op hebben, die geen cores of clockspeed ze kunnen bieden.

Dat de clock niet is toegenomen betekent daarnaast niet dat er geen vooruitgang is geweest. Van core2 naar core2duo naar i5 en i7 zijn stuk voor stuk grote vooruitgangen, zelfs met hetzelfde aantal cores en dezelfde clocksnelheid.

[flowerp]

Sebazzz schreef op vrijdag 07 mei 2010 @ 23:08:
[...]

Zelfs nu? Ik heb sinds vorig jaar augustus een mobile quad core in me laptop, dus ze bestaan al een hele tijd.

Niet 'nu' als-in, dat ze er pas vanaf nu zijn, maar gewoon dat ze op het moment van schrijven simpelweg zijn Maar bedankt voor de toelichtig.

Wat betreft het parallel programmeren, het zal nog even niet te merken zijn, maar .NET 4 heeft veel uitbreidingen op gebied van threading gekregen. Onder andere PLINQ en TPL.

Absoluut, je ziet dus dat zowel Microsoft met .NET 4 en Apple met GCD (Grand Central Dispatch) sterker op concurrency hebben ingezet. Puur 'threading' zelf is natuurlijk allang niet meer zo interesant. Daar hebben alle platformen (Microsoft, Apple, Linux, ...) al lang al support voor. De laatste trends zijn meer thread pools met een klein aantal threads en programmeurs die meer fine-grained tasks in diverse queues zetten.

Apple heeft daar een zeer interesante stap mee gezet, en BSD heeft deze al overgenomen. Java 7, dat naar verluidt er dit jaar toch echt van gaat komen, biedt iets grofweg vergelijkbaars met het fork/join. Java 7 zou dan een rijkere API moeten bieden, maar is wel beperkt tot threads binnen 1 process, dus meer voor server-side apps. Apple's GCD is veel interesanter voor de desktop, omdat de thread pool system-wide is.

Grijze Vos schreef op vrijdag 07 mei 2010 @ 23:19:
Verreweg de meeste applicaties die wij maken zijn web applicaties. Aangezien elke request daar effectief in zijn eigen thread draait, is parallellisme niet echt nodig. Volgens mij is door de bank genomen toch relatief veel development web-based in de wereld.

Is dat niet de voornaamste reden voor de lage interesse voor multi-threading?

Hmmm, dat argument is 3 jaar geleden al uitgebreid besproken. De grap is dat zelfs als doe je zeg 500 users per server, dat het aantal daarwerkelijk concurrent requests daar maar een kleine fractie van is. In uitgebreide tests kwamen wij op minder dan 4 requests op de 500 users die daadwerkelijk tegelijk liepen. Daar zit je dan met je 32 core machine en 28 cores die niets doen.

Daarnaast, wat ook al uitgebreid besproken is, 1 enkele request kan ook gewoon zwaar werk moeten doen. Als je lightweight je werk over meerdere cores kunt verdelen (en nee, een thread is te heavy weight meestal), dan kun je ook hier behoorlijke winsten boeken. Als een zware request b.v. normaal 4 seconde zou pakken, dan kun je dit wellicht terug brengen tot onder de seconde door het over 8 cores te verdelen.

Het hele probleem is en blijft dat te veel mensen maar blijven denken dat het helemaal verdelen over 8 cores zo'n overheid is, dat dit geen winst gaan opleveren en alleen maar complexiteit oplevert. Met technieken als Apple's GCD (niet echt voor de server, maar toch) en Java's komende fork/join voor CPU intensieve operaties is dat helemaal niet meer zo.

Confusion schreef op vrijdag 07 mei 2010 @ 23:33:
Het is inmiddels helder dat consumenten niet op meerdere cores zitten te wachten, omdat het voor hun dagelijkse CPU-gebruik geen vooruitgang biedt.

Dat ben ik niet helemaal met je eens. Als ik even voor mezelf spreek; wij zetten op onze servers volledig in op meerdere cores en parallele execution. De 'consumenten' die onze app gebruiken zaten hier wel degelijk op te wachten, want alles is veel sneller en dus boodt het hun daadwerkelijk vooruitgang.

[ Voor 8% gewijzigd door flowerp op 07-05-2010 23:50 . Reden: Nieuwe reactie en er heeft nog niemand na mij gereageerd. Volgens GOT rules moet ik nu edit doen ;) ]

[H!GHGuY]

Zelfs in de embedded space is multi-core helemaal aan het doorbreken:
- FreeScale heeft single- tot octo-core PowerPC oplossingen voor embedded.
- De Cortex A8 ondersteund dacht ik dual-core terwijl de Cortex A9 dit verder zal opdrijven.
- Ook binnen MIPS zijn er vanuit Cavium Networks enkele extreem schalende oplossing tot 32 cores voor embedded. Deze laatste zijn bovendien per-core extreem multi-threading optimized (caches, TLB enz.)

Multi-core is gewoon op alle markten aan het doorbreken. Zelf zijn we er nog niet eens uit of we wel daadwerkelijk alle processing power die multi-core ons biedt efficiënt zullen kunnen opsouperen wegens de architectuur van de software.

[flowerp]

H!GHGuY schreef op zaterdag 08 mei 2010 @ 09:42:
[embedded examles]
Multi-core is gewoon op alle markten aan het doorbreken.

Interesant, dat is natuurlijk ook nog een hele andere markt. Ik volg deze niet zo, maar lees wel af en toe wat nieuws berichten over dual and multi-core chips in toekomstige versies van apparaten als de iPhone en de iPad. In veel gevallen zijn een groter aantal cores op een lagere clock ook gewoon power efficienter als minder cores op een hogere clock.

Dat is eigenlijk al de hoofdreden voor de move naar multi-core voor servers en desktop, maar het energy argument speelt bij de embedded dingen natuurlijk nog meer.

Bij mijn huidige stand van zaken post hierboven was ik trouwens nog helemaal de 12-core Magny Cours van AMD vergeten

Anno 2010 zitten we voor goedkope X86 servers dus zelfs al in het 12 core tijd perk

[MBV]

Vergeet niet dat op embedded niveau al veel met meerdere threads wordt gewerkt, omdat dat voor realtime-zaken eenvoudiger kan werken*. Een thread die motortje X aanstuurt, een andere die Y aanstuurt, een andere die sensor X verwerkt, enzovoort. Meerdere cores is daar dus veel eenvoudiger toe te passen.

* disclaimer: geen werkervaring, hear-say en colleges etc.

[JKVA]

flowerp schreef op vrijdag 07 mei 2010 @ 23:46:
[...] en Java's komende fork/join [...]

Jammergenoeg ziet het er niet naar uit dat we het Fork-Join Framework snel zullen zien. Java 7 gaat ontzettend traag en waarschijnlijk zit Fork-Join er niet in...

[flowerp]

JKVA schreef op zaterdag 08 mei 2010 @ 17:11:
[...]

Jammergenoeg ziet het er niet naar uit dat we het Fork-Join Framework snel zullen zien. Java 7 gaat ontzettend traag

Valt momenteel wel mee. Inderdaad, de vertraging in het verleden is substantieel geweest, maar we zitten nu al bij build 92 en een flink aantal dingen zitten er toch al echt in. Met een target final build van ergens begin 100, zie ik een release dit jaar toch wel zitten eigenlijk.

en waarschijnlijk zit Fork-Join er niet in...

Waarom denk je dat? Het zit er toch nu al gewoon een flink aantal builds in? Zie http://download.java.net/...current/ForkJoinPool.html

Deze zie ik er al in zitten sinds tenminste build 87 ofzo, en je kunt ook al geruime tijd een stand alone versie downloaden.

Zoals trouwens al reeds gezegd, naast Apple en Oracle/Sun is ook Microsoft flink op dit gebied bezig. In .NET 4.0 is hier extra nadruk op komen te leggen. Deze link geeft hier wat meer info over: http://blogs.msdn.com/pfx...e/2009/07/07/9822857.aspx

Hoewel alle implementaties nogal verschillen op details, is het onderliggende concept toch wel sterk overeenkomstig. Dit lijkt me positief, omdat programmeurs voor de 3 verschillende platforms dan makkelijker kunnen overschakelen en ideeen kunnen uitwisselen.

[H!GHGuY]

MBV schreef op zaterdag 08 mei 2010 @ 14:37:
Vergeet niet dat op embedded niveau al veel met meerdere threads wordt gewerkt, omdat dat voor realtime-zaken eenvoudiger kan werken*. Een thread die motortje X aanstuurt, een andere die Y aanstuurt, een andere die sensor X verwerkt, enzovoort. Meerdere cores is daar dus veel eenvoudiger toe te passen.

* disclaimer: geen werkervaring, hear-say en colleges etc.

Ik zou niet graag die software die jij beschrijft moeten onderhouden want alles gesynchroniseerd houden zou een hel zijn

Ik kan natuurlijk ook maar uit eigen werkervaring spreken (embedded, digitale televisie segment) maar onze software heeft behoorlijk wat threads. Onze belangrijkste applicatie heeft gemakkelijk 60 threads lopen. Echter zou ik de software op dit moment niet echt multi-threaded noemen in de zin dat ze schaalbaar is. Over het algemeen zijn slechts een aantal threads verantwoordelijk voor de bulk van het werk en staan de meeste andere te wachten op events. De real-time zaken zitten overigens logischerwijs in aparte RT-threads.

Nu we ook bij ons de overstap maken naar multi-core zien we er een behoorlijk uitdaging in om ook effectief schaalbaar te gaan werken. Hoewel dat niet meteen altijd een vereiste is. Ook bij ons zien we andere voordelen zoals lagere latencies voor RT-threads. Andere mogelijkheden zijn ook Asymmetrical Multi-Processing (meerdere OS'en draaien, al dan niet verschillend)

Ik kan je ook meegeven dat threading niet altijd voordelen heeft. In het verleden hebben we zelfs nog de omgekeerde beweging gezien bij collega's: begonnen met X threads die een pipeline vormden maar wegens synchronisatie problemen en context switching overhead verminderd tot slechts enkele.

Daarenboven heb je in de embedded space ook veel meer SoCs. Een processor bevat de dag van vandaag al snel crypto/regex/tcp-ip/... offloading engines die heel wat van de kerntaken van je processor uit de handen nemen. Gevolg is natuurlijk dat het power budget onder controle kan blijven door specialistische hardware.

[.oisyn]

flowerp schreef op vrijdag 07 mei 2010 @ 23:46:
Absoluut, je ziet dus dat zowel Microsoft met .NET 4 en Apple met GCD (Grand Central Dispatch) sterker op concurrency hebben ingezet.

Ook C++ in VS 2010 heeft een concurrency library gekregen. Samen met de C++0x lambda feature die ook wordt ondersteund kun je daarmee mooie parallelle loopjes mee schrijven, zonder je hoofd te breken over allerlei synchronisatie details.

[MBV]

H!GHGuY schreef op zaterdag 08 mei 2010 @ 19:50:
[...]

Ik zou niet graag die software die jij beschrijft moeten onderhouden want alles gesynchroniseerd houden zou een hel zijn
[snip]

Ik had dat van iemand die bij Oce heeft gewerkt: verschillende onderdelen worden door verschillende threads aangestuurd, en verschillende sensors in verschillende threads uitgelezen. Maar het verhaal is alweer een paar jaar oud. Binnenkort ga ik het allemaal meemaken

En dat [snip]-stuk was erg interessant om te lezen

[Alarmnummer]

.oisyn schreef op maandag 10 mei 2010 @ 01:52:
[...]
Ook C++ in VS 2010 heeft een concurrency library gekregen. Samen met de C++0x lambda feature die ook wordt ondersteund kun je daarmee mooie parallelle loopjes mee schrijven, zonder je hoofd te breken over allerlei synchronisatie details.

Alhoewel dat soort features erg mooi zijn voor de developer die meer kennis in huis heeft, de meeste developers die weten echt heel weinig van concurrency control af. En trust me dat je niet nog een box met features (lees problemen) in je systeem wilt hebben. En voor game development zal het niveau wel anders zijn dan de gemiddelde 'enterprisy' applicatie.

Dat is een van de redenen dat ik al meer dan 1.5 jaar zoet ben met Multiverse:
http://multiverse.codehaus.org
Een in Java geschreven STM implementatie. Met een STM kan je veel beter abstraheren dan met lock based concurrency, alhoewel er nog veel ruimte is voor performance en schaalbaarheids verbeteringen. Een groot deel van mijn zorgen zouden verdwijnen als er een schaalbare counter in de hardware zou zitten die altijd sneller unique timestamps kan uitdelen dan cpu's ze kunnen aanvragen.

[ Voor 8% gewijzigd door Alarmnummer op 12-05-2010 13:53 ]

[Alarmnummer]

flowerp schreef op zaterdag 08 mei 2010 @ 17:28:
Waarom denk je dat? Het zit er toch nu al gewoon een flink aantal builds in? Zie http://download.java.net/...current/ForkJoinPool.html

Ik ben ook erg blij met de fork join. Niet alleen om de functionaliteit die geboden wordt, maar ook het feit dat closures waarschijnlijk wel in Java 7 gaan komen ivm voorkomen ugly syntax als je van fork join framework gebruik wilt maken.

PS:
Ik heb thuis een dual Xeon 5500 thuis staan (dus 8 cores in totaal.. 16 als je hyperthreading gebruikt). Aan het eind van het jaar maar eens upgraden naar een Xeon 6500/7500.

[ Voor 15% gewijzigd door Alarmnummer op 12-05-2010 14:46 ]

[JKVA]

flowerp schreef op zaterdag 08 mei 2010 @ 17:28:
[...]
Waarom denk je dat? Het zit er toch nu al gewoon een flink aantal builds in? Zie http://download.java.net/...current/ForkJoinPool.html
[...]

Iemand van Sun vertelde me een tijd terug dat hij ook wel een voordeel zag in het feit dat Fork/Join niet in JDK 7 zou komen omdat dit nog wat extra tijd gaf om de API te overdenken (omdat closures nog zo nieuw zijn voor Java).

Anyway, blijkbaar was mijn info outdated.

[flowerp]

Alarmnummer schreef op woensdag 12 mei 2010 @ 13:56:
[...]
Ik heb thuis een dual Xeon 5500 thuis staan (dus 8 cores in totaal.. 16 als je hyperthreading gebruikt). Aan het eind van het jaar maar eens upgraden naar een Xeon 6500/7500.

Die dual quad core is ook ongeveer mijn configuratie, alleen dan in de vorm van een Mac Pro

Daar zijn nu alweer 12 core versies van te krijgen (24 dus met hyperthreading) en bij diverse andere merken die workstation class computers aanbieden druppelen dergelijke machines ook het assortiment binnen.

Hier een vroege benchmark over deze machine: http://www.barefeats.com/wst10.html

We zitten nu dus min of meer in het 12 core tijdperk, hoewel het nog wel vrij lang zal duren totdat 12 cores helemaal gemeengoed zijn geworden. Als ik om me heen kijk lijkt het erop dat nog steeds het merendeel van de computers dual-core is, ondanks de beschikbaar van quad en hex cores (al dan niet in dual opstelling).

De spreiding in cores op de markt is denk ik groter dan destijds de spreiding in Mhz op de markt. Ik kan me niet echt herinneren dat b.v. het gros van de markt nog op 100Mhz zat, terwijl er al 600Mhz machines (van de zelfde CPU architectuur) te krijgen waren.

Bovenstaande benchmark geeft ook aan dat nog steeds, ondanks het al jaren beschilkbaar zijn van multi cores en het nu na al die jaren toch echt wel eens duidelijk moet zijn dat Intel niet "binnenkort de clock weer drastisch omhoog gaat gooien", er nog steeds weinig software is die multi core echt goed benut.

Ik denk nog steeds dat met dingen als GCD en fork/join dit echt goed benutten een stuk makkelijker zal gaan worden, maar we zullen zien. Topic loopt nu bijna 4 jaar, en de stelling/vraag van de openings post is nog steeds actueel. Ben benieuwd naar posts over nog eens 4 jaar

[Alarmnummer]

flowerp schreef op dinsdag 24 augustus 2010 @ 15:22:
[...]
Die dual quad core is ook ongeveer mijn configuratie, alleen dan in de vorm van een Mac Pro

Wel een kick ass configuratie En mooie machines om te zien. Bijna iedereen om me heen die is intussen naar een mac aan het switchen, maar zo'n vooroorlogse desktop omgeving zoals Gnome heeft ook wel zijn charmes.

Daar zijn nu alweer 12 core versies van te krijgen (24 dus met hyperthreading) en bij diverse andere merken die workstation class computers aanbieden druppelen dergelijke machines ook het assortiment binnen.

Ik denk er over om volgend jaar weer te upgraden naar een 8 core per cpu en dan uiteraard weer een dual cpu configuratie. Helaas komt er voor de Xeon 5500 reeks volgens mij geen 8 core meer uit. Dus verplicht upgraden naar een 6500/7500 (dus ook ander moederbord).

We zitten nu dus min of meer in het 12 core tijdperk, hoewel het nog wel vrij lang zal duren totdat 12 cores helemaal gemeengoed zijn geworden. Als ik om me heen kijk lijkt het erop dat nog steeds het merendeel van de computers dual-core is, ondanks de beschikbaar van quad en hex cores (al dan niet in dual opstelling).

Serverside zie je ze wel steeds meer terug. De reden dat ik zoveel cores wil is ivm testen Multiverse. Heb laatst al het genoegen gehad om op een Azul Vega 2 met 768 cores te kunnen testen

Bovenstaande benchmark geeft ook aan dat nog steeds, ondanks het al jaren beschilkbaar zijn van multi cores en het nu na al die jaren toch echt wel eens duidelijk moet zijn dat Intel niet "binnenkort de clock weer drastisch omhoog gaat gooien", er nog steeds weinig software is die multi core echt goed benut.

Hmmm.. de klok boeit me eigelijk niet veel. Wat bij mij voornamelijk voor problemen zorgt zijn cache misses en cas kosten. Het lezen van een veld dat niet in de cache zit of een extra cas, kan zo al voor een loss van 50% performance opleveren bij sommige stukken code. Dus nog meer megaherzen er tegen aan gooien, zal voor mij niet echt voor performance verbeteringen zorgen. Intel VTune is trouwens ideaal om op instructie nivo te zien waar nou echt de kosten zitten.

Uiteraard is het natuurlijk wel goed voor het patsgehalte (en dat is voor een zichzelf respecterende it'er ook belangrijk).

Ik denk nog steeds dat met dingen als GCD en fork/join dit echt goed benutten een stuk makkelijker zal gaan worden, maar we zullen zien. Topic loopt nu bijna 4 jaar, en de stelling/vraag van de openings post is nog steeds actueel. Ben benieuwd naar posts over nog eens 4 jaar

Idd. Ik heb gisteravond een request om te spreken op JFall de deur uit gedaan: Modern Concurrency: STM, Actors and Transactors. Maar ik heb nog niet echt het gevoel dat we de holy grail hebben gevonden. Je lost veel traditionele problemen op, maar je krijgt er ook een hele lading nieuwe bij. En sommige problemen die je gewoonlijk al hebt (zoals het aanspreken van niet transactionele resources zoals een webservice) worden dan extra duidelijk.

[ Voor 4% gewijzigd door Alarmnummer op 01-09-2010 20:28 ]

[Hydra]

flowerp schreef op dinsdag 24 augustus 2010 @ 15:22:
We zitten nu dus min of meer in het 12 core tijdperk, hoewel het nog wel vrij lang zal duren totdat 12 cores helemaal gemeengoed zijn geworden. Als ik om me heen kijk lijkt het erop dat nog steeds het merendeel van de computers dual-core is, ondanks de beschikbaar van quad en hex cores (al dan niet in dual opstelling).

Volgens mij verwar je desktops met servers. Wij zijn met een upgradeproject bezig waar 4 jaar oude dualcores vervangen gaan worden voor server met 8 quadcores, 32 cores totaal dus. En dit is een overheidsproject dus die lopen niet enorm voor ofzo...

[Alarmnummer]

Alarmnummer schreef op woensdag 01 september 2010 @ 20:18:
[...]

Idd. Ik heb gisteravond een request om te spreken op JFall de deur uit gedaan: Modern Concurrency: STM, Actors and Transactors. Maar ik heb nog niet echt het gevoel dat we de holy grail hebben gevonden. Je lost veel traditionele problemen op, maar je krijgt er ook een hele lading nieuwe bij. En sommige problemen die je gewoonlijk al hebt (zoals het aanspreken van niet transactionele resources zoals een webservice) worden dan extra duidelijk.

Mijn verzoek is goedgekeurd. Dus we me wil horen ijlen over concurrency kan me horen op JFall 2010.

[Nick_S]

Alarmnummer schreef op woensdag 15 september 2010 @ 23:24:
[...]


Mijn verzoek is goedgekeurd. Dus we me wil horen ijlen over concurrency kan me horen op JFall 2010.

Ik ben er zeker bij. Erg interessant onderwerp.

[Icelus]

Linux May Need a Rewrite Beyond 48 Cores
"There is interesting new research coming out of MIT which suggests current operating systems are struggling with the addition of more cores to the CPU. It appears that the problem, which affects the available memory in a chip when multiple cores are working on the same chunks of data, is getting worse and may be hitting a peak somewhere in the neighborhood of 48 cores, when entirely new operating systems will be needed, the report says. Luckily, we aren't anywhere near 48 cores and there is some time left to come up with a new Linux (Windows?)."

Zou een OS als BeOS hier minder last van hebben?

[H!GHGuY]

Het artikel doet de paper oneer aan door zijn poging om hier wat sensatie uit te kloppen.
Lees even de paper zelf en je zal zien wat men al lang wist:
er zitten scalability bottlenecks in de kernel, die 1 per 1 opgelost worden.

In de paper beschrijven ze ook dat ze een aantal gevallen van false-sharing hebben opgelost. Ook gebruikten ze een nieuwe shared counter methode om reference counting te versnellen op multi-core.
Helemaal niets nieuws onder de zon.

Binnen de kernel is er trouwens de consensus om niet te gaan optimizen voor meer dan X cores, als de mainstream markt daar nog lang niet is. Wees er maar zeker van dat Linux nog betrekkelijk lang mee zal kunnen op multi-core.

[YopY]

Gelukkig zal het nog wel een tijdje duren - als het ooit al zover komt - voordat we aan 48 cores zitten. Eerlijk gezegd zie ik het niet gebeuren, en zal er binnen 5 jaar een balans gevonden worden tussen multicore CPU's (evt. met een soort van turbo mode) en specifieke extra componenten voor het parralel verwerken van een bepaald soort data (denk OpenCL en companen).

[Olaf van der Spek]

YopY schreef op vrijdag 01 oktober 2010 @ 23:29:
Gelukkig zal het nog wel een tijdje duren - als het ooit al zover komt - voordat we aan 48 cores zitten.

Oh ja? 8 sockets met 6 cores en je bent er al...
Ik denk dat het threads is, niet cores, dus dan ben je er al met 4 sockets met 6 cores / 12 threads.

[Alarmnummer]

YopY schreef op vrijdag 01 oktober 2010 @ 23:29:
Gelukkig zal het nog wel een tijdje duren - als het ooit al zover komt - voordat we aan 48 cores zitten. Eerlijk gezegd zie ik het niet gebeuren, en zal er binnen 5 jaar een balans gevonden worden tussen multicore CPU's (evt. met een soort van turbo mode) en specifieke extra componenten voor het parralel verwerken van een bepaald soort data (denk OpenCL en companen).

Alhoewel het aantal cores minder snel groeit dan ik had verwacht, zie ik al een tijd lang geen verhoging meer van de kloksnelheid (zelfs vaak een verlaging). Zo lang er geen oplossing is voor het de gegenereerde warmte, denk ik dat het aantal cores netjes blijft stijgen.

Misschien dat het voor desktop machines niet zo snel zal gaan, serverside zie ik wel steeds meer cores verschijnen. Intel heeft net een echte 8 core cpu uitgebracht en volgend jaar komt de 16 core bulldozer van AMD op de markt. Ik neem aan dat het dan ook niet lang zal duren dat intel met een 16 pitter op de markt gaat komen.

Dus stel dat je iedere 3 jaar een verdubbeling van het aantal cores krijgt, dan zit je over 6 jaar al op 32/64 cores op een enkel cpu (en dat zonder ht).

Imho meer een zaak van when dan van if.

[flowerp]

flowerp schreef op zondag 01 februari 2009 @ 22:23:
[...]
Maar weer eens een tussentijdse update. Slechts enkele maanden later ziet het beeld bij Mycom er nu zo uit:

code:

Aantal cores
1x  2
2x 10
3x  1
4x 12
(totaal 25 cpus)

Er zijn nu meer quad cores leverbaar dan dual cores. Het gemiddeld aantal cores bij deze winkel is dan ook van ruim 2.5 naar bijna 3 gegaan.

Tijdje geleden dat ik dit overzicht heb gemaakt (moet er maar eens een grafiekje van tekenen eigenlijk), maar hier weer eens update van onze vrienden bij MyCom:

code:

Aantal cores
1x  1
2x 17
3x  1
4x 12
6x  5
(totaal 36 cpus)

Wel vreemd is deze keer dat de totale lijst zonder filtering 50 cpus is. Er missen er dus 14 die waarschijnlijk volgens MyCom dan 0 cores ofzo hebben

Volgens bovenstaande is het gemiddelde cores nu 3.2, een marginale stijging t.o.v. van de vorige meeting.

Vanwege de significante afwijking van 14 cpus waarvan ik geen zin heb om na te kijken welke dat zijn en hoevel cores die dan hebben, heb ik ook even bij Alternate gekeken deze keer.

code:

Aantal cores
1x  1
2x 29
3x  3
4x 22
6x  6
(totaal 61 cpus)

Alternate kent gelukkig geen cpus met 0 cores. Hier is het gemiddelde dus wel correct en dat is 3.04.

We zien dat er aan de ene kant wel de hex-core voor het consumenten segment is bijgekomen, maar dat de dual core nog volledig dominant is. Wat dat betreft is er sinds de 4 jaar(!) sinds de opening van dit topic eigenlijk maar bar weinig veranderd.

Een en ander lijkt ook te maken te hebben met de opkomst van extreem goedkope complete desktop PCs voor prijzen waar je vroegah amper een case voor kon kopen. Deze komen in de regel met een dual core. Ook is er sprake van een opkomst van cpus met ingebouwde gpu. De ruimte voor extra cores wordt dan ingenomen door deze gpu, wat de stijging van het gemiddeld aantal cpu cores ook tegengaat.

[.oisyn]

flowerp schreef op dinsdag 28 december 2010 @ 22:44:
Wel vreemd is deze keer dat de totale lijst zonder filtering 50 cpus is. Er missen er dus 14 die waarschijnlijk volgens MyCom dan 0 cores ofzo hebben

Misschien rekenen ze een Core i7 als een 8-core?

Ik heb m'n eigen core 2 duo trouwens omgeruild voor een core 2 quad die ik op de kop had getikt, puur om mee te experimenteren .

[ Voor 17% gewijzigd door .oisyn op 28-12-2010 22:52 ]

[flowerp]

.oisyn schreef op dinsdag 28 december 2010 @ 22:50:
[...]

Misschien rekenen ze een Core i7 als een 8-core?

Hmmm, en dat de 8 core selectie dan gewoon niet in het filter staat. Zou kunnen ja.

Ik heb m'n eigen core 2 duo trouwens omgeruild voor een core 2 quad die ik op de kop had getikt, puur om mee te experimenteren .

Zo toe maar, das wel heel erg luxe!

Ik besefte net dat Tweakers zelf ook een handig core filter heeft in de price watch. Deze geeft het volgende beeld:

code:

1x  61 
2x 106
3x   7 
4x 145
6x  17 
8x   1
12x  1
(Totaal 338 cpus)

Hoewel dit een mix is van cpus voor huis tuin en keuken computers en servers, is het gemiddelde hier juist het laagste: 2.95. Tweakers raakt hier trouwens ook 1 cpu kwijt. Zonder filter is het totaal 339, met het filter voor alle verschillende cores aan of handmatig bij elkaar opgeteld 338.

Iemand met toegang tot de DB van tweakers zou hier misschien wel een query voor kunnen schrijven die zo'n overzicht als ik hier maak automatisch neer zet. Als tweakers ook intern de oude beschikbaarheid per datum bijhoudt zou je hier zelfs een grafiek uit kunnen maken

[.oisyn]

Zonder filter is het totaal 339

Ik zie er zonder filter ook maar 338?

.edit: ah, het lijkt een bug te zijn met de telling denk ik. Als je op die pagina landt krijg je 339 te zien, zodra je een filter aan en weer uit zet zijn het er nog 338

[Olaf van der Spek]

.oisyn schreef op dinsdag 28 december 2010 @ 23:17:
[...]

Ik zie er zonder filter ook maar 338?

.edit: ah, het lijkt een bug te zijn met de telling denk ik. Als je op die pagina land krijg je 339 te zien, zodra je een filter aan en weer uit zet zijn het er nog 338

Heeft volgens mij te maken met produkten zonder prijs.

[cariolive23]

YopY schreef op vrijdag 01 oktober 2010 @ 23:29:
Gelukkig zal het nog wel een tijdje duren - als het ooit al zover komt - voordat we aan 48 cores zitten.

Bij Dell kun je de servers gewoon in de webshop bestellen: 4x12 core AMD Opteron uit de 6100-serie.

[flowerp]

cariolive23 schreef op woensdag 29 december 2010 @ 08:34:
[...]

Bij Dell kun je de servers gewoon in de webshop bestellen: 4x12 core AMD Opteron uit de 6100-serie.

Inderdaad, dat klopt. Voor entry-level tot medium level servers zijn we dus nu al wel degelijk het 48 core tijdperk in getreden. In het echt hogere segment waar machines custom build voor je worden en waar de prijs is van het type if you have to ask you can't afford it, zijn er al langer veel meer cores te krijgen.

In de vorige overzichten richten ik me voornamelijk op de consumenten en prosumer markten. De gedachte is een beetje dat de server wel 48 cores kan hebben, maar dat de gemiddelde programmeur dat gewoon niet beseft.

Meerdere cores gaan denk ik pas echt leven bij programmeurs als hun eigen machine en die van hun vrienden zoveel cores heeft. Misschien is er ook wel gewoon een nieuwe generatie programmeurs voor nodig, die is begonnen met programmeren toen computers al standaard met 16 cores kwamen.

Hoewel ik in de high-performance business zit en je het daar juist niet zou verwachten, blijf ik hordes programmeurs tegenkomen die zijn opgegroeid met de gedachte dat parallel programmeren alleen iets is voor hele uitzonderlijke gevallen, en dat alles dan heel ingewikkeld wordt en debuggen met name bijna onmogelijk wordt omdat je nergens meer iets deterministisch over kunt zeggen.

Met zo'n instelling wordt het natuurlijk nooit wat...

Tevens valt op trouwens dat in tegenstelling tot tijdens de Mhz race, de range van cores nogal groot is. Aan de ene kant hebben we nog volop single en met name dual cores, aan de andere kant is die 12 core CPU toch echt beschikbaar en dat voor een prijs die makkelijk door een prosumer is op te brengen. En zoals cario al levend aangeeft, die 48 core bak is ook wel te bestellen voor ietsje meer geld maar ook weer niet voor zoveel dat een bedrijf er volledig krom van ligt.

Dat is dus een spreiding van zo'n 12x en 48x.

Ik kan me niet herinneren dat toen de 1.2GHz machines volop in de winkel lagen, dat 100- en 200Mhz ook nog gewoon veel verkochte snelheden waren. En ook niet met 120Mhz vs 10 en 20Mhz. Laat staan dat toen 100Mhz computers gebruikelijk waren, er al redelijk betaalbare servers waren van 4.8Ghz...

[Olaf van der Spek]

flowerp schreef op woensdag 29 december 2010 @ 19:09:
In de vorige overzichten richten ik me voornamelijk op de consumenten en prosumer markten. De gedachte is een beetje dat de server wel 48 cores kan hebben, maar dat de gemiddelde programmeur dat gewoon niet beseft.

Wat voor server apps schrijft de gemiddelde programmeur?

Ik kan me niet herinneren dat toen de 1.2GHz machines volop in de winkel lagen, dat 100- en 200Mhz ook nog gewoon veel verkochte snelheden waren. En ook niet met 120Mhz vs 10 en 20Mhz. Laat staan dat toen 100Mhz computers gebruikelijk waren, er al redelijk betaalbare servers waren van 4.8Ghz...

Kloksnelheid was/is vooral afhankelijk van procestechnologie. Aantal cores van die grootte. Een i7 1 ghz is niet goedkoper om te maken dan een i7 3 ghz.
Ook is CPU performance vaak "goed genoeg". Een film bekijken gaat niet sneller met een quad core. Internetten ook niet.

[.oisyn]

flowerp schreef op woensdag 29 december 2010 @ 19:09:
en dat alles dan heel ingewikkeld wordt en debuggen met name bijna onmogelijk wordt omdat je nergens meer iets deterministisch over kunt zeggen.

Maar dat is gewoon waar. De debuggability van parallelle algoritmes is een ramp, en daar zijn een stuk betere tools voor nodig dan gewoon de standaard debugger zoals je die gewend bent.

[dcm360]

Olaf van der Spek schreef op woensdag 29 december 2010 @ 20:30:
Ook is CPU performance vaak "goed genoeg". Een film bekijken gaat niet sneller met een quad core. Internetten ook niet.

Leuke voorbeelden Decoderen van video is juist uitstekend te parallelliseren, waardoor videokaarten er heel erg geschikt voor zijn. Een quadcore heeft dus geen voordeel tov een singlecore, omdat je liever de cpu toch al niet gebruikt.
En ook internetten gaat sneller (worden) door meerdere cpu's te gebruiken. Met de huidige prestatiewedloop wordt het ineens interessant voor browserbouwers om multithreading te gaan gebruiken (multicores beginnen redelijk standaard te worden, dus daar is nog veel winst te halen).

[flowerp]

Olaf van der Spek schreef op woensdag 29 december 2010 @ 20:30:
[...]

Wat voor server apps schrijft de gemiddelde programmeur?

Server apps waar ik ook als de netwerk latency laag is nog steeds moet wachten zodra een request een beetje ingewikkeld is.

Kloksnelheid was/is vooral afhankelijk van procestechnologie. Aantal cores van die grootte. Een i7 1 ghz is niet goedkoper om te maken dan een i7 3 ghz.
Ook is CPU performance vaak "goed genoeg". Een film bekijken gaat niet sneller met een quad core. Internetten ook niet.

Gevaarlijke opmerking en inderdaad 1 van de "problemen". Programmeurs die denken dat "alles wel goed genoeg is". Waren er jaren geleden ook niet programmeurs die vonden dat 100Mhz+ CPUs dikke onzin waren omdat WP er echt niet sneller mee ging?

De uitdaging ligt natuurlijk in steeds betere apps maken, met meer data, betere beelden etc.

Voor de "sustained" CPU usage zullen niet continue alle cores in gebruik hoeven te zijn, maar de piek capaciteit kan wel enorm omhoog. Zolang ik nog steeds apps heb die er 10 seconden over doen om op te starten terwijl ik op een machine zit met 16GB memory en een Areca 1880 met daarop 4 snelle SSDs in RAID heb en ik via iostats -mx zie dat er GEEN IO bottleneck is, maar volledig 1 core op 100% staat... ja, dan kan het nog steeds beter en sneller.

Dit komt op veel plekken terug. Als ik een global search doe in Eclipse op een keyword, dan moet ik nog steeds enkele seconden wachten. Waarom is dat niet gewoon instant? Ook hier gaat weer 1 core naar 100% en is mijn IO belasting de eerste keer nihil en de 2de keer als mijn hele workspace in het buffer geheugen staat gewoon niets.

Ik wijt dat aan programmeurs die allemaal denken dat alles wel "goed genoeg" is.

Met die mentaliteit kunnen we wel gewoon stoppen met hardware ontwikkeling en alle engineers lekker naar huis sturen. Wat we nu hebben is immers "goed genoeg"?

.oisyn schreef op woensdag 29 december 2010 @ 20:51:
[...]

Maar dat is gewoon waar. De debuggability van parallelle algoritmes is een ramp, en daar zijn een stuk betere tools voor nodig dan gewoon de standaard debugger zoals je die gewend bent.

Als je zelf parallel execution engines maakt, zoals b.v. in games, dan geef ik je gelijk.

Als je echter gebruikt maakt van b.v. een join/fork framework, of zelfs gewoon een thread pool die jobs execute dan geef ik je geen of minder gelijk.

Het komt er dan grotendeels op neer dat je je data opsplitst in stukken en/of je algoritme recursief defineerd. Op die manier komt het eigenlijk gewoon niet voor dat je race problemen of moeilijke visibility corner cases tegenkomt.

Ook is er dan geen sprake van de gevreesde overhead die je wel krijgt als je handmatige threads gaat lopen te spawnen.

Stel ik heb een probleem van 100.000 items en wil hier een of andere bewerking op doen. Ik defineer dan een algoritme die deze bewerking uitvoert in termen van een simpele recursie, waarbij ik bij een X aantal items de bewerking direct doe en anders afsplits. Die X moet ik gokken, maar de marge voor een goede X is in de praktijk heel erg ruim. Tenzij je veels te hoog of veels te laag gokt (en dat merk je snel) kun je deze moeilijk fout gokken.

Dit geef ik aan mijn join/fork framework. Deze heeft al een thread-pool draaien. Dus er worden niet telkens threads gemaakt en het aantal beschikbare worker threads wordt automatisch door het framework bepaald (voor CPU bound werk is dat in de regel gewoon je aantal cores). Afhankelijk van hoeveel ander werk er is kan het zijn dat 16 threads tegelijk aan mijn probleem werken of dat het efficiënter is voor de totale performance dat toevallig 1 enkele thread het hele probleem afwerkt.

Niet elk probleem kan in deze vorm gegoten worden, maar verassend veel wel. Nogmaals, je hoeft via een dergelijk aanpak niet aan ingewikkeld parallel debuggen te doen

[Olaf van der Spek]

flowerp schreef op woensdag 29 december 2010 @ 21:53:
Server apps waar ik ook als de netwerk latency laag is nog steeds moet wachten zodra een request een beetje ingewikkeld is.

Maar dat heeft vaak niks met parallel programmeren te maken.

Gevaarlijke opmerking en inderdaad 1 van de "problemen". Programmeurs die denken dat "alles wel goed genoeg is". Waren er jaren geleden ook niet programmeurs die vonden dat 100Mhz+ CPUs dikke onzin waren omdat WP er echt niet sneller mee ging?

Ik bedoelde dat CPU performance goed genoeg is. Niet dat app performance goed genoeg is.

[.oisyn]

flowerp schreef op woensdag 29 december 2010 @ 21:53:
Als je zelf parallel execution engines maakt, zoals b.v. in games, dan geef ik je gelijk.

Als je echter gebruikt maakt van b.v. een join/fork framework, of zelfs gewoon een thread pool die jobs execute dan geef ik je geen of minder gelijk.

Het komt er dan grotendeels op neer dat je je data opsplitst in stukken en/of je algoritme recursief defineerd. Op die manier komt het eigenlijk gewoon niet voor dat je race problemen of moeilijke visibility corner cases tegenkomt.

Ook is er dan geen sprake van de gevreesde overhead die je wel krijgt als je handmatige threads gaat lopen te spawnen.

Sorry maar dat is gewoon nonsens. Uiteraard gebruikt iedere zelfrespecterende multicore programmeur een jobsysteem en threadpool, dus ook wij in games, maar dat doet echt compleet niets af aan het feit dat je ondanks dat weldegelijk raceconditions kunt krijgen, zeker als het gebruikte algoritme inherente data dependencies heeft en je je code niet wilt peperen met mutexes. Met name als je datastructuren meer grafen zijn dan bomen. Vertel jij maar eens hoe je een multicore sweep & prune garbage collection gaat implementeren op de door jou voorgestelde manier.

Zelf threads maken staat echt compleet los van het geschetste probleem (lastige debuggability), dus waarom je dat erbij betreft is me eigenlijk een raadsel

[ Voor 7% gewijzigd door .oisyn op 29-12-2010 22:38 ]

[MBV]

@flowerp: Je hebt gedeeltelijk gelijk: we moeten met z'n allen functioneel gaan programmeren, dan lossen de frameworks het allemaal wel op. Toch houd je om diverse redenen een groot aandeel C++ programmeurs, die nog steeds fouten met null-pointers maken (ik nooit ). Dan krijg je een stacktrace na een test terug, met de mededeling dat de fout zich af en toe voordoet. Dat is nu al een crime met single-core, single-threaded programmeren. Hoe stel je je dat voor bij multi-threaded? Met Java/C# loopt dat wel los, dat geloof ik zeker, maar tot er betere statische analyse beschikbaar is die multi-threaded gedrag kan voorspellen zie ik het somber in.

Waarom kan de null-pointer met statische analyse nog niet worden uitgebannen? Waarom moeten programmeurs altijd weer pointers gebruiken in de meest onzinnige situaties?

@.iosyn: het staat er niet compleet los van, zelf uitvinden van paradigma's (met bijbehorende frameworks) is altijd moeilijker dan het goed toepassen van een fatsoenlijk uitgedacht framework. Al zovaak gezien dat iemand het zelf even wilde uitvinden, want 'dat moet toch makkelijker kunnen'.

[ Voor 15% gewijzigd door MBV op 29-12-2010 22:38 ]

[.oisyn]

Maar dan ben je je library aan het debuggen, niet het algoritme, en daar ging het me nou juist om toen ik dat schreef. Oftewel, het staat er wél compleet los van. Een parallel algoritme dat last heeft van race conditions is gewoon een bitch om te debuggen, zelfs als je proven technology gebruikt om je jobs te schedulen.

[Alarmnummer]

flowerp schreef op woensdag 29 december 2010 @ 21:53:
[...]
Server apps waar ik ook als de netwerk latency laag is nog steeds moet wachten zodra een request een beetje ingewikkeld is.

Wat mijn observatie tot zover is, en heb al bij heel wat bedrijven als consultant gezeten, is dat voor de meeste webapplicaties er veel/onnodig dure operaties gedaan worden, met name database en netwerk communicatie. Ik heb nog maar weinig problemen gezien waarbij de CPU/geheugenbus echt de bottleneck is gaan vormen, of het onnodig is gaan vormen doordat er onhandige oplossingen gekozen zijn (vooral gc in Java is een totale performance/schaalbaarheids killer).

Extra threading er tegen aan smijten is in veel gevallen alleen maar symptoom bestrijding of maakt het probleem zelfs nog erger. Bij de meeste bedrijven is performance/schaalbaarheid iets dat je in productie wel gaat oplossen en zeker geen integraal onderdeel van het ontwikkel proces. Voor Multiverse heb ik intussen een microbenchmark frameworkje opgezet waarmee ik performance over tijd heen kan monitoren en waarbij je ook 'eenvoudig' verschillende benchmarks met elkaar kunt combineren in een enkele view.

Ik werk zelf sinds een jaartje voor een klein bedrijf in Boxtel en we zijn al een paar jaar bezig met een soortement van applicatie server, maar ipv de standaard set met JEE diensten hebben we andere zoals beveiligd document opslag, semantische analyze en doorzoeken van documenten en bericht uitwisseling (met document-attachements). Het is de bedoeling dat dit lineair kan schalen. Tot zover zijn de voornaamste performance/schaalbaarheids problemen hier ook IO en onnodige netwerk communicatie,

"als we een framework gebruiken dat lineair schaalbare oplossingen mogelijk maakt, dan moet onze applicatie ook lineair schaalbaar zijn".

Ben intussen al meer dan een jaar puin aan het ruimen. Het voornaamste probleem met concurrency dat ik bij ons tot zover zie is dat er veel bugs in zitten. Simpele zaken als een een non atomic check/modify worden over het hoofd gezien. En dat sommige technieken niet goed op elkaar aansluiten (bv gigaspaces en traditioneel concurrency control). Veel datagrid oplossingen gaan er van uit dat een object alleen wordt gematerialized als het gelezen/geschreven moet worden en direct daarna weer gedematerialized kan worden. In ons geval gaat dit niet op aangezien we met een aantal vrij complexe lokale objecten zitten die je niet de hele tijd door de space wilt halen.

Zaken als visibility problemen is voor de meeste developers echt een ver weg van hun bed show.

Het feit dat het in een cloud draait maakt het nog veel troebeler.

Gelukkig heb ik Multiverse nog om mijn skills een beetje op bot te kunnen vieren.

[ Voor 14% gewijzigd door Alarmnummer op 29-12-2010 23:53 ]

[Alarmnummer]

deautistifing content.

grrr... wrong screen...

[ Voor 38% gewijzigd door Alarmnummer op 29-12-2010 23:52 ]

[flowerp]

.oisyn schreef op woensdag 29 december 2010 @ 22:35:
[...]

Sorry maar dat is gewoon nonsens.

Het is zeker geen nonsens, wij gebruiken dit bijna elke dag in de praktijk. Veel business problemen zijn best wel makkelijk hier in uit te drukken. Het gaat dan om dingen als sommaties, aggregaties, gemiddelden, filtering, percentages berekenen, voorkomens tellen van drempel waardes, dat gaat allemaal best makkelijk.

We werken dan tevens datasets van niet geringe grote door (zo'n 200GB) en die worden ook op deze manier gedaan. Dat betreft vooral veel aggregatie, wat zich uitstekend leent hiervoor. Dit parallel laten draaien is gedaan door programmeurs zonder bijzonder veel ervaring met parallel programmeren en het draait gewoon uitstekend. Omdat we genoeg IO bandbreedte hebben (4xAreca 1880 met 32 Intel X25-E's) is de schaalbaarheid nagenoeg perfect. Met 16 cores gaat het vaak een goede 14x of meer zo snel als met een enkele core.

Ik heb een programmeur die dit gedaan heeft maar minimale begeleiding hoeven te geven. We zijn zeker niet in de weer geweest met ingewikkelde parallele debugging technieken.

Vertel jij maar eens hoe je een multicore sweep & prune garbage collection gaat implementeren op de door jou voorgestelde manier.

Ik heb volgens mij nooit gezegd dat een GC algo ff makkelijk met een threadpooltje gemaakt kan worden. Dat is een zeer specialistisch probleem wat duidelijk afgedekt is door mijn disclaimer:

Niet elk probleem kan in deze vorm gegoten worden

Zelf threads maken staat echt compleet los van het geschetste probleem (lastige debuggability), dus waarom je dat erbij betreft is me eigenlijk een raadsel

Ik haalde dat erbij omdat je in de praktijk juist met low-level technieken zoals handmatig threads aanmaken en niets meer gebruiken dan een simpele synchronized en Oject.wait/notify (java) het snel heel ingewikkeld kan worden. Juist met higher level elementen kan het dikwijls heel eenvoudig gehouden worden en kan er toch flinke winst geboekt worden. Denk ook aan dingen als gewoon een blocking queue, een phaser of een count down latch. Dat zijn niet al te high-level dingen (zoals b.v. een parallel array of join/fork), maar kan dingen al enorm veel makkelijker maken.

Soms kunnen juist simpele dingen je heel snel winst geven. Neem een typische backing bean in Java EE die b.v. 4 data items nodig heeft: een customer, een order, een paylist en een company. De code kan die na elkaar stuk voor stuk gaan ophalen, maar een simpele @Asynchronous annotation op de method van je service class en je kunt deze parallel laten ophalen. Je krijgt dan b.v. een Future<Customer> terug en je code blokt dan pas als zo'n item echt nodig is.

Hier hoef je niet echt hogere wiskunde voor gestudeerd te hebben om toe te passen en het kan toch een leuke winst geven en een algehele beter gebruikt van je resources tot gevolg hebben.

[Alarmnummer]

flowerp schreef op woensdag 29 december 2010 @ 23:53:
[...]
We werken dan tevens datasets van niet geringe grote door (zo'n 200GB) en die worden ook op deze manier gedaan. Dat betreft vooral veel aggregatie, wat zich uitstekend leent hiervoor. Dit parallel laten draaien is gedaan door programmeurs zonder bijzonder veel ervaring met parallel programmeren en het draait gewoon uitstekend. Omdat we genoeg IO bandbreedte hebben (4xAreca 1880 met 32 Intel X25-E's) is de schaalbaarheid nagenoeg perfect. Met 16 cores gaat het vaak een goede 14x of meer zo snel als met een enkele core.

Waar zit je voor dit soort problemen? Tom Tom, electronic trading company? De meeste developers komen niet met dit soort 'mooie' problemen in aanraking.

[flowerp]

Olaf van der Spek schreef op woensdag 29 december 2010 @ 22:16:
[...]

Maar dat heeft vaak niks met parallel programmeren te maken.

Ja wel hoor. Hoewel er natuurlijk inderdaad ook op veel andere terreinen winst te halen is, zoals simpelweg slimmere algoritmes, slimmere indeling van je data, slim cachen en voorberekenen enzo, is het dikwijls ook gewoon domweg dat de CPU niet optimaal gebruikt wordt.

Ik had het er een poosje terug al over. We krijgen een klacht dat 1 enkele request lang duurt (b.v. 5 seconden) en we zien dan in de logs terug dat gewoon 1 core op 100% stond. Bij de consultancy die ik zo nu en dan doe zie ik dat dit bij andere apps van andere teams ook dikwijls zo is.

Veel web-apps zijn volledig ingericht om enorme hoeveelheden users te bedienen (opzich geen gek idee natuurlijk), maar doen niets om 1 enkele user sneller van dienst te zijn. Elke request wordt volledig sequentieel afgehandeld. Als je op een gegeven moment niet genoeg users hebt om alle je resources optimaal benutten zit dus een gedeelte van je resources idle. Sommige users wachten op zo'n moment dan langer dan ze misschien zouden hebben moeten wachten als je meer parallele technieken had gebruikt.

Ik bedoelde dat CPU performance goed genoeg is. Niet dat app performance goed genoeg is.

En hoe maak je dan de app performance beter met dezelfde CPU?

[.oisyn]

Fair enough, je daadwerkelijke punt is me nu een stuk duidelijker geworden. Relatief eenvoudige parallellisme is natuurlijk met de juiste toolkit ook daadwerkelijk vrij simpel te implementeren. Wat dat betreft bedoelde je niet zozeer dat de stelling "dat alles dan heel ingewikkeld wordt en debuggen met name bijna onmogelijk wordt omdat je nergens meer iets deterministisch over kunt zeggen" per definitie onjuist was alswel dat die argumentatie niet valide was om maar van parallellisme vandaan te blijven omdat je er in die simpele cases niet tegenaan loopt. Interpreteer ik dat goed zo?

[ Voor 8% gewijzigd door .oisyn op 30-12-2010 00:07 ]

[Alarmnummer]

@.iosyn: het staat er niet compleet los van, zelf uitvinden van paradigma's (met bijbehorende frameworks) is altijd moeilijker dan het goed toepassen van een fatsoenlijk uitgedacht framework. Al zovaak gezien dat iemand het zelf even wilde uitvinden, want 'dat moet toch makkelijker kunnen'.

Het gevaar aan frameworks, vooral met het oog op concurrency, is dat het problemen obscuren of dat ze het zelfs bewust verdoezelen en mensen bad practices aanleren.

zie:
http://blog.xebia.com/200...g-and-visibility-problems

Ik ben zeker niet vies van een goed framework, maar soms is een stukje custom code ook een perfecte oplossing (als je weet hoe het moet).