[alg] Gebruik maken van multiple cores

quote:

Alarmnummer schreef op donderdag 30 december 2010 @ 00:00:
[...]

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

We zijn een semi-wetenschappelijk instelling die software schrijft voor (wetenschappelijke) experimenten en recent ook surveys.

Een gedeelte van onze app is de beheerders portal die niets anders doet dan het gros van andere web applicaties (aanmelden, inloggen, overzicht van eigen ingevoerde experimenten bekijken, etc). Ook, of misschien juist, dit gedeelte van de app komt in aanmerking voor versnelling. Dat komt omdat het hier om interactief gebruik gaat waar mensen nogal kritischer zijn.

Daarnaast hebben we ook een module die ruwe gegevens van sensors verwerkt. Dan kan b.v. gaan om zo'n 20 events per seconde gedurende 2 dagen, of het kan een kort durende meeting zijn van zo'n 1000 events per seconde van 1000 aparte sensors. Om dit een beetje netjes te persisten met weinig threads gebruiken we wat simpele concurrent transfer queues met een kleine hierarchy en daarachter een paar workers die het batchen en dan persisten. Dit is nou ook weer niet zo enorm spannend dat het een publicatie van een artikel waard is

Over deze ruwe data die soms wel ~200GB groot kan worden, worden dan de genoemde aggregaties gedaan die dan voornamelijk in tabel vorm in de beheerders module bekeken worden. Deze draaien in de eerste instantie als batch jobs voor de meest voor de hand liggende aggregaties. De dataset die hier bij over blijft is nog steeds vrij groot, en hier kan een gebruiker dan nog real-time diverse operaties op uitvoeren zoals verdere aggregatie, inzoomen op data of gewoon filtering.

De hardware klinkt misschien wel heftig, maar we doen eigenlijk voornamelijk zelfbouw en de kosten zijn helemaal niet zo gek. Grofweg wat je krijgt door gewoon de stuksprijzen vanuit de pricewatch te pakken

quote:

flowerp schreef op donderdag 30 december 2010 @ 00:27:
[...]
We zijn een semi-wetenschappelijk instelling die software schrijft voor (wetenschappelijke) experimenten en recent ook surveys.

Wees blij dat je dit soort problemen voor de kiezen krijgt. Grote datasets verwerken is imho vaak een stuk leuker dan de 1000e webapp (daarom ben ik ook blij dat ik bij mijn huidige werkgever zit).

quote:

De hardware klinkt misschien wel heftig, maar we doen eigenlijk voornamelijk zelfbouw en de kosten zijn helemaal niet zo gek. Grofweg wat je krijgt door gewoon de stuksprijzen vanuit de pricewatch te pakken

Mijn ervaring is dat bedrijven het liefst tonnen uitgeven aan veel te dure IBM/Oracle hardware/software en het liefst nog meer tonnen uitgeeft aan extra development tijd. Ik heb tot zover geen bedrijven gezien waar vanuit development de hardware is aanbevolen.

quote:

flowerp schreef op donderdag 30 december 2010 @ 00:01:
En hoe maak je dan de app performance beter met dezelfde CPU?

Meer cores gebruiken, minder blocking (IO) gebruiken.

quote:

Olaf van der Spek schreef op donderdag 30 december 2010 @ 00:37:
[...]
Meer cores gebruiken, minder blocking (IO) gebruiken.

Een van de dingen waar ik me de laatste tijd op focus is het verlagen van druk op de geheugen bus. Dus zorgen dat je data in een slag in de cache kan krijgen (een drama in Java omdat je weinig invloed uit kunt oefenen hoe objecten in het geheugen komen te staan en je geen cache friendly object arrays kan maken.. de objecten zweven tenslotte in java in de heap rond en zijn niet direct gemapt op een array..alleen de pointer). Een ander probleem is het aantal dure geheugen bus operaties zoals een volatile write of een cas.

