[alg] Gebruik maken van multiple cores

[flowerp]

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

[Alarmnummer]

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

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.

[Olaf van der Spek]

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.

[Alarmnummer]

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

[ Voor 14% gewijzigd door Alarmnummer op 30-12-2010 01:04 ]

[flowerp]

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

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

[MBV]

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.

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

[flowerp]

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.

[MBV]

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.

[Janoz]

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.

[MBV]

Ja, die zijn lekker aan het promoten. En terecht

[flowerp]

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:

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

[ Voor 10% gewijzigd door flowerp op 05-02-2012 14:17 ]

[MBV]

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.

[.oisyn]

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.

[flowerp]

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

[H!GHGuY]

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

[Olaf van der Spek]

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.

[MBV]

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.

[Olaf van der Spek]

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

[YopY]

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

[Hydra]

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?

[H!GHGuY]

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.

[MBV]

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

[Hydra]

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

Thanks

[Confusion]

I'm ranting against [those] who continue to talk about how software must be more highly threaded, and how multi-core is the inevitable future.

[..] It's not the inevitable future at all. Software programmers should not think that they have to write multi-threaded programs. It's too hard, and the payoff is too little. And it absolutely isn't where the industry is even going.

-- Linus Torvalds, mei 2009

[.oisyn]

Ach ja, ik ben lang geleden opgehouden die gast serieus te nemen. Degene die erop reageert laat dat ook mooi zien.
Wat is dat trouwens voor vaag forum? Hij laat de volledige posts niet zien. Is het een nieuwsgroep aggregate oid?

[ Voor 64% gewijzigd door .oisyn op 09-07-2012 23:06 ]

[Olaf van der Spek]

Je bedoelt volledige thread?
Hier ziet eruit als het archief van een mailing list.

[.oisyn]

Nee individuele posts zijn afgekapt.

[Kajel]

.oisyn schreef op maandag 09 juli 2012 @ 22:41:
Ach ja, ik ben lang geleden opgehouden die gast serieus te nemen. Degene die erop reageert laat dat ook mooi zien.

Linus heeft 2 dingen bedacht, die me nauw aan het hart staan: Linux en vooral Git. Desalniettemin neem ik hem tegenwoordig ook nauwelijks serieus meer. Als je in die thread kijkt naar het aantal keer dat hij iemand "Moron" noemt, kan ik alleen maar denken "Ach gossie, je krijgt je gelijk niet? Autistje"

[Voutloos]

The first one to get angry loses the fucking argument.

[RobIII]

quote: http://www.drdobbs.com/pa...ver-be-embraced/240003926

Will Parallel Code Ever Be Embraced? @DrDobb's
[...]
Each system will become a collection of smaller systems, rather like a blade server, except made up of tiny machines that sip power and deliver exactly what I need — all using separate processors and with separate process spaces, so no one system interferes with the performance of any other. Life is good. I'll be gobbling up cores like popcorn and still not writing parallel code. Why? Because instead of scaling up (more threads in one process), I've scaled out (more processes).

[Kajel]

Ik geloof zelf ook wel dat het die kant opgaat. Ik ben nu voor mijn afstudeeronderzoek bezig met MapReduce/Hadoop, en daar wordt "het probleem" gewoon opgelost door inderdaad meerdere processen op verschillende fysieke hardware nodes in te zetten. Commodity hardware is tegenwoordig zo goedkoop, dat dit voor elk bedrijf dat de behoefte heeft (veel data en/of cpu-intensieve processen) betaalbaar is.

In feite ben je overigens nog steeds parallel aan het programmeren, met als grote verschil dat het framework (Hadoop) heel veel low-level zaken (IO, Netwerkcommunicatie, gedistribueerd filesysteem) voor je wegabstraheert. Door je probleem gewoon om te zetten in het "MapReduce formaat", heb je in weinig tijd, en met weinig moeite de uitkomst van je probleem versneld.

[YopY]

Voor dataverwerking en bijv. webhosting is "scale out" idd de toekomst, maar multicores - en multicore programmeren - blijven gewoon relevant voor apparaten; PC's, consoles, tegenwoordig ook mobiele telefoons, etc.

Actor-based programmeren is zeer goed te vergelijken met een Hadoop-achtig systeem; je communiceert via berichten met actors die vergelijkbaar zijn met losstaande systemen die een taak uitvoeren, en je een bericht terug sturen - of een bericht doorsturen naar een andere actor - als ze daarmee klaar zijn, en die actors kunnen natuurlijk op externe systemen staan. Korte rant, maar als concurrency op de klassieke manier te complex is (locks, synchronizatie, etc), kijk dan naar actor-based concurrency, da's een stuk eenvoudiger te begrijpen imho.

