[alg] Gebruik maken van multiple cores

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

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