Het is jammer dat de meeste tooling (vooral in Java land) je daar totaal in je naakie laten staan. Alleen Intel VTune 9 (XE heeft geen Java support meer) kan je de performance monitoren in je cpu combineren met de bytecode en op machine assembly/bytecode niveau kunt zien wat er aan de hand is. Het combineren van Java source met de gegenereerde assembly binnen een enkele view is echt prachtig (meteen een goeie reden om hiervan de kennis maar eens uit te gaan diepen).

In dat opzicht heb je in Java nog een laag om je door heen te worstelen als je (echt) wilt tunen.

dit boek is trouwens ook een aanrader voor iedereen die meer wil weten wat er 'under the hood' zich allemaal afspeeld:
Multicore Application Programming

Alarmnummer wijzigde dit bericht 30-12-2010 01:04 (14%)

quote:

Alarmnummer schreef op donderdag 30 december 2010 @ 00:44:
Ik heb tot zover geen bedrijven gezien waar vanuit development de hardware is aanbevolen.

Haha, goede. Ga ik eens wat mensen voor de kiezen gooien als ze weer eens lopen te klagen

quote:

(een drama in Java omdat je weinig invloed uit kunt oefenen hoe objecten in het geheugen komen te staan en je geen cache friendly object arrays kan maken.. de objecten zweven tenslotte in java in de heap rond en zijn niet direct gemapt op een array..alleen de pointer).

Eigenlijk heeft Java stiekum wel zoiets in de vorm van Java-RT. Dan heb je dingen als immortal memory, memory die je kunt mappen op registers, scoped memory etc. Zie http://java.sun.com/devel...icles/Programming/rt_pt1/

Jammer misschien dat dit niet beschikbaar is gekomen in 'gewoon' Java.

quote:

Alarmnummer schreef op donderdag 30 december 2010 @ 00:13:
[...]

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.

Dat gevaar lijkt me nog veel groter wanneer iemand zonder voldoende kennis een framework binnen z'n eigen bedrijf maakt en laat gebruiken.

quote:

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).

Dat dus

quote:

flowerp schreef op dinsdag 28 december 2010 @ 22:44:
[...]


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)

Om maar weer eens met de ~half jaarlijkse update te komen. MyCom doet nu het volgende:
code:

Aantal cores
1x  0
2x 16
3x  2
4x 16
6x  6
(totaal 40 cpus)

Gemiddelde is nu 3.45, weer een marginale stijging t.o.v. de vorige meeting. MyCom's filtering blijft wel CPUs missen. Dit keer 9 (totaal overzicht zegt er 49 te hebben).

Nieuwe is een overzicht van hardware threads, maar deze is helaas nog te onnauwkeurig om mee te nemen:
code:

Aantal threads
1x   0
2x   1
4x   5
8x   3
12x 2

Ook de support medewerker van MyCom had geen idee waar deze getallen op sloegen. Hopelijk wordt dit in de toekomst beter.

Opvallend is deze keer dat er geen enkele single core meer in het assortiment zit. Quad cores beginnen steeds meer normaal te worden in zelfs de allergoedkoopste desktop PCs. De Athlon II X4 vindt je al in complete systemen van 399,- de oude Core2 Quad vanaf zo'n 479,- en de i5 die in de huidige Sandy Bridge generation bijna allemaal Quad zijn in systemen vanaf zo'n 500,-.

Hex cores zijn nu los te krijgen voor prijzen die niet zo gek lang geleden nog vrij laag waren voor single cores. AMD's X6 1090 is er al voor zo'n 150,- terwijl Intel's i7-970 vanaf zo'n 470,- van de hand gaat. Prijzen waarvoor de echte liefhebbers het niet hoeven te laten.

Tevens is er in het smartphone en tablet segment een sterke migratie naar dual core aan de gang op dit moment, zodat ook hier de single core langzaam verdwijnt.