[RayNbow]

Euh... Actor-based concurrency vs map-reduce parallelism?

[MBV]

't groeit een beetje naar elkaar, zo te zien

Kost dat actor-based programmeren niet veel overhead, waardoor je uiteindelijk voor een klein beetje winst in reactiesnelheid veel extra resources nodig hebt? Eigenlijk het standaard-probleem bij multi-threaded programmeren op een interactief systeem

[RayNbow]

MBV schreef op donderdag 19 juli 2012 @ 23:10:
't groeit een beetje naar elkaar, zo te zien

Het hangt natuurlijk af van je definities, maar ik beschouw zelf concurrency en parallelism als twee concepten die los van elkaar kunnen staan.

Kost dat actor-based programmeren niet veel overhead, waardoor je uiteindelijk voor een klein beetje winst in reactiesnelheid veel extra resources nodig hebt?

Performance lijkt me niet het primaire doel van actor-based programmeren. Het primaire doel is om het schrijven van correcte programma met concurrency gemakkelijker te maken.

In de woorden van Joe Armstrong (ontwikkelaar van Erlang):

quote: http://osdir.com/ml/lang....ral/2003-04/msg00350.html

[...]

The reaction is varied - everything from (rarely) "you're absolutely right" to - (more commonly) "what about efficiency"

Me, I can make an incorrect program run arbitrarily quickly - that is no challenge, the following program, for example, computes factorial(10000000000) in less than a picotwinkle.

factorial(N) -> 42.

/Joe

[MBV]

Maar waarom wil je een correct programma met concurrency schrijven? Als je met minder moeite een single-threaded programma kan schrijven met dezelfde response-time als een actor-based programma dat op 3 cores draait, is het hele punt een beetje weg natuurlijk. Je gaat je zorgen maken over meerdere cores om een betere performance te halen, toch? Dat is zo'n beetje het doel ervan.
Dat je met functionele programmeertalen makkelijker correcte programma's kan schrijven dan met imperatieve programmeertalen ten koste van een klein beetje performance* weet ik, en ben ik ook voorstander van.

_{*) Ten opzichte van de ideale implementatie in een imperatieve programmeertaal natuurlijk, ik weet dat automatische optimalisaties soms beter zijn dan degene die de programmeur verzint.}

[RayNbow]

MBV schreef op vrijdag 20 juli 2012 @ 11:11:
Maar waarom wil je een correct programma met concurrency schrijven? Als je met minder moeite een single-threaded programma kan schrijven met dezelfde response-time als een actor-based programma dat op 3 cores draait, is het hele punt een beetje weg natuurlijk. Je gaat je zorgen maken over meerdere cores om een betere performance te halen, toch? Dat is zo'n beetje het doel ervan.

Als de eigenschappen van een single-threaded programma voldoen, dan geniet dat natuurlijk de voorkeur.

Het probleem is dat mijn oorspronkelijke zin een beetje ambigu is.

Wat ik wilde zeggen is het volgende. Er zijn programma's die baat hebben bij concurrency (en niet per se om rauwe performance redenen). Het actor model helpt om zulk soort programma's op een correcte manier te implementeren, maar het actor model is niet de enige manier om concurrency te bewerkstelligen.

[flowerp]

flowerp schreef op zondag 05 februari 2012 @ 14:06:
[...]

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.

Laatste keer was meer dan 2 jaar geleden, een eeuwigheid in IT land. Is er veel veranderd?

MyCom doet nu het volgende:

code:

Aantal cores
1x  0
2x  7
3x  0
4x 22
6x  3
8x  4
(totaal 36 cpus)

Gemiddelde is nu 4.2. Er zit dus wel een zekere stijging in, maar het is nog steeds erg gering. Eigenlijk kunnen we wel stellen dat jaar, na jaar, na jaar het aantal beschikbare cores voor de typische consument eigenlijk niet veranderd. Het zijn 4 cores voor de gewone PC, 2 cores voor de erg budget bewuste consument en diverse laptops.

Net zoals 2 jaar geleden heeft Intel nog steeds geen consumenten oct core uit. Omdat AMD in het high performance segment steeds minder meespeelt en Intel per core toch meer performance biedt, is het ook interessant om nog even naar de Intel only lijst te kijken:

code:

Aantal cores
1x  0
2x  6
3x  0
4x 14
6x  1
8x  0
(totaal 21 cpus)

Nu is het gemiddelde slechts 3.5 wat nog duidelijker aangeeft dat de multi-core revolutie die er bij de topic start uit 2006(!) leek aan te komen er niet is gekomen. Na een kleine 8 jaar is er qua cores eigenlijk weinig veranderd.