Toch blijft in de consumenten markt de zin uit de openings post: "Zitten we momenteel op 2 a 4 cores" na een goede 4.5 jaar (een eeuwigheid in de computer branch) nog steeds grotendeels actueel. 6 cores is weliswaar betaalbaar, maar op dit moment toch nog relatief zeldzaam. De grote revolutie van het snel toenemen van het aantal cores hebben we nog steeds niet gezien.

Voor wat meer technisch georiënteerd materiaal: hier een leuke link die laat zien hoe het gebruik maken van steeds meer higher level parallisatie technieken de code niet alleen makkelijker maakt, maar ook beter schaalbaar:

http://www.deftitlenil.com/2011/04/blog-post_05.html

Tevens zal over ongeveer 2 maanden JDK 7 eindelijk uitkomen, waarmee een fork/join framework standaard beschikbaar komt in de base library van 1 van de meest gebruikte programmeer talen. Mogelijk dat de nieuwe generatie programmeurs die hier mee opgroeit high level parallellisme als meer natuurlijk zal gaan beschouwen.

Als java-programmeur kan je waarschijnlijk beter Scala kiezen voor high-level parallellisme. Daar heb ik laatst een presentatie over gezien, en dat ziet er erg mooi uit 100% compatible met de rest van de java-wereld, dus je kan makkelijk die ene performance-bottleneck in Scala schrijven en de rest in Java, mocht je dat willen.

Vergeet Typesafe niet. Scala + Akka + Tools. Let vooral ook even op Company / Team. Daar komen wel wat bekende namen terug zoals James Gosling, maar ook Peter Veentjer.

Ja, die zijn lekker aan het promoten. En terecht

quote:

flowerp schreef op zaterdag 28 mei 2011 @ 15:26:
[...]
code:

Aantal cores
1x  0
2x 16
3x  2
4x 16
6x  6
(totaal 40 cpus)

De half jaarlijkse update is iets uitgelopen, maar MyCom doet op dit moment het volgende:
code:

Aantal cores
1x  0
2x  7
3x  1
4x 16
6x  3
8x  2
(totaal 30 cpus)

Gemiddelde is nu 3.8, weer slechts een marginale stijging t.o.v. de vorige meeting. MyCom's filtering is voor de eerste keer wel correct. Totaal overzicht en bij elkaar opgetelde CPU's zijn allebei 30.

Er zit nog steeds geen echte vaart in het opschalen van de cores. De dual core die meer dan 5 jaar geleden al helemaal ingeburgerd was blijft nog steeds een zeer sterke positie innemen. Ter vergelijking, 5 jaar vanaf het moment dat 10Mhz een gebruikelijke CPU snelheid was, zat geen enkele in de winkel verkrijgbare CPU meer op die snelheid.

Wel zien we nu eindelijk een oct core in het overzicht, maar dit is wel een AMD oct core. AMD gebruikt voor cores in haar laatste architectuur iets dat tussen SMP en een 'echte' core inzit.

Als je naar de roadmap kijkt van de CPU fabrikanten (met name Intel, maar Oracle is ook interessant hier) dan lijkt het alsof de multi-core revolutie alweer beëindigd is voordat deze goed en wel begonnen was.

De nieuwe ivy bridge serie van Intel zal zich voornamelijk weer gaan focusses op dual en quad cores (zie Wikipedia: Ivy Bridge (microarchitecture)), wat betekend dat we dus weer terug bij af zijn. Vooralsnog geen hex cores, geen oct cores en al helemaal geen hexadeci cores, waar we volgens voorspellingen van 5 jaar terug al makkelijk op hadden kunnen zitten.

Ook de volgende Intel architectuur (2013), zal zich gaan richten op dual cores t/m hex cores voor de consumenten versies, en dan wel eindelijk een 10 core versie (en ik neem aan ook wel oct core) voor server gebruik:

quote:

Up to 2~6 cores available in consumer market and 10 core in server version.

Zie: Wikipedia: Haswell (microarchitecture)

Ter afsluiting, aardig artikel over deze materie: http://www.extremetech.co...-and-why-were-still-stuck

flowerp wijzigde dit bericht 05-02-2012 14:17 (10%)

Stomme vraag misschien, maar hoeveel mensen ken jij die de afgelopen 2-3 jaar een nieuwe PC hebben gekocht? Ik ken zat mensen die een nieuwe smart-phone, laptop of tablet hebben gekocht, maar ik heb 1 collega die een mid-range PC heeft gekocht, verder niemand. Lokale CPU-kracht is steeds minder relevant aan het worden, vanwege cloud-computing. Misschien is dat ook wel een reden dat het voor Intel en AMD weinig zin heeft om te investeren in de ontwikkeling van 8-core consumentenprocessors.

quote:

flowerp schreef op zondag 05 februari 2012 @ 14:06:
Wel zien we nu eindelijk een oct core in het overzicht, maar dit is wel een AMD oct core. AMD gebruikt voor cores in haar laatste architectuur iets dat tussen SMP en een 'echte' core inzit.

Waarom zou je SMP niet meetellen dan? Tenminste, daar ga ik vanuit, want een quadcore i7 heeft gewoon 8 hardware threads, en een 6-core heeft 12 threads. Het is geen P4 hyperthreading waar je beter geen gebruik van kan maken. In ons multicore systeem starten we voor iedere logische thread een jobthread, en voor een i7 zijn ze allemaal nuttig.

quote:

.oisyn schreef op maandag 06 februari 2012 @ 10:36:
[...]

Waarom zou je SMP niet meetellen dan? Tenminste, daar ga ik vanuit, want een quadcore i7 heeft gewoon 8 hardware threads, en een 6-core heeft 12 threads. Het is geen P4 hyperthreading waar je beter geen gebruik van kan maken.

Goed punt. Ja, ik heb hier telkens alleen fysieke cores getelt. Je hebt gelijk dat met SMP erbij de multi-core ontwikkeling dus harder is gegaan dan eigenlijk geschetst.

De opmerking was meer bedoeld in de geest dat bij de Intel cores niet SMP werd meegeteld, terwijl dat bij de AMD cores dus eigenlijk wel zo is, maar ook weer niet. Dat is het 'lastige' van de AMD cores. Het is geen equivalent van SMP, maar een echte volledige core is het ook net niet.

Het is hier precies nog niet aan bod gekomen, maar Haswell krijgt ondersteuning voor Transactional Memory.

- HLE - Hardware Lock Elision is een backwards compatible prefix die op een lock/unlock gedaan kan worden.
Hierbij start de processor automatisch een transactie.
- RTM - Restricted Transactional Memory: nieuwe instructies die een transactie beginnen (XBEGIN), committen of aborten (XEND) en aborten (XABORT)

Zie ook http://arstechnica.com/bu...am-with-intel-haswell.ars

quote:

MBV schreef op zondag 05 februari 2012 @ 22:49:
Lokale CPU-kracht is steeds minder relevant aan het worden, vanwege cloud-computing.

Vanwege cloud-computing? Hoe bedoel je?
Volgens mij is het vanwege het feit dat internet browsers en office suites nog prima werken op computers die 5 jaar oud zijn.

Inderdaad, internet browsers en office suites werken prima op een computer van 5 jaar oud. Maar vroeger wilden mensen meer dingen draaien op hun PC (of datgene wat ze in hun handen hadden) dan allen een browser. Dankzij cloud-computing, en steeds meer applicaties die naar het web verhuizen wordt al het andere minder relevant.

Zoals wat? Wat voor veel gebruikte en zware apps draaien nu in de cloud en draaiden vroeger lokaal?

[topicchange]