Wat er wel veranderd is is dat de clock voor quad cores omhoog is gegaan naar de clock die je destijds alleen voor single cores had; namelijk 3 t/m 3.7Ghz. De enkele hex core gaat overigens tot 3.4Ghz wat een verbetering is t.o.v. de hex cores van een poosje geleden die niet boven de 3Gh uitkwamen.

[BikkelZ]

Ik geloof dat mensen vanaf Core 2 Duo eigenlijk wel zoiets hadden van mijn PC is snel genoeg en wellicht dat de C2D's langzaam vervangen gaan worden nu maar mensen met wat voor i5 dan ook peinzen er niet over. Vroeger gingen mensen van een PII 350 naar een PIII 450* en je wil niet weten wat die dingen destijds kostten. Maar het maakte wel een voelbaar verschil. Maar eigenlijk is het PC meer zijn energiezuinigheid en memory bandwidth problemen aan het oplossen. De processors waren dermate snel en heet geworden dat ze vooral aan het wachten waren op input en iedere simpele laptop al constant het geluid van een föhn maakte.


OK wij zaten op een dual Celly 300A @ 450

[ Voor 5% gewijzigd door BikkelZ op 30-04-2014 04:52 ]

[MBV]

@flowerp: je vergeet dat AMD een zeer krachtige processor met 128 cores aan boord heeft. Over multicore gesproken!

[HMS]

Vergeet ook niet dat er erg veel verbeteringen zijn geweest in instructies per clock tik. 1 clocktik op een nieuwe i7 'is sneller' dan 1 clocktik op een C2D.

[flowerp]

MBV schreef op woensdag 30 april 2014 @ 10:03:
@flowerp: je vergeet dat AMD een zeer krachtige processor met 128 cores aan boord heeft. Over multicore gesproken!

Tsja, er komt ook binnenkort de POWER8 met 96 hardware threads die je ook nog in een 4 x board kunt kopen zodat je 384 hardware threads hebt.

Op server niveau en voor specialistische toepassingen (waaronder ook GPUs en ASICs) zijn er dus wel wat uitgebreidere mogelijkheden, maar waar het in dit topic vooral om gaat is dat de multicore revolutie er voor de gewone desktop komt. De stelling was namelijk ooit dat programmeurs pas *echt* over meerdere cores gaan nadenken als hun simpele workstation die ook heeft.

Nu is de "totale clock" (denkbeeldige clock snelheid van alle cores bij elkaar opgeteld) wel omhooggegaan, maar aantal cores zit dus al een decennia op 4, en kijkende naar de roadmaps zijn er ook niet echt aanwijzingen dat dit op korte termijn nog gaat veranderen. Sterker nog, er zijn eigenlijk geen echte aanwijzingen nu dat het voor de consument ooit gaat veranderen.

Net zoals de 4Ghz hurdle eigenlijk wel de absolute max is voor de gewone desktop PC, lijkt 4 "gewone" cores en met een beetje uitzondering 6 toch ook wel een soort maximum te zijn.

HMS schreef op woensdag 30 april 2014 @ 10:05:
Vergeet ook niet dat er erg veel verbeteringen zijn geweest in instructies per clock tik. 1 clocktik op een nieuwe i7 'is sneller' dan 1 clocktik op een C2D.

IPC is lastig. De efficiëntie ervan is iets toegenomen, maar percentueel best marginaal en deze wordt ook alleen gehaald met de juiste toevallige instructie mix.

Het verhaal over het power verbruik dat afgenomen is en de memory bandwidth die eerst moet toenemen is opzich wel logisch, maar dat betekent dus dat de toen voorspelde multicore revolutie inderdaad nog wel een flink poosje op zich kan laten wachten.

[PrisonerOfPain]

flowerp schreef op woensdag 30 april 2014 @ 22:58:
Nu is de "totale clock" (denkbeeldige clock snelheid van alle cores bij elkaar opgeteld) wel omhooggegaan, maar aantal cores zit dus al een decennia op 4, en kijkende naar de roadmaps zijn er ook niet echt aanwijzingen dat dit op korte termijn nog gaat veranderen. Sterker nog, er zijn eigenlijk geen echte aanwijzingen nu dat het voor de consument ooit gaat veranderen.

Vergeet niet dat de nieuwe consoles 8 cores hebben (2x4) wat wellicht de progressie zou kunnen drijven.

[MBV]

flowerp schreef op woensdag 30 april 2014 @ 22:58:
[...]

Op server niveau en voor specialistische toepassingen (waaronder ook GPUs en ASICs) zijn er dus wel wat uitgebreidere mogelijkheden, maar waar het in dit topic vooral om gaat is dat de multicore revolutie er voor de gewone desktop komt. De stelling was namelijk ooit dat programmeurs pas *echt* over meerdere cores gaan nadenken als hun simpele workstation die ook heeft.