Zeg, zijn er hier ook mensen die ervaring hebben met actor-based concurrency / actors? Ik had er zelf tot een half jaar geleden nog niet eens van gehoord, maar toen kwam ik voor een project (en via collega's) ermee in aanraking, en ik vind het zeker een interresante manier om concurrency werkend te krijgen.

Het is natuurlijk even anders denken over hoe je je programma structureert. Het heeft natuurlijk wel enig raakvlak met OOP, maar het is ook weer anders. Zelf heb ik er nog moeite mee om mijn server - die overigens in productie zit en naar behoren werkt - ook echt 'idiomatisch' actor-based te maken. Maar toegegeven, ook al is het Scala, d'r zitten ook nog genoeg 'java-ismes' in. Oude gewoontes zijn moeilijk af te leren, zeker als je naar een volledig ander paradigma overgaat (hybride oo/functioneel programeren, actor-based concurrency etc).

Ik zie er echter zeker wel toekomst in. Het is gewoon redelijk makkelijk om goeie multithreaded performance te halen - alle 'boilerplate' zoals locking en zelfs de keuze om een concurrent collectie of een gewone te gebruiken wordt gewoon weggeabstraheerd. Binnen je actors hoef je je helemaal geen zorgen te maken om concurrent access, d'r is toch telkens maar één bericht dat tegelijkertijd afgehandeld wordt.

Ik ben natuurlijk wel nieuwsgiering naar hoe ver we de server zoals hij nu is door kunnen schalen. Het daadwerkelijke gebruik is slechts een 30e van waar we op gerekend / getest hebben, en het testen was op een oudere versie en waarschijnlijk niet eens representatief (aangezien alle request vanuit één client kwamen).

tl;dr, ik zal nog eens vragen @ werk of ik er een blogpost aan mag wijden. Ook staat er op SO een vraag open over het juist structureren van een actor-based webservice (zal ik morgen weer naar kijken)

quote:

MBV schreef op zondag 29 mei 2011 @ 23:53:
Als java-programmeur kan je waarschijnlijk beter Scala kiezen voor high-level parallellisme. Daar heb ik laatst een presentatie over gezien, en dat ziet er erg mooi uit 100% compatible met de rest van de java-wereld, dus je kan makkelijk die ene performance-bottleneck in Scala schrijven en de rest in Java, mocht je dat willen.

Beetje laat, maar heb je die presentatie / link nog ergens?

quote:

YopY schreef op zondag 12 februari 2012 @ 10:40:
[topicchange]

Zeg, zijn er hier ook mensen die ervaring hebben met actor-based concurrency / actors?

actors lijken mij de extreme variant van active objects en message passing.

Wij werken in onze embedded software al jaren met modules die een eigen thread + queue hebben. Alles is eigenlijk event-driven. Je mag rekenen dat onze meest complexe applicaties in de orde van 30-60 threads hebben. Tot voor dit jaar was alles single-core, sinds dit jaar hebben we ook 2/6-core voor enkele applicaties.

Zoals je zegt: binnen 1 module werk je eigenlijk compleet single-threaded. Voor cross-module communicatie zend je dan messages (asynchroon of synchroon). Niet alle problemen zijn daarmee trouwens opgelost. Je kan bij onzorgvuldige code nog wel deadlocks krijgen, maar dat is meer uitzondering dan regel.

Dit model is trouwens niet heiligmakend als je multi-core optimaal wil benutten. Tenzij je workload toelaat om te partitioneren of een fijne grain size voor actors te hebben, krijg je enkele modules waar veel werk gedaan wordt en enkele waar sporadisch iets gebeurt. Die grotere modules opsplitsen is niet altijd triviaal/mogelijk en dan wordt het wel moeilijk om te gaan schalen naar meer CPUs tenzij je weer locking en andere invoert of enkele drastische beslissing neemt met grote impact + veel werkuren als gevolg.

quote:

Hydra schreef op zondag 12 februari 2012 @ 11:29:
[...]


Beetje laat, maar heb je die presentatie / link nog ergens?

http://www.sioux.eu/en/scala-hot-or-not.html

quote:

MBV schreef op maandag 13 februari 2012 @ 10:49:
http://www.sioux.eu/en/scala-hot-or-not.html

Thanks