GPGPU wordt (zoals de naam aangeeft) steeds minder specialistisch. Voor taken waarvoor de CPU intensief belast wordt is het zeker interessant om hiernaar te kijken, aangezien vrijwel elke nieuwe PC een krachtige GPU aan boord heeft die makkelijk voor general purpose is in te zetten. Ook zijn de ontwikkelingen gericht op steeds makkelijker aansturen vanuit de CPU, waarbij je minder snel tegen performance bottlenecks als transactiesnelheid aanloopt.

[ Voor 9% gewijzigd door MBV op 01-05-2014 13:16 ]

[flowerp]

MBV schreef op donderdag 01 mei 2014 @ 13:15:
[...]

GPGPU wordt (zoals de naam aangeeft) steeds minder specialistisch. Voor taken waarvoor de CPU intensief belast wordt is het zeker interessant om hiernaar te kijken, aangezien vrijwel elke nieuwe PC een krachtige GPU aan boord heeft die makkelijk voor general purpose is in te zetten. Ook zijn de ontwikkelingen gericht op steeds makkelijker aansturen vanuit de CPU, waarbij je minder snel tegen performance bottlenecks als transactiesnelheid aanloopt.

Klopt ja, en dit is ook zeker een parallelle ontwikkeling (no pun intended ), zeker als je bedenkt dat er diverse CPUs zijn waar een GPU in embedded zit. Dat zijn feitelijk ook extra cores, alleen een ander soort cores.

Hoewel ze minder specialistisch worden, blijft het toch wel een apart ding. Je runt er niet zomaar even je standaard Java, C# of Objective-C code op, maar in al deze talen en/of omgevingen waar deze talen vaak draaien komt er wel degelijk steeds meer (standaard) support voor.

PrisonerOfPain schreef op donderdag 01 mei 2014 @ 12:47:
[...]
Vergeet niet dat de nieuwe consoles 8 cores hebben (2x4) wat wellicht de progressie zou kunnen drijven.

Het zal zeker bijdragen ja. Het zijn dan wel AMD cores, wat iets is wat tussen SMT en een core zit, maar het geeft toch wel een zekere denk richting aan. Op een console MOET je eigenlijk wel alles gebruiken wat er in zit en kun je ook precies uitgaan van dat dat er exact in zit. Wel is het zo dat relatief weinig programmeurs voor consoles programmeren.

[ Voor 21% gewijzigd door flowerp op 01-05-2014 21:17 ]

[PrisonerOfPain]

flowerp schreef op donderdag 01 mei 2014 @ 21:14:
Wel is het zo dat relatief weinig programmeurs voor consoles programmeren.

Daar staat dan weer tegenover dat het wel producten zijn die op miljoenen PCs verschijnen.

Verder is Compute/GPGPU natuurlijk al massively parallel. Je hebt dan wel cores die niet veel meer zijn als 4 scalar units, maar je hebt er wel duizenden van en dat levert een enorm andere programmeer wijze op. Een simpele memset operatie is ipv een for loop bijvoorbeeld een gigantisch aantal threads dat word opgestart die allemaal een simpele operatie doen:

code:

dest[i] = value;

[ Voor 15% gewijzigd door PrisonerOfPain op 01-05-2014 21:59 ]

[djc]

flowerp schreef op donderdag 01 mei 2014 @ 21:14:
Hoewel ze minder specialistisch worden, blijft het toch wel een apart ding. Je runt er niet zomaar even je standaard Java, C# of Objective-C code op, maar in al deze talen en/of omgevingen waar deze talen vaak draaien komt er wel degelijk steeds meer (standaard) support voor.

Ik denk dat moderne talen zoals Go of Rust het ook al heel wat makkelijker kunnen maken om meerdere cores goed te benutten, door de CSP-gebaseerde concurrency-features.

[MBV]

Er zijn veel moderne talen die concurrency makkelijker maken, maar dat zijn vaak niet de talen waarmee je kan interfacen met GPGPU. Hoewel dat nadeel steeds minder groot wordt, is het nog steeds erg makkelijk om je performance om zeep te helpen door te vaak synchronisaties te forceren met de CPU. Collega van me had laatst een kleinigheidje veranderd waardoor de framerate van 40 naar 400fps ging... Om te zorgen dat je dat soort problemen kunt voorkomen wordt GPU-programmeren nog vaak in low-level talen als C++ gedaan.

_{Ook al is het bij 'slordig' programmeren vaak beter voor de performance om Java o.i.d. te gebruiken.}