[alg] Gebruik maken van multiple cores

[vleppyniles]

Een maat van me vertelde nl dat programma's altijd specifiek geschreven zijn voor een vast aantal cores. Zo zou een programma dus wel met 2 cores om kunnen gaan maar nooit met 4 omdat het er niet voor geschreven is.

Maar als ik het goed begrijp kunnen programma's zelf kijken hoeveel cores je in je systeem hebt en aan de hand daarvan bepalen of ze 1,2 of 4 cores kunnen gebruiken. Of zit ik er naast?

[.oisyn]

vleppyniles schreef op woensdag 03 januari 2007 @ 13:29:
Een maat van me vertelde nl dat programma's altijd specifiek geschreven zijn voor een vast aantal cores.

Da's onzin, en dan doel ik natuurlijk op het woordje "altijd". 't Is maar net hoe je je programma ontwerpt. Je kunt een applicatie idd schrijven voor een specifiek aantal cores, maar je kunt net zo goed het aantal cores opvragen en een taak of taken vervolgens over zoveel cores verdelen. Of je gebruikt een API die dat transparant voor je oplost.

[vleppyniles]

Oke, dank je wel voor je uitleg.

[Juup]

Misschien is het een uitkomst als de ontwikkelaars van programmeertalen zaken toevoegen die het eenvoudiger maken om multithreaded te werken. Ik kan met best voorstellen dat je een variabele maakt die in elke thread gelezen en geschreven mag worden. Tijdens het schrijven kan een andere thread dan alleen een oude copie lezen.
Dit heeft dan een performance penalty maar je zou de compiler/interpreter zo slim kunnen maken dat die peformance penalty alleen geldt als meerdere threads ook daadwerkelijk iets met die var doen.

[.oisyn]

Je bedoelt zoals bijvoorbeeld OpenMP in C/C++?

[Juup]

.oisyn schreef op woensdag 03 januari 2007 @ 16:45:
Je bedoelt zoals bijvoorbeeld OpenMP in C/C++?

Hmmm da's een goed begin ja.
Nou zouden C en C++ natuurlijk bij wet verboden moeten worden... maar toch

[.oisyn]

* .oisyn slaps Jaaap around a bit with a large trout

[MBV]

waarom zou het dan niet verboden moeten worden? Zulk low-level programmeren levert toch alleen maar geheugenfouten op e.d.?

[.oisyn]

C++ hoeft niet low-level te zijn en ook geen geheugenfouten op te leveren. Het kan wel, maar daar kies je dan voor. Da's het mooie van C++. En in java/.Net kun je net zo goed leaken . En als je dan per se de best of both worlds wil, dan ga je voor C++/CLI

[ Voor 29% gewijzigd door .oisyn op 03-01-2007 18:02 ]

[flowerp]

.oisyn schreef op woensdag 03 januari 2007 @ 18:01:
En in java/.Net kun je net zo goed leaken .

Inderdaad, als full-time Java developper kan ik dat beamen. Nagenoeg alle GC implementaties (waaronder die van Java en .NET) bieden alleen bescherming tegen een bepaalde soort leak: namelijk die van een unreachable object. Er is geen enkele bescherming tegen de leaks van een 'ongebruikt' object.

Dat dit in Java wel degelijk speelt getuige het defineren van een bekend anti-pattern in Java (ee); "overstuffed session". Dit ontstaat als men in web applicaties van alles en nog wat in de zogenaamde session stopt (een soort hashmap gekoppeld aan de scope van een user). Als je alles maar daar in blijft stoppen en nooit objecten weghaald als een bepaalde 'conversatie' afgelopen is, dan heb je een memory leak waartegen een GC niet beschermt.

Een andere mogelijkheid is dat je binnen een syntactische scope (binnen {}) een groot object alloceerd of een groot aantal objecten en dan, als je eigenlijk al klaar bent, iets gaat doen wat lang duurt. Bv

Java:

if ( condition ) {

   Object foo = createLargeObject();
   
   // ... do something with foo

   // Long running operation
   sendMsgToRemoteServer("Operation done");
}

In bovenstaand geval gaat de GC foo niet opruimen totdat sendMsgToRemoteServer() returned. als dat lang duurt hou je dus ook lang het geheugen voor foo (onnodig) bezet. Gebeurt dit vaak tegelijk, dan vraag je app opeens veel meer geheugen dan eigenlijk noodzakelijk. Is dat meer dan je hebt, dan krijg je gewoon keihard OutOfMemoryExceptions. Wat Java programmeurs zouden moeten doen (maar zelden doen) is zoiets als:

Java:

if ( condition ) {

   Object foo = createLargeObject();
   
   // ... do something with foo

   foo = null; // done with foo, allow GC to collect foo

   // Long running operation
   sendMsgToRemoteServer("Operation done");
}

Nog een heel andere klasse van memory leaks in Java is gerelateerd aan class loaders. Als jij een Java applicatie hebt met een statische referentie naar een Object waarvan het type geladen wordt door een specificieke classloader, dan zal deze classloader niet 'unloaded' kunnen worden zolang de referentie naar een concreet Object instance wijst.

Dit is een bekend leak wat voornamelijk tot uiting komt in web applicaties. Elke web app onder een Application Server heeft z'n eigen class loader. Als je nu types in de web app zelf defineert en je hebt hier de genoemde statische referentie naar, dan zal bij het zogenaamde reloaden van de app (bv voor een nieuwe deploy), de oude class loader in het geheugen blijven staan. Doe je dit reloaden vaak genoeg dan loopt je geheugen vanzelf weer vol en moet je hard alles killen.

Als oplossing voor dit laatste probleem wordt bij het afsluiten van een web app een groot aantal "contextDestroyed" methods aangeroepen, waarin je als programmeur de mogelijkheid hebt om van alles op null te zetten. Alleen... bijna geen enkele programmeur doet dit natuurlijk.

Hmmm, beetje lange en off topic post geworden, maar even om aan te geven dat de niet oplettende programmeur in Java net zo goed leaks kan maken

[MBV]

.oisyn schreef op woensdag 03 januari 2007 @ 18:01:
C++ hoeft niet low-level te zijn en ook geen geheugenfouten op te leveren. Het kan wel, maar daar kies je dan voor. Da's het mooie van C++. En in java/.Net kun je net zo goed leaken . En als je dan per se de best of both worlds wil, dan ga je voor C++/CLI

En we hebben een happer! Enneh, waar had ik het over leaks? Ik had het over buffer overrun, 0-pointer, dat soort gedoe

En ik weet ook wel hoe je het in C++ moet omzeilen (smart pointers, frameworks met smart pointers, dat soort dingen) maar by default kan het makkelijk fout gaan

En dat Java kan lekken weet ik ook wel. En als het niet lekt, dan gaat het geheugengebruik vaak zo snel omhoog (bijv http://www.gentleware.com/) dat je er al snel niet meer mee kan werken
Ik weet het, het kan beter, zie Eclipse, maar veel java-proggers doen het fout.

[Olaf van der Spek]

flowerp schreef op woensdag 03 januari 2007 @ 21:12:
Wat Java programmeurs zouden moeten doen (maar zelden doen) is zoiets als:

Is de optimizer niet slim genoeg om te zien dat die objecten al dead zijn zodat de GC ze wel kan dealloceren?

MBV schreef op woensdag 03 januari 2007 @ 22:08:
En we hebben een happer! Enneh, waar had ik het over leaks? Ik had het over buffer overrun, 0-pointer, dat soort gedoe

Buffer overruns zijn vaak een gevolg van C-style code in plaats van C++-style code.

Dat je in C++ low-level kunt coden betekent niet dat je het ook moet doen.

[ Voor 40% gewijzigd door Olaf van der Spek op 03-01-2007 22:15 ]

[flowerp]

Olaf van der Spek schreef op woensdag 03 januari 2007 @ 22:09:
[...]
Is de optimizer niet slim genoeg om te zien dat die objecten al dead zijn zodat de GC ze wel kan dealloceren?

In bepaalde gevallen zou dit kunnen, dit is een toepassing van het veel besproken escape analysis. Samengevat moet de compiler (first of second stage) bewijzen dat het object in kwestie op geen enkele manier uit z'n scope kan ontsnappen. Voor de Sun VM geldt dat men dit jaren op de planning heeft gehad, maar keer op keer uitgesteld heeft. In de huidige JVM (versie 6) wordt het als ik me niet vergis inderdaad beperkt toegepast. In de volgende versie zou dit grootschaliger ingezet moeten gaan worden.

[.oisyn]

flowerp schreef op woensdag 03 januari 2007 @ 21:12:
Wat Java programmeurs zouden moeten doen (maar zelden doen) is zoiets als:

Java:

if ( condition ) {

   Object foo = createLargeObject();
   
   // ... do something with foo

   foo = null; // done with foo, allow GC to collect foo

   // Long running operation
   sendMsgToRemoteServer("Operation done");
}

Idd, of je past het veelgebruikte C++ idioom in Java toe, namelijk een extra scope introduceren:

C++:

if (condition)
{
    {
        Object foo = createLargeObject();
        // bla
    }

    // foo bestaat nu niet meer, de foo = null is dan ook niet nodig
   sendMsgToRemoteServer("Operation done");
}

In C++ is dit natuurlijk extra belangrijk omdat je een destructor hebt die soms moet runnen voor je verder gaat. Overigens is het in C++/CLI ook mogelijk destructors op managed classes los te laten met exact dezelfde code - daar is C++/CLI uniek in vergeleken met de overige .Net talen.

[MSalters]

Niet helemaal uniek hoor. IDisposable is gewoon de .NET interface voor destructors.

[chris]

Ik denk dat de huidige oplossingen voor threaded applicaties nog een stuk te ingewikkeld zijn. In principe wil je je als programmeur zo min mogelijk druk maken over threads, en nog minder over low-level dingen als locks. Simon Peyton Jones beschrijft in z'n paper Beatiful Concurrency hoe je dit kan aanpakken. Erg interessant leesvoer voor iedereen denk ik.

[.oisyn]

MSalters schreef op zondag 07 januari 2007 @ 23:06:
Niet helemaal uniek hoor. IDisposable is gewoon de .NET interface voor destructors.

using() is ruk, maar soit

[ Voor 3% gewijzigd door .oisyn op 14-01-2007 16:35 ]

[Verwijderd]

using() is ideaal! Wanneer je toch al niet zelf netjes je rommel op mag ruimen, maar 't vriendelijk aan de GC moet vragen, is using() een prima manier om die rommel zo snel mogelijk out of scope te krijgen. En dan maar hopen dat de GC 't ook snel genoeg doorheeft...

[.oisyn]

Verwijderd schreef op maandag 15 januari 2007 @ 23:03:
using() is ideaal!

using is helemaal niet ideaal, voor ieder object heb je een nieuwe nesting nodig, itt C++ destructors (waar het over ging). Het is idd beter dan niets (zoals in Java), maar ze hadden het imho wel wat handiger aan mogen pakken (C++/CLI kan het immers ook prima in .Net)

[Verwijderd]

Je hebt niet voor ieder object een nesting nodig, maar alle objecten die je binnen 1 using() gebruikt zijn daarna weer out of scope (en gaan dus t.z.t. opgeruimd worden). Binnen 1 using() kun je honderden of duizenden objecten feest laten vieren, en die worden allemaal vriendelijk verzocht het pand te verlaten wanneer de using() afloopt.

Maar als Delphi programmeur krijg ik ook de kriebels wanneer ik niet zelf netjes de boel kan free-en of clearen... 't is even wennen, net alsof je een gratis huishoudster krijgt!

[.oisyn]

Verwijderd schreef op dinsdag 16 januari 2007 @ 01:21:
Je hebt niet voor ieder object een nesting nodig, maar alle objecten die je binnen 1 using() gebruikt zijn daarna weer out of scope (en gaan dus t.z.t. opgeruimd worden). Binnen 1 using() kun je honderden of duizenden objecten feest laten vieren, en die worden allemaal vriendelijk verzocht het pand te verlaten wanneer de using() afloopt.

Vergelijk:

C++:

void foo()
{
    Resource1 resource1;
    // wat code
    Resource2 resource2;
    // nog wat code
    Resource3 resource3;
    // meer code
}

C#:

void foo()
{
    using (Resource1 resource1 = new Resource1())
    {
        // wat code
        using (Resource2 resource2 = new Resource2())
        {
            // nog wat code
            using (Resource3 resource3 = new Resource3())
            {
                // meer code
            }
        }
    }
}

Als je een betere oplossing weet, I'm all ears

[Flard]

.oisyn schreef op dinsdag 16 januari 2007 @ 01:35:
[...]


Vergelijk:

C++:

void foo()
{
    Resource1 resource1;
    // wat code
    Resource2 resource2;
    // nog wat code
    Resource3 resource3;
    // meer code
}

C#:

void foo()
{
    using (Resource1 resource1 = new Resource1())
    {
        // wat code
        using (Resource2 resource2 = new Resource2())
        {
            // nog wat code
            using (Resource3 resource3 = new Resource3())
            {
                // meer code
            }
        }
    }
}

Als je een betere oplossing weet, I'm all ears

Ik vind de vergelijking niet zo eerlijk...
In de C# variant geef je min of meer expliciet aan waar de resource weggegooid mag worden, terwijl in je C++ variant de resources allemaal impliciet op het einde worden weggegooid omdat ze out of scope zijn.

Dus, als je enkel op de plaatsen code zou hebben waar jij dat aangeeft, is de C# inderdaad erg omslachtig, en zou het op dezelfde manier als C++ geschreven kunnen worden... in beide gevallen gaan de resources dan bij het verlaten van de functie out of scope.

(mijn laatste regel C++ is alweer wat jaartjes geleden)...
Als je ze in C++ expliciet weg wilt gooien dan moet je destroyen en in principe het geheugen vrijgeven.
In C# kun je ook iets expliciet weggooien door het te disposen (als het IDisposable is), en eventueel de variabele (pointer/reference) de waarde null geven.

Maar goed, daarmee bevestig ik wel je punt dat using() inderdaad lang niet altijd een uitkomst is. Ik gebruik het dan ook amper. De enige gevallen waar ik het 'handig' vindt, is bij tekenen in .NET.

[.oisyn]

Flard schreef op dinsdag 16 januari 2007 @ 10:04:
Ik vind de vergelijking niet zo eerlijk...
In de C# variant geef je min of meer expliciet aan waar de resource weggegooid mag worden, terwijl in je C++ variant de resources allemaal impliciet op het einde worden weggegooid omdat ze out of scope zijn.

En dat is dus exact mijn rant. De code is identiek, en in C# had het bijvoorbeeld ook zo gekund:

C#:

    using Resource1 resource1 = new Resource1();
    // wat code 
    using Resource2 resource2 = new Resource2();
    // nog wat code 
    using Resource3 resource3 = new Resource3();
    // meer code

(grammaticaal wordt dit misschien wat problematisch wegens de using directive, maar het gaat om het idee)

Dus, als je enkel op de plaatsen code zou hebben waar jij dat aangeeft, is de C# inderdaad erg omslachtig, en zou het op dezelfde manier als C++ geschreven kunnen worden...
Als je ze in C++ expliciet weg wilt gooien dan moet je destroyen en in principe het geheugen vrijgeven.

Ik heb het meer over C++/CLI waar je met doodnormale garbage collected .Net classes werkt. Geheugen vrijgeven is er niet bij, het gaat puur om het disposen. En dat kan in C++/CLI middels destructors, in C# moet dat met using (of idd custom code die de juiste functies aanroept, maar dat is dan weer error-prone)

Anyway, ik wil hier helemaal geen C++/CLI vs C# discussie starten, ik zei alleen dat using() ruk was ivm destructors

(FYI: C++/CLI is geen C++. Het is een aparte (gestandaardiseerde) taal met de syntax van C++ en wat extra features voor .Net 2.0)

[ Voor 3% gewijzigd door .oisyn op 16-01-2007 11:59 ]

[MBV]

Zeg jongens, kunnen we weer even naar de titel kijken? Die is niet C++<=> C# <=> Java <=> J# flamewar

Multiproc vind ik veel interessanter

[ Voor 17% gewijzigd door MBV op 16-01-2007 12:05 ]

[.oisyn]

Fair enough, hier is de thread-library proposal voor C++09: http://www.open-std.org/j...cs/papers/2006/n2094.html

[MBV]

zo, en wat vind jij daar de interessantste onderdelen van, en wat zou er anders in moeten? Waar schiet het in te kort?

[Olaf van der Spek]

.oisyn schreef op dinsdag 16 januari 2007 @ 12:31:
Fair enough, hier is de thread-library proposal voor C++09: http://www.open-std.org/j...cs/papers/2006/n2094.html

09 pas?

[.oisyn]

MBV schreef op dinsdag 16 januari 2007 @ 17:14:
zo, en wat vind jij daar de interessantste onderdelen van

dát er een threading lib voor de volgende C++ komt, dat vind ik al interessant genoeg.

[MSalters]

Mischien wel opmerkelijk in dit verband is de verwijzing naar het werk van Boehm, wat in eerste instantie voor Java bestemd was.

[MBV]

.oisyn schreef op dinsdag 16 januari 2007 @ 18:38:
[...]

dát er een threading lib voor de volgende C++ komt, dat vind ik al interessant genoeg.

Ach ja, dat zat toch ook al in Qt, en Borland had zijn Pascal-rommel toch ook beschikbaar in C++? Sorry voor dit en het vorige flauwe bericht, mijn volgende bericht zal wat inhoudelijker zijn _{maar ik weet niet wanneer ik daar tijd voor heb}

[flowerp]

Practisch nieuws:

nieuws: Intel verwacht 1 miljoen quadcores te verkopen in H1 2007

Intel verwacht 1 miljoen quadcores te verkopen in H1-2007

H1-2007 is nu al begonnen, en 1 miljoen is niet niks. Ondertussen is ook al het bulk van de nieuw verkochte computers tenminste dual-core. Toen dit topic slechts 2 maanden geleden begon viel het aantal dual-core bezitters nog wel mee, maar nu kom ik ze echt overal tegen. Collega's, familie, vrienden; overal zie je ze nu.

[Olaf van der Spek]

flowerp schreef op woensdag 17 januari 2007 @ 21:51:
H1-2007 is nu al begonnen, en 1 miljoen is niet niks. Ondertussen is ook al het bulk van de nieuw verkochte computers tenminste dual-core. Toen dit topic slechts 2 maanden geleden begon viel het aantal dual-core bezitters nog wel mee, maar nu kom ik ze echt overal tegen. Collega's, familie, vrienden; overal zie je ze nu.

1,3% van de nieuwe systemen is toch niet veel?

[chris]

Dit vond ik wel een mooie quote, van de designers van Lua

… we did not (and still do not) believe in the standard multithreading model, which is preemptive concurrency with shared memory: we still think that no one can write correct programs in a language where ‘a=a+1’ is not deterministic.

Gelezen in The evolution of Lua

[flowerp]

Olaf van der Spek schreef op woensdag 17 januari 2007 @ 22:24:
[...]
1,3% van de nieuwe systemen is toch niet veel?

Wel als je bedenkt dat dit nu nog slechts de absolute high-end bovenlaag moet voorstellen, en dat dat nu dus al zo hoog is. Dit zal dus zeer snel doorsijpelen naar het midden segment, en dan hebben we het toch wel over fors hogere cijfers.

Als je naar duals kijkt dan zie je die cijfers nu al. Sla een willekeurige folder van de buurt super open, en er staan aanbiedingen in van systemen met dual cores. Als ik gebasseerd op de folders die ik lees een gok zou moeten maken, dan zou ik zeggen dat >80% van de nieuw verkochte computers vandaag dual core is.

[Olaf van der Spek]

flowerp schreef op dinsdag 23 januari 2007 @ 22:26:
Wel als je bedenkt dat dit nu nog slechts de absolute high-end bovenlaag moet voorstellen, en dat dat nu dus al zo hoog is. Dit zal dus zeer snel doorsijpelen naar het midden segment, en dan hebben we het toch wel over fors hogere cijfers.

Dat is waar, maar ook redelijk logisch. Als Intel (en AMD) straks overstappen naar 45 nm hebben ze weer twee keer zoveel transistors beschikbaar en kan het aantal cores zo weer verdubbeld worden.

[flowerp]

Olaf van der Spek schreef op dinsdag 23 januari 2007 @ 23:02:
[...]

Dat is waar, maar ook redelijk logisch. Als Intel (en AMD) straks overstappen naar 45 nm hebben ze weer twee keer zoveel transistors beschikbaar en kan het aantal cores zo weer verdubbeld worden.

Inderdaad, en omdat de meeste software niet zomaar even uit de lucht komt vallen is het dus zaak dat we -nu- beginnen met rekening houden hiermee. Over een tijdje staan die quad-cores dus toch echt wel bij iedereen thuis, en dan gaan mensen echt wel om geschikte software vragen.

Effin, ongeveer de stelling uit de eerste paar posts

[Verwijderd]

Ik ga binnekort aan de slag met een afstudeeropdracht op dit onderwerp.
Aangezien ik hier wel een aantal interessante posts zag staan vroeg ik me af of er mischien ook
bronnen zijn die deze uitspraken onderbouwen: in de vorm van papers/boeken of andere
artikelen. Ik heb zelf wel al wat gevonden, maar nieuwe papers zijn altijd welkom.

Dus mocht een van jullie nog enkele pointers naar artikelen op het vakgebied van concurrency en parallelisme weten dan zijn deze welkom. Met name op het gebied van het opdelen van applicaties in modulen die parallel uitgevoerd kunnen worden en dus het transformeren van sequentiele verwerking naar parallelle verwerking.

[MBV]

U vraagt, wij draaien: http://www.bmi2.bmt.tue.nl/philbers/2IN50/overzicht.html

van een vak wat ik op het moment aan de TU/e volg. Voor het geval je een HBO-er bent: hint: er staat een mailadres. Professoren bijten niet, ze vinden het soms juist leuk dat je belangstelling toont Als je Universitair bent: schaam je dat je op GoT om links vraagt

[flowerp]

Voor al die programmeurs hier die nu -nog- niet de trend naar meerdere cores zien en denken dat "intel binnenkort gewoon weer de klok snelheden omhoog gooit" :

nieuws: AMD heeft groot vertrouwen in quadcore

Verwijderd schreef op woensdag 24 januari 2007 @ 14:24:
vroeg ik me af of er mischien ook
bronnen zijn die deze uitspraken onderbouwen: in de vorm van papers/boeken of andere
artikelen.

In de topic al meerdere malen genoemd, maar voor als je hem nog niet gezien had, deze blijft echt -de- klassieker over dit onderwerp:

http://www.gotw.ca/publications/concurrency-ddj.htm

Het onthuld geen nieuwe dingen over parallel programmeren zelf, nog zul je er specificieke technieken in vinden. Eigenlijk is de text bijna triviaal te noemen, maar juist de bijna volledig voor de hand liggende observeringen gecombineerd met de ijskoude praktijk zoals je 'huis, tuin en keuken' programmeurs overal ziet reageren (bijvoorbeeld in een aantal van de eerste posts in dit topic), maakt dit werk zo brilliant.

[H!GHGuY]

en als je dan toch op gotw.ca bent, klik dan meteen door naar de PDF slides van herb sutter over concurrency waarin hij 'futures', 'actives' e.a. uitlegt...
Zoeken op "the free lunch is over"

heb die vandaag op het werk zitten lezen. Hier zijn enkel van zijn ideëen al gepasseerd, of ik had er elders al over gelezen, maar telkens opnieuw heb ik een "waaw" effect: "give it to me, give it to me NOW"

[EfBe]

Maar... zolang de processors niet een shared cache hebben voor de cores, is het werken met multi-threaded apps op meerdere cores erg lastig, want de views op memory op de verschillende cores loopt dan niet in sync.

Verder het ontbreken aan transactional memory in conventionele platforms (ook VM's) levert niet echt een voordeel op.

Gaat het niet de kant op dat je gewoon meerdere applicaties tegelijk op een multi-core machine kunt draaien, dus bv virtualization makkelijker wordt en het voornamelijk richting server-side toepassingen gaat?

Begrijp me niet verkeerd, parallellisatie van algoritmen is erg belangrijk en indien mogelijk moet het ook zo geimplementeerd worden dat het geparallelliseerd kan worden. Echter, ik denk dat je gaat zien wat je ook in de services wereld hebt gezien: dat je vertikaal in een applicatie delen verpakt in een aparte app / service die dan dus op een aparte core draait en zo je parallellisatie pakt, ipv dat je zoekt naar parallellisatie op microniveau (e.g. in een routine bv).

[MSalters]

Views op memory kunnen via memory barriers redelijk effectief in sync gebracht worden. Verder is het MESI protocol recent geoptimaliseerd tot MOESI, waarmee multicore CPUs zelfs zonder shared cache nog voordeel kunnen hebben van snelle communicatie (directe cache naar cache updates)

[Olaf van der Spek]

EfBe schreef op woensdag 31 januari 2007 @ 19:02:
Gaat het niet de kant op dat je gewoon meerdere applicaties tegelijk op een multi-core machine kunt draaien, dus bv virtualization makkelijker wordt en het voornamelijk richting server-side toepassingen gaat?

Zelfs voor services is het draaien van 'onafhankelijke' threads/processen vaak niet de juiste oplossing (qua performance).
Maar op de desktop heb je vaak maar een process dat veel CPU tijd nodig heeft en dan ontkom je niet aan multi-threading.

[EfBe]

Olaf van der Spek schreef op woensdag 31 januari 2007 @ 22:35:
[...]

Zelfs voor services is het draaien van 'onafhankelijke' threads/processen vaak niet de juiste oplossing (qua performance).
Maar op de desktop heb je vaak maar een process dat veel CPU tijd nodig heeft en dan ontkom je niet aan multi-threading.

Ik doel dan ook op vertikale segmentering binnen een applicatie. Dus autonome onderdelen binnen een applicatie die op een aparte core gaan draaien. Dat kun je zien als multi-threading, alleen heb je dan niet meerdere threads op dezelfde code, maar meerdere threads met ieder een verschillend onderdeel van de applicatie.

@MSalters: zolang het maar zonder verlies opgelost wordt is het prima, alleen zit je dan nog steeds met het ontbreken van transactional memory, IMHO onontbeerlijk voor parallel programming zonder kopzorgen.

[Olaf van der Spek]

nieuws: 'Onvoldoende parallelle software voor computerclusters'

EfBe schreef op donderdag 01 februari 2007 @ 09:41:
Ik doel dan ook op vertikale segmentering binnen een applicatie. Dus autonome onderdelen binnen een applicatie die op een aparte core gaan draaien. Dat kun je zien als multi-threading, alleen heb je dan niet meerdere threads op dezelfde code, maar meerdere threads met ieder een verschillend onderdeel van de applicatie.

Dat is op zich nuttig, maar het schaalt maar zeer beperkt. Dan heb je straks een dual-socket quad-core systeem, maar echt geen 8+ threads/processes om die cores goed bezig te houden.
En dan draait een database vaak op een andere computer, dus dan moet je 'zelf' nog meer cores bezig houden.

[ Voor 68% gewijzigd door Olaf van der Spek op 01-02-2007 14:07 ]

[flowerp]

Olaf van der Spek schreef op donderdag 01 februari 2007 @ 14:04:
nieuws: 'Onvoldoende parallelle software voor computerclusters'

Hey, die wilde ik ook al posten

Geeft wel aan dat het probleem blijft spelen. Gebruikers (onze klanten!) beginnen het nu al langzaam op te merken dat er een tekort een parallelle software gaat komen. Dit is natuurlijk nog maar de voorhoede...

Dat is op zich nuttig, maar het schaalt maar zeer beperkt.

Inderdaad, maar het is toch mooi meegenomen onder het motto van alle beetjes helpen. Dit soort opsplitsing heb je eigenlijk automatisch al in een unix pipeline, maar ook bijvoorbeeld games of emulators willen nog wel eens zoiets als het soundsysteem in een aparte thread laten draaien. Ook de background spell-checker van een wordprocessor zou je hier onder kunnen scharen.

Zeker met massive multi cores moet het parallelisme echt uit alle hoeken en gaten komen. Zo kun je dus een combinatie maken van je hoofd architectische onderdelen van je systeem als aparte services op eigen cores laten draaien, bepaalde algorithmen parallel ontwerpen (vaak recursief parallel), en om stukjes code waar de gebruiker niet onmiddelijk een resultaat van verwacht asynchroon uit te voeren (b.v. als een fire 'n forget job).

[EfBe]

Wat me wel een beetje verbaast is dat nog niemand over Fortress (http://fortress.sunsource.net/ ) heeft gesproken Ok, ok, fortran is niet meteen een taal waar je aan denkt wanneer je programmatuur gaat schrijven, maar fortress is wel een stap in de goede richting volgens mij.

[flowerp]

EfBe schreef op zaterdag 03 februari 2007 @ 10:05:
Wat me wel een beetje verbaast is dat nog niemand over Fortress (http://fortress.sunsource.net/ ) heeft gesproken

Hier stond laatst ook een stuk over op de FP. Heb er nog in gepost maar klaarblijkelijk vergeten de link hier te crossposten Anyway: nieuws: Sun komt met open source opvolger voor Fortran: Fortress

Dit is inderdaad een voorbeeld van een taal die door z'n design automatisch beter aansluit op meerdere cores; je kunt er parallelisme makkelijker in uitdrukken. Het draait trouwens wel boven op de JVM, dus ik denk dat ook java programmeurs dit wel kunnen gebruiken om enkele algortimen in te schrijven en die dan als library functies aan te roepen in hun main app.

[JeromeB]

EfBe schreef op zaterdag 03 februari 2007 @ 10:05:
Wat me wel een beetje verbaast is dat nog niemand over Fortress (http://fortress.sunsource.net/ ) heeft gesproken Ok, ok, fortran is niet meteen een taal waar je aan denkt wanneer je programmatuur gaat schrijven, maar fortress is wel een stap in de goede richting volgens mij.

Ik ben niet zo geïnteresseerd in threading en multi-core programming, maar ik heb een tijdje terug een aantal slides doorgelezen. Voorzover ik het heb kunnen zien lijkt de syntax weinig op Fortran, dat is volgensmij een verkooppraatje. Bovendien bevat de taal allerlei nieuwe features die niet terug te vinden zijn in de oude bekende Fortran-varianten of zelfs in huidige programmeertalen. Sommige van die features zijn best interessant, maar ik vraag mij af of ze werkelijk productief zijn.

• Die juxtaposition-operator is best een leuk idee, maar in de praktijk lijkt me die toch vooral verwarrend.
• Het gebruik van unicode is een handige toevoeging als je zelf operators wil toevoegen. Het is échter niet handig voor operators die veel gebruikt worden. Je moet dan een apart toetsenbord hebben of specifieke toetstencombinaties onthouden. Bovendien vraag ik mij af waarom ze niet voor bijvoorbeeld een type-setting-systeem als LaTeX hebben gekozen.
• Het lijkt vooral handig voor mensen die bezig zijn met wiskundige-problemen, maar hoe zit het met andere problemen? In de slides die ik heb doorgenomen komen die problemen niet aan bod.
• De syntax is misschien te afwijkend tov talen die momenteel veel worden gebruikt zoals Java, C# en C++.

[flowerp]

JeromeB schreef op zaterdag 03 februari 2007 @ 11:59:
[...]
Voorzover ik het heb kunnen zien lijkt de syntax weinig op Fortran, dat is volgensmij een verkooppraatje.

Inderdaad, behalve dat ze het dan niet verkopen natuurlijk. Het lijkt een beetje op het VB vs VB.NET verhaal, waarbij de laatste niet gewoon een .NET uitbreiding is van de eerste maar eigenlijk een compleet andere taal.

Bovendien bevat de taal allerlei nieuwe features die niet terug te vinden zijn in de oude bekende Fortran-varianten

Lijkt me logisch, anders zou het geen nieuwe taal zijn maar gewoon een implementatie van de oude spec

• De syntax is misschien te afwijkend tov talen die momenteel veel worden gebruikt zoals Java, C# en C++.

Zolang programmeurs niet hun hele applicatie in zo'n afwijkende syntax moeten maken, zou dit niet perse een probleem moeten zijn. Met name Java programmeurs zijn toch al gewend om in meerdere syntaxen te werken, zeker serverside programmeurs. Zo heb je naast Java in een web project natuurlijk nog HTML en Javascript maar ook nog het sub taaltje EL en voor de view layer zelfs nog een ander 'taaltje' JSTL (waarbij alle statements XML worden, dus dingen als <c:if>. <c:set> etc). In de model layer gebruiken vele mensen natuurlijk een of andere query taal, meestal SQL of een variant hierop i.c.m. een O/R mapper. Sommige maken dan ook nog eens gebruik van stored procedures in hun DBMS.

Ook domain specific languages worden al vaker gebruikt. Vele partijen maken wel gebruik van 1 of andere speciale taal om business rules in uit te drukken, of een speciale dataflow taal om high-level navigation rules in uit te drukken (zoals bv in Jboss Seam).

Al met al zit je dan al binnen 1 project met gemak aan 8 a 9 talen, allemaal min of meer in hun eigen afgeschermde domain. Natuurlijk is er soms overlap. Ik kan een bepaalde berekening (laten we zeggen een gemiddelde nemen ofzo) door de DB laten uitvoeren d.m.v. SQL query of desnoods een stored procedure, maar dezelfde berekening kan ik in Java doen.

In dit geheel kun je fortress mischien ook (in de toekomst?) plaatsen. Je normale logica hou je in Java, maar voor specificieke dingen die echt onder de noemer "zware berekening met algoritme" vallen kun je dan in Fortress implementeren en makkelijk op meerdere cores laten draaien.

[flowerp]

Olaf van der Spek schreef op woensdag 17 januari 2007 @ 22:24:
[...]
1,3% van de nieuwe systemen is toch niet veel?

De percentages stijgen nu rap, zie bijvoorbeeld deze FP post:

nieuws: Intel verkoopt meer multicore- dan singlecorechips

[Olaf van der Spek]

flowerp schreef op vrijdag 23 februari 2007 @ 21:34:
[...]


De percentages stijgen nu rap, zie bijvoorbeeld deze FP post:

nieuws: Intel verkoopt meer multicore- dan singlecorechips

Daar staan toch geen cijfers in voor quad-core?

[flowerp]

Olaf van der Spek schreef op zaterdag 24 februari 2007 @ 09:51:
[...]
Daar staan toch geen cijfers in voor quad-core?

Indirect:

over half of the central processing units (CPUs) that the company shipped in the fourth quarter contained two or more cores.

[Eric Oud Ammerveld]

Ik ben benieuwd welke richting de "aansturing" van die cores gaat krijgen.

Als je het verhaal op machine niveau laat beheersen zullen mogelijk de compilers wat extra info krijgen zodat ze op een handige manier stukken berekeningen uit elkaar trekken en zorgen dat ze parallel uit gevoerd kunnen worden.

Het lastige punt hierbij is het garanderen van een gelijke uitvoer als bij seriele behandeling en tegelijkertijd snelheidswinst behalen.

Een niveau hoger (kernel van het OS) is eigenlijk waar het nu gebeurt maar of dat op desktop systemen en high performance systemen het gewenste resultaat geeft is nog de vraag imho.
Het dynamisch inzetten zal voor een vergroting van de rekenkracht kunnen zorgen.

Ik vraag me af of de bepaling welke core te gebruiken uberhaupt bij het programma zal moeten liggen.
Eerlijk gezegd heb ik me er maar oppervlakkig in verdiept, maar het lijkt me dat wanneer een programma een threat opent/aanvraagt bij de kernel dat de kernel op zijn beurt zou moeten bepalen op welke core de threat moet worden afgehandeld.

Daarmee laat je flexibel hoeveel cores de berekeningen van de applicatie op zich nemen en zal je de uivoering van zaken als 3D rendering goed kunnen verdelen en zelfs kunnen distribueren over verschillende systemen (iets dat met heftige wiskundige calculaties soms best interessant kan zijn; denk aan Seti/Koetje/e.d.).

Ik geloof dat distcc (een distributed c compiler voor linux) het compilen over meerdere systemen een vergelijkbare werking heeft.
Alles dat gecompileerd kan worden in een losse threat wordt naar een ander systeem gestuurd en de aansturing hiervan wordt gemanaged door het host systeem (of in te stellen systeem)..
Nu is het niet zo dat we allemaal continu aan het compilen zijn, maar ik denk dat er in iedere applicaitie wat zaken zijn die niet atomair uitgevoerd hoeven worden, waardoor je hiervoor dus parallelisatie zou kunnen toepassen.

[chris]

Het probleem met imperatieve talen is dat er geen onderscheid wordt gemaakt tussen functies die wel of geen IO doen. Als je het gedistribueerd programmeren door de compiler wil laten doen, zal het erg van pas komen als die scheiding er wel is.

Verder wordt er in veel imperatieve talen nog steeds te serieel gedacht, als er meer support was voor constructies als map en fold zou dit veel uit kunnen maken. Ik denk dat talen als C# hier misschien wel een heel eind kunnen gaan komen.

[EfBe]

Er is nog niets gezegd over map / reduce, een algo wat door google gebruikt wordt voor het parallelliseren van queries over een grote hoeveelheid machines. Dit algorithme is ook bruikbaar voor het parallelliseren van werk in een applicatie.
http://labs.google.com/papers/mapreduce.html

Ik heb wat tests gemaakt en met wat goede map /reduce functies in een class of library kun je ver komen binnen je eigen code. Het is natuurlijk wel zo dat je zelf de parallellisatie plekken moet aangeven, maar het is dan ook wel erg simpel om te bouwen.

In .NET heb je bv een threadpool class, die je delegate op een thread uitvoert die beschikbaar is. Je kunt dit gebruiken om alle resources die beschikbaar zijn te benutten. Een voorbeeld staat hier:
http://www.knowing.net/Pe...48-970b-4e659aea8299.aspx

Ik heb dit wat omgecat zodat het wat beter zn werking illustreert:

C#:

delegate void BackgroundFunction<T>(T memberOfEnumerable);

public class MapReduce
{
    public const int SEGMENTSIZE = 100;
    public const int SEGMENTCOUNT = 100000;

    static void Main(string[] args)
    {
        List<int[]> nums = new List<int[]>();

        for(int i = 0; i < SEGMENTCOUNT; i++)
        {
            int[] segment = new int[SEGMENTSIZE];
            nums.Add(segment);
            for(int j = 0; j < SEGMENTSIZE; j++)
            {
                segment[j] = (i * SEGMENTSIZE) + j;
            }
        }

        Random r = new Random();
        BackgroundFunction<int[]> func = delegate(int[] segment)
        {
            int foo = 0;
            for(int i = 0; i < segment.Length; i++)
            {
                if(i == 0)
                {
                    //      Console.WriteLine(segment[0]);
                }
                foo += i;
            }
        };

        Stopwatch watch = new Stopwatch();
        Console.WriteLine("Started");
        watch.Start();
        ParallelApply<int[]>(nums, func);
        watch.Stop();
        Console.WriteLine("Done");
        Console.WriteLine("The whole operation took: {0}", watch.Elapsed.ToString());

        Console.ReadKey();
    }


    static void ParallelApply<T>(List<T> segments, BackgroundFunction<T> function)
    {
        ManualResetEvent done = new ManualResetEvent(false);
        int doneRefCount = 1;

        BackgroundFunction<object> wrappedBlock = delegate(object state)
        {
            function.DynamicInvoke((T)state);
            int isDone = Interlocked.Decrement(ref doneRefCount);
            if(isDone == 0)
            {
                done.Set();
            }
        };

        WaitCallback callback = new WaitCallback(wrappedBlock);
        foreach(T segment in segments)
        {
            Interlocked.Increment(ref doneRefCount);
            ThreadPool.QueueUserWorkItem(callback, segment);
        }
        int isDoneLate = Interlocked.Decrement(ref doneRefCount);
        if(isDoneLate == 0)
        {
            done.Set();
        }

        done.WaitOne();
    }
}

Wij gaan dit binnenkort toepassen voor in-memory filters en ander bulkwerk in-memory (denk aan het mergen van child nodes in een prefetch graph met de parent nodes) in onze library, zodat beschikbare resources beter benut worden. Je kunt middels de Environment class in .NET de beschikbare cores opvragen dus je kunt de code finetunen dat bij een single core je de hele handel overslaat (want dan heb je alleen maar last van de threading) maar bij multiple cores je de meerdere cores benut.

[ Voor 8% gewijzigd door EfBe op 25-02-2007 11:40 ]

[Alarmnummer]

Persoonlijk denk ik dat we gaan paralleliseren op 2 niveau's:

voor rekenintensieve applicaties is het handig om op heel low level te gaan paralleliseren. Het probleem wat ik met deze aanpak (icm Java) heb is dat je objecten tussen threads laat delen, en dat gaan consequenties met zich meebrengen (race problemen, visibility problemen etc). Je moet trouwens niet vergeten dat veel cpu's zelf ook kunnen paralleliseren. Als bv instructies niet van elkaar afhankelijk zijn, kunnen ze automatisch parallel naast elkaar uitgevoerd worden (dynamic scheduling).

Voor veel enterprisy applicaties kun je vaak paralleliseren door meerdere threads naast elkaar te draaien, omdat je op hoog niveau al kunt zien welke stukken niet van elkaar afhankelijk zijn. Hierdoor voorkom je veel concurrency problematiek en kunnen programmeurs vrij eenvoudig werken. De omgeving is verantwoordelijk voor het multithreaden, zo lang je maar aan een aantal guidelines houd (veilige immutable objecten maken, geen mutable objecten delen tussen threads). Zo gauw je trouwens niet meer van deze regels gebruik kunt maken, dan begint het echt interessant te worden. Maar zo lang de huidige complexiteit blijft bestaan, betwijfel ik of de meeste developers wel veilige applicaties kunnen neerzetten. De meeste mensen weten totaal niet van alle problemen die er spelen.

[edit]
Ik heb nog even zitten bladeren in dit topic, in het begin heb ik ongeveer hetzelfde al gezegd

[ Voor 22% gewijzigd door Alarmnummer op 26-02-2007 11:02 ]

[flowerp]

Weer een interessante update wat betreft de marktsituatie:

nieuws: 'Quadcores in helft desktops in 2009'

Dit is een al heel wat concreter cijfer dan het eerdere bericht van de FP wat ik hier poste. 2009 is al over krap 2 jaar. In de tijd zou, volgens deze speculatie, dus de helft van alles desktops quad-core zijn. Dat is echt een behoorlijk significant aandeel.

Om de eerdere argumenten nogmaal eens te herhalen: dual-cores kun je nog afdoen met dat de 2de core background tasks kan draaien, maar met quad-cores moeten wij als programmeurs toch echt wat gaan doen.

Kortom zeker die +- 50% van de programmeurs hier die voornamelijk of gedeeltelijk aan desktop applicaties werken hebben nog slechts zo'n 2 jaar om hun bestaande engines aan te passen en zichzelf om te leren gaan met deze toch wel ingewikkelde materie.

Het ongelooflijke is dat zelfs na enkele jaren van klok snelheden die niet boven de 3Ghz uitkomen er nog steeds programmeurs zijn die multiple cores totaal negeren en denken dat: "intel binnenkort gewoon weer de klok omhoog gooit". (gelukkig zijn dat hier op got maar 4 mensen )

[Alarmnummer]

Als je naar de server omgeving kijkt, dan ze je vaak dat ze meer dan een cpu hebben. Dus voor serverside programmeurs is het eigenlijk nog belangrijker.

Een oplossing zoals http://www.pervasivedatarush.com/ zou wel een rol kunnen spelen om alle cores effectiever in te zetten. Een van de grootste problemen die developers nu moeten overwinnen is dat al die synchrone aanroepen concurrent execution enorm verhinderd.

Ik ben zelf ook met wat support aan het spelen voor vereenvoudigen asynchrone executie:
http://prometheus.codehaus.org

Het channels en processors/process gedeelte kan asynchrone en synchrone executie tot een configuratie detail maken. Ik ben op dit moment bezig om een demo applicatie in elkaar te zetten die we deze maand gaan clusteren mbv Terracotta. Hopelijk komt Jonas Boner langs volgende maand bij het bedrijf waar ik werk.

heb je trouwens nog een email adres? Een vrouw die zich bezighoud met concurrency control kan ik natuurlijk niet aan me laten voorbij gaan.

[ Voor 41% gewijzigd door Alarmnummer op 01-05-2007 23:04 ]

[flowerp]

Alarmnummer schreef op dinsdag 01 mei 2007 @ 22:40: Ik ben op dit moment bezig om een demo applicatie in elkaar te zetten die we deze maand gaan clusteren mbv Terracotta. Hopelijk komt Jonas Boner langs volgende maand bij het bedrijf waar ik werk.

Is dat nog een beetje gelukt?

Wat betreft de markt situatie; van de week liep ik door een winkelstraat en zag dat diverse winkels PCs op basis van een quadcore aanbieden voor een jan en alleman prijs (< 1000,-). Paradigit had zelfs een grote advertentie buiten staan, iets in de trend van: koop nu een quadcore PC en ervaar nog meer snelheid. Een losse quadcore CPU is ook gewoon overal te koop (zie b.v. http://www.mycom.nl/Produ..._Core_2_Q6600/143247.aspx).

Amper 9 maanden na de openingspost van dit topic zien we dat single cores nagenoeg verdwenen zijn. Zowel Intel als AMD bieden alleen nog dual cores aan; de goedkoopste dual core kost momenteel zo weinig dat er geheel geen ruimte meer over is voor single cores. Daarnaast beginnen quad cores dus behoorlijk mainstream te worden.

Ik vraag me af of de programmeurs die in het begin van het topic nog niet echt het nut inzagen van parallel programmeren dat nu wel zien? Of denken er nog steeds mensen dat dual en quad core PCs iets voor de hardcore tweakers blijft?

offtopic:
[quote]
heb je trouwens nog een email adres? Een vrouw die zich bezighoud met concurrency control kan ik natuurlijk niet aan me laten voorbij gaan.
[/quote]

Misschien moet je bij ons komen werken We hebben hier zelfs nog 2 andere vrouwen die als hardcore Java developer werken, 1'tje met een WO informatica diploma en de andere met een WO AI diploma

[LauPro]

Ik blijf nog steeds bij mijn standpunt dat het invoeren van meerdere cores in eerste instantie is bedoeld om meerdere applicaties (of processen) naast elkaar te draaien. En niet is bedoeld om het threadgebruik in applicaties te bevorderen. Zeker ook gekeken in Terminal Service omgevingen zijn 'overthreaded' applicaties niet wenselijk voor de performance.

Steeds meer consumenten (naast de Tweakers) zullen (onbewust) een multi core systeem kopen omdat er nagenoeg geen alternatief meer is. Een aantal exotische bordjes van VIA zijn nog single CPU maar die zijn dan juist ook gemaakt op energiebespraring vaak. En bij multi core systemen gaat er altijd CPU-tijd (en dus energie) verloren aan syncing wat niet in lijn staat met de besparing die men dan beoorgt.

Pas als er bijvoorbeeld een 64 of 128 core CPU is dan is het interessant om te kijken naar threading in applicaties. En volgens mij (zoals dit topic wel beaamd) zullen alle goede softwareontwikkelaars uit zichzelf wel threading toepassen als dit een goede snelheidswinst oplevert.

[Punkie]

@LauPro: welke snelheid winst moet multicore programmeren voor multi-core systemen leveren voor ze voor een desktop pc een meerwaarde leveren? Uit je opmerking af te leiden schat ik dat je verschillende tientallen bedoelt. Immers een speedup van 8 zou al mogelijk zijn met 16 cores. Maar alleen vanaf 64 (zeg maar speedup x 20) voor jou.

Voor een speedup van 5 zouden heel wat mensen graag hun personeels uitgaven verdubbelen. Enkele mogenlijkheden maar niet niet gelimiteerd tot: compilers,video editing, rendering, database engines, search engine, imaging, entertainment,...
Op een desktop zijn dit al stuk voor stuk heel veel gebruikte applicaties. En deze speedup zal binnen enkele jaren te verkrijgen zijn, waarvoor je NU dus moet gaan onwikkelen.

Als je nu nog zegt dat dit niet de moeite is gelieve dan uit te leggen waarom de ontwikkelaars hiervan de neus zouden ophalen voor een speedup van factor 5 en waarom ze wel een jaar lang werken aan hun product om het gemiddeld met een factor 2 te versnellen?

[ Voor 8% gewijzigd door Punkie op 03-08-2007 15:52 ]

[.oisyn]

LauPro schreef op vrijdag 03 augustus 2007 @ 15:27:
Ik blijf nog steeds bij mijn standpunt dat het invoeren van meerdere cores in eerste instantie is bedoeld om meerdere applicaties (of processen) naast elkaar te draaien.

De enige "bedoeling" van multicore in de desktop PC is omdat er in de lengte (meer GHz) geen winst meer te halen is wegens natuurkundige limieten in de huidige stand van techniek, dus gaan ze maar verder in de breedte (meer CPUs). Dat schaalt namelijk heel makkelijk. Jammer genoeg schalen apps niet automatisch mee, tenzij je ze naast elkaar draait, wat bijna nooit het geval is (dwz, je draait bijna nooit 2 apps naast elkaar die 100% van een enkele core vreten - de meesten staan gewoon te idlen, en dan is een dualcore al genoeg om de responsiveness van het systeem op peil te houden).

Om daar als applicatie van mee te snoepen moet je multithreaded gaan programmeren. En aangezien de tendens toch al is dat we richting de tientallen cores gaan (quadcores gaan al over de toonbank), kunnen we er maar beter meteen mee beginnen. Dan schaalt de app namelijk wël automatisch mee zodra er meer cores beschikbaar worden.

Ik kan me dus compleet niet vinden in jouw standpunt.

[ Voor 20% gewijzigd door .oisyn op 03-08-2007 16:19 ]

[LauPro]

Ik ken geen grote applicaties waar een speedup wenselijk zou kunnen zijn die u nog niet gethread zijn. Te noemen:
• Office: MSO, OOo; beide hebben vele vormen van theading, saven op achtgrond, render apart van invoer, spellingscontrole.
• *Cad: Deze applicaties zijn standaard ook al voorzien van threading en de meeste fabrikanten ondersteunen ook multi core systemen.
• Browsers: Moz/FF heeft een heftige vorm van multithreading, plaatjes kunnen in aparte threads worden geladen en tot 1 geheel worden gerenderd. Over het algemeen is dit geen snelheidsissue meer. IE zal ongetwijfeld vergelijkbare technieken hebben.
• CRM/ERM: Deze platforms hebben meestal zelf optimalisaties of zijn iig zo afgesteld dat er snel mee gewerkt kan worden (als ze al niet webbased zijn en met frames werken).

Traagheden in huidige software zit meestal in knelpunten bij (netwerk)protocollen, te noemen:
• SMB browsing dat een eeuwigheid duurt waardoor de gebruiker moet wachten bij printen.
• DNS servers die traag zijn/of niet bereikbaar die de meest wonderlijke errors/freezes geven.
• Converten van een optimized vector format naar een groot, archaïstisch format (PS bij printen bijv.).
• Inlezen inefficiënte XML datastructures (OOo heeft er last van). Dit valt deels te threaden maar komt ook omdat XML eigenlijk geen formaat is voor snelheid bij inlezen.

Ik zie dus geen grootschalige verbeterpunten binnen de huidige softwarebase. Het idee dat je alle software zal moeten worden herontwikkelen voor een 8 core processor vind ik echt onzin. Dat is een vergelijkbare hype als met AJAX. Dit proces loopt al minimaal 10 jaar. En bij vrijwel alle implementaties van threading is er de keuze voor de ontwikkelaar hoeveel threads er moeten worden gegenereerd. Nu wordt dit afgestemd op de huidige markt (zoals altijd eigenlijk). Zodra er een 32 core CPU is het een kwestie van finetunen en shippen. Niemand gaat software uitbrengen voor processoren/architecturen die nog niet op de markt zijn. Dat zag je bij 16 > 32 bit, 32 > 64 bit en zul je ook zien bij 'dual core optimised' naar 'quad core optimised' (whatever dat may be). Ik zie veel liever dat als je multi core gaat ontwikkelen dat je dan ook vooral uit gaat van 'multiple cores' en niet van 2, 4 of 8.

Daarnaast zie ik in bedrijfsomgeving steeds meer het Terminal Server concept ontplooien, daar is het (zoals ik al aan gaf) erg onwenselijk dat applicaties rijkelijk threads spawnen. Omdat dat met bijvoorbeeld 50 users op 1 server een gigantisch aantal threads geeft met alle syncronisatie van dien.

Network based computing is naar mijn idee zeker voor enterprise omgevingen de toekomst. Datgene dat Sun 10 jaar geleden al probeerde te doen zal op de lange termijn de oplossing vormen nu er nauwelijks meer geografische beperkingen zijn in de infrastructuur (Internet). Dat houdt in dat er centrale serverparken zijn waar alle data wordt gestored en geback-upped. De eerste stap die nu gebeurt is het webserver/webbrowser concept: servers centraliseren. P2P-systemen zijn in omkomst maar op dit moment nog niet haalbaar (en waarschijnlijk vanuit security gezien nooit) om er een goede database mee te onderhouden oid.

Dus eigenlijk zie ik op lange termijn (zeg 20 jaar) de fat clients bij de eindgebruiker verdwijnen. Bij de particulier thuis zal het misschien wat langer duren, maar de verwachting is wel dat je in de toekomst gewoon processor power als een abonnement in koopt.

[ Voor 8% gewijzigd door LauPro op 03-08-2007 19:56 ]

[Olaf van der Spek]

LauPro schreef op vrijdag 03 augustus 2007 @ 15:27:
Pas als er bijvoorbeeld een 64 of 128 core CPU is dan is het interessant om te kijken naar threading in applicaties.

nieuws: Sun komt met 64 threads tellende Niagara 2

LauPro schreef op vrijdag 03 augustus 2007 @ 16:46:
Network based computing is naar mijn idee zeker voor enterprise omgevingen de toekomst. Datgene dat Sun 10 jaar geleden al probeerde te doen zal op de lange termijn de oplossing vormen nu er nauwelijks meer geografische beperkingen zijn in de infrastructuur (Internet). Dat houdt in dat er centrale serverparken zijn waar alle data wordt gestored en geback-upped. De eerste stap die nu gebeurt is het webserver/webbrowser concept: servers centraliseren.

Alle storage op servers en dus diskless clients vind ik wel logisch (in een bedrijf), maar iets als terminal server niet altijd. De responsiveness is toch een stuk minder en bepaalde apps (3D, games, video enzo) zijn geloof ik helemaal niet mogelijk.

[ Voor 52% gewijzigd door Olaf van der Spek op 03-08-2007 17:16 ]

[LauPro]

Olaf van der Spek schreef op vrijdag 03 augustus 2007 @ 17:08:
nieuws: Sun komt met 64 threads tellende Niagara 2

Dit zijn toch wel CPU voor een tamelijk niche markt (zoals in de nieuwspost ook staat). Ik denk niet dat je deze snel in een desktop terug zal zien. En dat is vooralsnog wel de grootste markt als het gaat om performance. In enterprise-omgevingen ligt dat heel anders waar men vaak gewoon gewezen is op 1 platform gezien de schaal.

Alle storage op servers en dus diskless clients vind ik wel logisch (in een bedrijf), maar iets als terminal server niet altijd. De responsiveness is toch een stuk minder en bepaalde apps (3D, games, video enzo) zijn geloof ik helemaal niet mogelijk.

Dat is een kwestie van tijd. Men is bezig met een efficiënte versie van X11 bijvoorbeeld waarmee het wel degelijk mogelijk is om 3D te renderen via netwerk. Microsoft heeft voor zover ik weet ook plannen om met RDP 8.0 ofzo DirectX te gaan ondersteunen, nu is daarvoor de netwerkcapaciteit nog te laag eigenlijk (of de overhead te groot).

Dus nogmaals: voor serversoftware, games of andere performance prima optimaliseren voor MT. Maar de rest van de software is goed zoals die nu is, hooguit via de gebruikte toolkit wat optimaliseren.

[flowerp]

LauPro schreef op vrijdag 03 augustus 2007 @ 16:46: Niemand gaat software uitbrengen voor processoren/architecturen die nog niet op de markt zijn. Dat zag je bij 16 > 32 bit, 32 > 64 bit en zul je ook zien bij 'dual core optimised' naar 'quad core optimised' (whatever dat may be).

Dan snap je toch de strekking van dit topic niet helemaal. Het idee is juist dat voor meerdere cores programmeren niet gewoon iets is dat je even moet doen (zoals een compiler switch aanzetten), maar een geheel andere denkwijze van ontwikkelen vereist. Als je daar pas mee gaat beginnen als de dual core op de markt is, dan ben je te laat.

Of wacht, de dual core is natuurlijk al lang op de markt! Ik bedoel dus als je wacht totdat de quad core op de markt is dan ben je te laat.

Verhip! Die quad core is er ook al!

Wat bedoel je nu eigenlijk LauPro? Is het niet gewoon een beetje ontwijkgedrag van jou? Als er zo meteen alleen nog maar quad-cores te koop zijn en de oct-core ook al voor 200,- in de winkel ligt, dan ga jij pas je software voor meerdere cores schrijven als de hex-core er is? En als die er is, dan ga je je opeens pas weer aanpassen bij minimaal 32-core CPU's?

Of het bij jou echt zo is kan ik niet helemaal zeggen, maar ik bespeur bij toch wel een aantal programmeurs een zekere onwil om een nieuwe manier van programmeren te leren. Ze hebben hun hele leven al sequentieel geprogrammeerd, en omschakelen naar parallel denken is dan extra moeilijk. De vergelijking is al eerder gemaakt, maar het lijkt op de omschakeling van gestructureerd naar object geörienteerd programmeren. Ook toen wilde een hele generatie verstokte programmeurs niet mee en werden er veel excuses bedacht waarom OO onzin was (dingen als 'geen enkel mainstream software pakket is zo complex dat het OO echt nodig heeft, alleen voor hele grote systemen is zoiets nodig').

M.b.t. meerdere cores is het dus handig als je er nu al mee begint. Vanwege de dual en quad cores van vandaag heb je er nu al voordeel van, maar je bent ook voorbereid op een toekomst die voor allen dan de meest blinden toch wel helder moet zijn.

[LauPro]

Dan begrijp ik het inderdaad misschien niet. Maar laten we wel wezen dat moderne talen stimuleren en alle tools hebben om MT te programmeren. Ik zie dan dus ook totaal niet in hoe iemand die nu met C++ begint bijvoorbeeld enkel sequentieel kan programmeren. MT is gewoon iets waar je op een gegeven moment tegen aan loopt en dan een oplossing voor gaat vinden (threads), ookal heb je single core. Bij .NET Java wordt je op dezelfde mannier al bijna gedwongen om met threads te werken. En een voorbeeld van Perl 6 met het pure keyword ligt ook op tafel dat vanuit het platform optimalisaties worden uitgevoerd.

Dus ik ontken helemaal niet het nut van threads. Maar ik vind dit topic een klein beetje een storm in een glas water. Leg mij nu eens het nut uit van een applicatie die 60 threads zou spawnen? Als je met een dergelijk aantal threads werkt dan heb je veelal een architectuur om die aan te sturen en ontkom je er niet aan om met bepaalde parameters te werken.

Als nu de mentaliteit ontstaat dat threads heel goedkoop zijn, en we zitten straks met een desktop waar 10-15 applicaties open staan met elk 60 threads dan zijn we terug bij af met onze performance.

Dát is het gevaar dat ik wil benadrukken. En ook hierbij wil ik nogmaals zeggen dat veel optimalisaties de taak van het overkoepelende platform/toolkit zijn en niet voor de programmeur.

[whoami]

Laatst heb ik hierover een interessant artikeltje gelezen.
The Free Lunch is over

[flowerp]

whoami schreef op vrijdag 03 augustus 2007 @ 21:10:
Laatst heb ik hierover een interessant artikeltje gelezen.
The Free Lunch is over

Dat is inderdaad een zeer interessant artikel van een gerespecteerd iemand uit de IT (Herb Sutter). Als het goed is staan er ook al enkele links en besprekingen van dit artikel in het begin van dit topic

[flowerp]

LauPro schreef op vrijdag 03 augustus 2007 @ 16:46:
Daarnaast zie ik in bedrijfsomgeving steeds meer het Terminal Server concept ontplooien, daar is het (zoals ik al aan gaf) erg onwenselijk dat applicaties rijkelijk threads spawnen. Omdat dat met bijvoorbeeld 50 users op 1 server een gigantisch aantal threads geeft met alle syncronisatie van dien.

Hier ben ik het op zich zeker mee eens. Hoewel je laatste opmerking de plank misschien misslaat (of je gebruikt simpelweg het verkeerder woord); bij 50 users hoeven de threads van de verschillende users helemaal niet met elkaar te synchroniseren. Sterker nog, de threads van de verschillende applicaties van 1 user hoeven al niet met elkaar te synchroniseren.

Wat wel zo is dat in een dergelijke situatie zoveel threads zwaar contraproductief werkt; met name de overhead van context switches zal zeer zwaar wegen.

Als je echter de rest van het topic gelezen hebt dan heb je waarschijnlijk gezien dat de exact zelfde situatie ook al bij 'gewone' serverside applicaties speelt. Als het aantal requesten hoog is, dan hoef je niet voor snelheidswinst meerdere threads te gaan spawnen; de cores worden dan al genoeg bezig gehouden.

Helemaal niet meer expliciet gaan multi-threaden is dan echter ook geen oplossing. Ik werk bijvoorbeeld aan een web applicatie (geen site, maar echt een applicatie) waar ongeveer 40 ~ 60 simultane gebruikers per oct-core (dual quad) bak werken. Aanvankelijk dachten wij ook dat 60 users 8 cores wel genoeg bezig konden houden. Toch komt het geregeld voor dat een gebruiker klaagt over de traagheid van het systeem. In de monitoring history zien we dan dat er 1 core op 100% staat, terwijl de andere 7 cores het relatief rustig hebben.

Het parallel laten uitvoeren van 1 request levert hier dus zeker wel een groot voordeel op. De complicerende factor is dat het adaptief moet gebeuren; het aantal threads dat je optimaal wilt gebruiken is een functie van o.a. het totaal aantal cores wat je hebt en hun huidige belasting. Bij het parallel uitvoeren van SQL queries houden systemen als MS SQL Server en Oracle hier expliciet rekening mee.

Nu ga je natuurlijk zeggen dat een systeem als waar ik aan werk niet typisch is, en dat klopt (hoewel je dergelijke apps wel steeds meer ziet). Maar het exact zelfde verhaal geldt ook voor 'gewone' applicaties in een TS omgeving. Als het relatief rustig is op een TS dan zal een individuele user ook verwachten dat haar applicatie een stuk sneller dingen kan doen vergeleken met de situatie dat 49 andere gebruikers ook aan het werk zijn.

Het zou zeker een meerwaarde hebben als het OS en/of de runtime van het platform op de een of andere manier meer support zouden kunnen bieden voor het bepalen van de optimale opdeling in threads voor 1 applicatie of 1 request.

Dus eigenlijk zie ik op lange termijn (zeg 20 jaar) de fat clients bij de eindgebruiker verdwijnen. Bij de particulier thuis zal het misschien wat langer duren, maar de verwachting is wel dat je in de toekomst gewoon processor power als een abonnement in koopt.

Tanenbaum zei het al enkele jaren geleden; de IT beweegt zich in cycles. Eerst hadden onderzoeker 1 computer voor zichzelf, toen kwamen er mainframes die een hele groep users bediende, toen kwam de personal computer weer terug, en nu komt het mainframe idee weer terug.

[ Voor 8% gewijzigd door flowerp op 03-08-2007 21:49 ]

[LauPro]

flowerp schreef op vrijdag 03 augustus 2007 @ 21:47:
[...]
Hier ben ik het op zich zeker mee eens. Hoewel je laatste opmerking de plank misschien misslaat (of je gebruikt simpelweg het verkeerder woord); bij 50 users hoeven de threads van de verschillende users helemaal niet met elkaar te synchroniseren. Sterker nog, de threads van de verschillende applicaties van 1 user hoeven al niet met elkaar te synchroniseren.

Wat ik bedoel met synchroniseren zijn de threads binnen een applicatie onderling ten op zichte van minder deftig 'gethreadde' applicaties. Er zit een overheid aan het gebruik van threads, stel dat die 20% is en je 40% performancewinst hebt, bij 50 gebruikers ziet dat plaatje er dan heel anders uit. Effectief verbruik je over de hele CPU gezien meer tijd aan syncen dan wanneer er minder actieve threads zijn.

Als je echter de rest van het topic gelezen hebt dan heb je waarschijnlijk gezien dat de exact zelfde situatie ook al bij 'gewone' serverside applicaties speelt. Als het aantal requesten hoog is, dan hoef je niet voor snelheidswinst meerdere threads te gaan spawnen; de cores worden dan al genoeg bezig gehouden.

Dat is exact wat ik bedoel en probeer te zeggen. Op een gegeven moment heeft theaden geen nut meer en zorgt het voor alleen maar overhead. Wanneer dat moment is ligt aan de arch/cpu.

Toch komt het geregeld voor dat een gebruiker klaagt over de traagheid van het systeem. In de monitoring history zien we dan dat er 1 core op 100% staat, terwijl de andere 7 cores het relatief rustig hebben.

Ik ben zeer benieuwd wat voor een type taak dat dan is. Als het het wachten op een DB is, dan kan je er weinig aan doen (je kan maar 1 query tegelijk doen in principe). Als het het wachten is op een complexe berekening is dan valt er misschien met MT iets te regelen. Daarnaast vraag ik me af of het wel wenselijk is dat 1 user alle 8 cores tot zijn beschikking krijgt. Ik vind het eigenlijk wel een mooie oplossing dat een user maximaal 1 core kan gebruiken, dan weet je zeker dat niet 1 request het hele systeem op vreet.

Nu ga je natuurlijk zeggen dat een systeem als waar ik aan werk niet typisch is, en dat klopt (hoewel je dergelijke apps wel steeds meer ziet). Maar het exact zelfde verhaal geldt ook voor 'gewone' applicaties in een TS omgeving. Als het relatief rustig is op een TS dan zal een individuele user ook verwachten dat haar applicatie een stuk sneller dingen kan doen vergeleken met de situatie dat 49 andere gebruikers ook aan het werk zijn.

Ik weet niet om wat voor een applicatie het precies gaat. Maar mijn ervaring is dat als er echte langdurige berekeningen uitgevoerd moeten worden dit vaak door middel van een job buiten werktijden wordt gedaan of on the fly maar dan wel een statusbalk en terugkoppeling naar de gebruikers. Misschien valt daar al wat ergenis mee weg te nemen.

Het zou zeker een meerwaarde hebben als het OS en/of de runtime van het platform op de een of andere manier meer support zouden kunnen bieden voor het bepalen van de optimale opdeling in threads voor 1 applicatie of 1 request.

Laten we dan daar op concentreren ipv allemaal work-a-rounds in de software te bakken.

Tanenbaum zei het al enkele jaren geleden; de IT beweegt zich in cycles. Eerst hadden onderzoeker 1 computer voor zichzelf, toen kwamen er mainframes die een hele groep users bediende, toen kwam de personal computer weer terug, en nu komt het mainframe idee weer terug.

Als je ongeveer weet dat dat de cyclus gaat worden, dan kan je je daar toch gewoon beter rekening mee houden? Ik zie echt serieus de theadmerger functie ontstaan voor applicaties die teveel threads hebben. Het is gewoon waanzin om een allround desktop (of web-) applicatie te maken die 60 threads weg schiet. Tenzij je het hebt over bijvoorbeeld een enterprise omgeving waar een webserver, helemaal geöptimaliseerd, met 64 cores 60 threads maakt om alle requests af te handelen en de rest voor het systeem gebruikt. Maar voor desktop zie ik het niet gebeuren voorlopig.

[.oisyn]

flowerp schreef op vrijdag 03 augustus 2007 @ 20:43:
dingen als 'geen enkel mainstream software pakket is zo complex dat het OO echt nodig heeft, alleen voor hele grote systemen is zoiets nodig'

't Is natuurlijk wel zo dat veel apps prima werken in een single-threaded environment. Datzelfde soort apps dat maar 99.9999% van de tijd staat de idlen voornamelijk .

Bij ons is ook een complete ommezwaai bezig. Onze vorige 360 game (Tomb Raider: Legend) was nog singlethreaded, maar nu we wat meer feeling hebben met het platform en er meer uit willen halen, en nu we ook voor de PS3 ontwikkelen, is multicore development een must. Belangrijke delen van de codebase wordt "ge-job-ified" zodat subtaken parallel kunnen worden uitgevoerd.

LauPro schreef op vrijdag 03 augustus 2007 @ 20:54:
Dan begrijp ik het inderdaad misschien niet. Maar laten we wel wezen dat moderne talen stimuleren en alle tools hebben om MT te programmeren. Ik zie dan dus ook totaal niet in hoe iemand die nu met C++ begint bijvoorbeeld enkel sequentieel kan programmeren. MT is gewoon iets waar je op een gegeven moment tegen aan loopt en dan een oplossing voor gaat vinden (threads), ookal heb je single core. Bij .NET Java wordt je op dezelfde mannier al bijna gedwongen om met threads te werken. En een voorbeeld van Perl 6 met het pure keyword ligt ook op tafel dat vanuit het platform optimalisaties worden uitgevoerd.

Threads an sich hebben maar weinig met het paralleliseren van code te maken. Leuk dat veel apps nu al threads gebruiken, maar dat is voornamelijk om de UI responsive te houden terwijl een taak op de achtergrond draait, of om blocking IO heen te werken. Heeft maar weinig te maken met echt parallel processing, waar een heel ander design-paradigima achter schuilt.

Leg mij nu eens het nut uit van een applicatie die 60 threads zou spawnen?

Dat is niet uit te leggen. Het gaat er ook niet om dat een applicatie 60 threads spawnt. Het gaat erom dat de applicatie een tijdrovende taak over verschillende cores opsplitst.

Als nu de mentaliteit ontstaat dat threads heel goedkoop zijn, en we zitten straks met een desktop waar 10-15 applicaties open staan met elk 60 threads dan zijn we terug bij af met onze performance.

Dikke onzin. Je spawnt alleen 60 threads als je 60 cores hebt, en hey, is het dan niet hetzelfde als een singlethreaded app op een single code platform? Bovendien zijn threads voornamelijk duur in system resources zoals memory, niet zozeer in executietijd (want of je code nou runt in 1 threads of in 5 threads, het blijft gewoon code dat runt op je CPU)

[LauPro]

.oisyn schreef op zaterdag 04 augustus 2007 @ 03:05:
Threads an sich hebben maar weinig met het paralleliseren van code te maken. Leuk dat veel apps nu al threads gebruiken, maar dat is voornamelijk om de UI responsive te houden terwijl een taak op de achtergrond draait, of om blocking IO heen te werken. Heeft maar weinig te maken met echt parallel processing, waar een heel ander design-paradigima achter schuilt.

Daar heb je helemaal gelijk in, maar dan zeg ik: wanneer processing echt zo zwaar is dan heb je het over een hele beperkte markt. Natuurlijk zal dit in een game engine noodzakelijk zijn, netzoals dat in een platform/toolkit noodzakelijk is.

Dat is niet uit te leggen. Het gaat er ook niet om dat een applicatie 60 threads spawnt. Het gaat erom dat de applicatie een tijdrovende taak over verschillende cores opsplitst.

Ik denk dat bij veel 'tijdrovende taken' die er nu zijn het niet zozeer aan de applicatie of het lokale systeem ligt, maar aan externe systemen.

Dikke onzin. Je spawnt alleen 60 threads als je 60 cores hebt, en hey, is het dan niet hetzelfde als een singlethreaded app op een single code platform? Bovendien zijn threads voornamelijk duur in system resources zoals memory, niet zozeer in executietijd (want of je code nou runt in 1 threads of in 5 threads, het blijft gewoon code dat runt op je CPU)

Dat is wat ik bedoel met parameters, afhankelijk van het systeem het aantal threads bepalen. Mocht er een complexe berekening zijn en je hebt 8 cores, en de user heeft toestemming om die gebruiken dan zou je daarbij alle 8 cores kunnen gebruiken. Maar dit zijn geen dingen waar je zomaar standaard vanuit mag gaan imo. Zeker juist met het oog op de toekomst. Overigens kost ook memory dat extra moet worden aangesproken CPU-tijd.

[flowerp]

LauPro schreef op zaterdag 04 augustus 2007 @ 15:46:
[...]
Daar heb je helemaal gelijk in, maar dan zeg ik: wanneer processing echt zo zwaar is dan heb je het over een hele beperkte markt.

Bedoel je nou te zeggen dat er een beperkte markt is voor extra processing power?

Als dat zo was, waarom is er dan überhaupt desktop en notebook hardware? Als performance er niet toe zou doen, waarom zijn er dan niet alleen maar notebook CPU's?

Ik snap best dat jij van mening bent dat eigenlijk niemand meer dan pak 'm beet een PIII 500Mhz nodig zou hebben. Met heel secuur en optimaliserend programmeren zou dat voor veel gevallen nog wel waar zijn ook, maar voor net zo veel andere gevallen weer compleet niet. Mensen willen en eisen steeds meer. Daarnaast verwachten ze ook dat van software steeds sneller een nieuwe release uit komt, die meer en meer kan.

Volgens jouw redenatie ("bijna niemand heeft meer processing power nodig"), zouden Intel, AMD en consorten net zo goed kunnen stoppen met het designen van nieuwe architecturen, en zich enkel en alleen richten op het fabriceren van de bestaande modellen. Als dan de hele wereld zo'n CPU heeft, dan kunnen ze zich zelf zo ongeveer beperken tot het produceren van wat vervangings CPU's als er ooit eens eentje kapot gaat.

Tuurlijk werkt dat niet zo. De ontwikkeling gaat door en het einde is nog lang niet in zicht. Het verschil is alleen dat de CLOCK SNELHEID binnen afzienbare tijd (met de huidige inzichten) niet/amper meer omhoog zal gaan. Je ziet nu al een beetje een soort cycle; single-cores gaan tot +- 3.8Ghz. Dual-core komt uit, begint op lage clock en klimt langzaam naar de +-3Ghz. Quad-core komt uit, begin op lagere clock en klimt ook langzaam naar de +3Ghz, etc.

Wellicht dat met een geheel andere aanpak er over een tig aantal jaren weer een echte of effectieve stijging van de clock snelheid mogelijk is. Hier wordt ongetwijfeld onderzoek naar gedaan, maar of er iets bruikbaars gevonden gaat worden is nu natuurlijk nog niet zeker.

Voorlopig zal meer performance dus voornamelijk betekenen meer cores. Zoals Herb Sutter al schreef; de 'free lunch' is daarmee over. Je kunt niet meer meeliften op een automatische performance gain voor je sequentiële code, maar moet het actief gaan parallelliseren.

Doe je dat niet, dan zeg je eigenlijk tegen je gebruikers: 3Ghz is genoeg voor jou. Voor altijd... Of te wel, een variant op het oude: "640Kb ought to be enough". Voor de gebruiker zal jouw app op de hedendaagse CPU (bv een dual core) exact even snel draaien als op een CPU van over 7 jaar (bv een 32-core). Hoeveel hardware jouw gebruiker er ook tegen aan gooit, die app van jou zal nooit sneller gaan.

Volgens mij is dat niet helemaal in overeenstemming met de verwachting die gebruikers hebben.

[LauPro]

flowerp schreef op zondag 05 augustus 2007 @ 01:41:
Bedoel je nou te zeggen dat er een beperkte markt is voor extra processing power?

Ja, ik zie niet in welke desktopapplicaties nu exorbitant veel processing power nodig hebben. En zeker in bedrijfsomgevingen gaat alles nu al vaak gecentraliseerd als het gaat om complexe processing (databases, report generators etc).

Als dat zo was, waarom is er dan überhaupt desktop en notebook hardware? Als performance er niet toe zou doen, waarom zijn er dan niet alleen maar notebook CPU's?

Met 'notebook CPU's' bedoel je dan neem ik aan de energie zuinige versie van de reguliere CPU's. Deze zijn ontwikkeld om zo lang mogelijk met een accu operationeel te kunnen zijn met een bepaalde performance, maar zeker bij Centrino bijvoorbeeld heeft men performance niet als een van de belangrijkste punten als basis gehad.

Ik snap best dat jij van mening bent dat eigenlijk niemand meer dan pak 'm beet een PIII 500Mhz nodig zou hebben. Met heel secuur en optimaliserend programmeren zou dat voor veel gevallen nog wel waar zijn ook, maar voor net zo veel andere gevallen weer compleet niet. Mensen willen en eisen steeds meer. Daarnaast verwachten ze ook dat van software steeds sneller een nieuwe release uit komt, die meer en meer kan.

Misschien dat men qua processing speed nu gemiddeld wel die PIII nodig zou hebben, echter bij de pieken heeft men meer capaciteit nodig. Als ik er even vanuit ga dat alle multi-core CPU's die nu uitgebracht worden sneller zijn de de laatste reguliere single core dan zit daar alleen al snelheidswinst in. Doordat er hierdoor per core minder threads zijn is er per definitie al een performancewinst. En met een beetje slim power management kan je een aantal cores uitschakelen of terugklokken op tijden dat er minder processing power nodig is (waardoor je bij dalmomenten misschien de performance van een PIII hebt).

Volgens jouw redenatie ("bijna niemand heeft meer processing power nodig"), zouden Intel, AMD en consorten net zo goed kunnen stoppen met het designen van nieuwe architecturen, en zich enkel en alleen richten op het fabriceren van de bestaande modellen. Als dan de hele wereld zo'n CPU heeft, dan kunnen ze zich zelf zo ongeveer beperken tot het produceren van wat vervangings CPU's als er ooit eens eentje kapot gaat.

Voor een deel is het commercie, voor een ander deel de constante drang naar vernieuwing (en dat is ook noodzakelijk). Echter op een gegeven moment zal de ontwikkeling zeker 'stallen' als het gaat om mainstream toepassingen. Om even een simpel voorbeeld te geven, stel dat je een record op wil slaan in een database, en dat is een record van 64KB. Dan zal dat misschien enkele miliseconden schelen als je de mainstream tegen de top van nu zou uitzetten. Ik zie niet in hoe dat met een CPU die bwvs 64 cores heeft sneller gaat kunnen, of in ieder geval merkbaar sneller.

Leuk detail is dat in Vista bijvoorbeeld dialogen bij het tonen worden vertraagd (fade) zodat de gebruiker het beter begrijpt. Dus uiteindelijk blijf je op dat punt toch op de gebruiker wachten. Als het gaat om displays, het menselijk oog kan maar een bepaalde resolutie onderscheiden. Dus ook daar zit een limiet aan.

Tuurlijk werkt dat niet zo. De ontwikkeling gaat door en het einde is nog lang niet in zicht. Het verschil is alleen dat de CLOCK SNELHEID binnen afzienbare tijd (met de huidige inzichten) niet/amper meer omhoog zal gaan. Je ziet nu al een beetje een soort cycle; single-cores gaan tot +- 3.8Ghz. Dual-core komt uit, begint op lage clock en klimt langzaam naar de +-3Ghz. Quad-core komt uit, begin op lagere clock en klimt ook langzaam naar de +3Ghz, etc.

Die 'lagere clock' zou ik liever willen typeren als een 'mainstream clock'. Want de topmodellen (3.8 Ghz) worden voor zover ik weet relatief weinig verkocht en zijn voor de bedrijven meer paradepaardjes om klanten te binden. Op een gegeven moment kan men (met de juiste architectuur) heel schaalbaar cores toevoegen verwacht ik, zonder dat men direct de clocksnelheid moet verlagen ivm temperaturen oid. Dus ja, de ontwikkeling zal door gaan.

Wellicht dat met een geheel andere aanpak er over een tig aantal jaren weer een echte of effectieve stijging van de clock snelheid mogelijk is. Hier wordt ongetwijfeld onderzoek naar gedaan, maar of er iets bruikbaars gevonden gaat worden is nu natuurlijk nog niet zeker.

Voorlopig zal meer performance dus voornamelijk betekenen meer cores. Zoals Herb Sutter al schreef; de 'free lunch' is daarmee over. Je kunt niet meer meeliften op een automatische performance gain voor je sequentiële code, maar moet het actief gaan parallelliseren.

Nogmaals zou ik graag wat praktijkvoorbeelden willen zien. Als het gaat om databases, game(s) (engines), toolkits/platforms geef ik je gelijk, maar dit is een hele beperkte markt voor ontwikkelaars. Noem eens een concreet voorbeeld van een desktopapplicatie die nu dermate lang duurt en dat met paralleliseren zou kunnen worden versneld, ik noem er alvast een paar:
• Defragmenteren, formatteren, partitie resizen: I/O issue, zou je RAID of een HDD met meerdere koppen moeten hebben.
• DVD branden: ook I/O issue, zou je brander met meerdere koppen moeten hebben, of in 1 keer dubbelzijdig.
• Printen: Ook I/O issue, misschien dat converteren vanuit applicatie naar metaformaat voor printer versneld kan worden maar veelal blijft de latentie van het netwerk/printserver de bottleneck.
• Downloaden: Idem.

Dus nogmaals, voor de meeste applicaties zie ik niet in dat 'extreem toepassen van threads' nuttig is, ik zie het dan als overhead.

Doe je dat niet, dan zeg je eigenlijk tegen je gebruikers: 3Ghz is genoeg voor jou. Voor altijd... Of te wel, een variant op het oude: "640Kb ought to be enough". Voor de gebruiker zal jouw app op de hedendaagse CPU (bv een dual core) exact even snel draaien als op een CPU van over 7 jaar (bv een 32-core). Hoeveel hardware jouw gebruiker er ook tegen aan gooit, die app van jou zal nooit sneller gaan.

Het sneller maken van applicaties ligt nu meestal aan het extern geheugen (harde schijf) dan aan de CPU. Je zal zelf wel beamen dat met een schijf van 10 jaar geleden met de nieuwste processor het voor geen meter op schiet. Ik zie dus eerder performancewinst voor een desktop in storage, bijvoorbeeld een snelle DDR-cache waar programmacode in wordt opgeslagen en browsercache. Dat zal pas een revolutie zijn.

[Alarmnummer]

flowerp schreef op vrijdag 03 augustus 2007 @ 13:52:
[...]


Is dat nog een beetje gelukt?

Jazekers. Er komt wellicht een presentatie over op JFall. En een podcast met Jonas Bonair komt binnenkort op de site van het bedrijf waar ik voor werk: http://www.xebia.com

Ik ben deze week tot de ontdekking gekomen dat Mule een aantal dingen precies hetzelfde doet: automatisch dispatching op event type, interpretatie van return values etc. Ik ga daarom kijken hoe goed de process functionaliteit van Prometheus valt te combineren met Mule.

http://mule.codehaus.org/display/MULE/Writing+Components
http://prometheus.codehaus.org/guide-processors.html

Misschien moet je bij ons komen werken We hebben hier zelfs nog 2 andere vrouwen die als hardcore Java developer werken, 1'tje met een WO informatica diploma en de andere met een WO AI diploma
[/offtopic]

Een vrouw vind ik voldoende..... voor nu

[ Voor 39% gewijzigd door Alarmnummer op 05-08-2007 15:42 ]

[Ontspannen]

Wat betekend dit paralel programmeren nu voor het schrijven van code (visual studio)?

Kort door de bocht: opzich begrijp ik dat je code sturtuur zodanig moet zijn dat de te verwerken taak opgedeeld wordt.

Moet ik nu, bijv., een structuur maken dat threads aanmaakt en vervolgens de code voor de verwerking ( dus er is dan een transparatie mbt hoe het prog. hardwarematig wordt uitgevoerd). Of moet ik code maken dat specifiek de processoren aanspreekt en daarna de code voor verwerking.

[MBV]

[disclaimer]nog nooit echt zoiets gemaakt, maar zo zou ik het doen:[/disclaimer]
Je moet 1 klasse verantwoordelijk maken voor het verwerken van die dingen, bijv via het Chain of responsibility design pattern. Die klasse heeft een aantal threads waar hij taken aan toe kan wijzen (afhankelijk van het aantal processors). Hij kiest een thread uit voor de taak, laat hem de taak verwerken, en zorg je weer dat de gegevens terug komen. Hoe je die mapping op threads doet is afhankelijk van het soort taak.

[Ontspannen]

off topic
@ alarmnummer:
http://prometheus.codehaus.org/guide-repeater.html

Eerste voorbeeld:
Repeatable task new RepeatableRunnable(new SomeRunnable();

equivalentieteken vergeten?

Met datgene wat je daar aan het ontwikkelen bent, kan je paralelliseren in Java ?

[Alarmnummer]

Ontspannen schreef op dinsdag 14 augustus 2007 @ 11:46:
off topic
@ alarmnummer:
http://prometheus.codehaus.org/guide-repeater.html

Eerste voorbeeld:
Repeatable task new RepeatableRunnable(new SomeRunnable();

equivalentieteken vergeten?

Jup. documentatie is zeker voor verbetering vatbaar

Met datgene wat je daar aan het ontwikkelen bent, kan je paralelliseren in Java ?

Jup..

Ik heb mbv Prometheus een prototype high volume data processing applicatie in elkaar gezet (dus parallel draaien van taken, pipelining etc) en mbv Terracotta wordt het geclusterd. De uiteindelijk berekeningen die werden uitgevoerd waren pi en fibonacci (lekker load genereren):

code:

public class PiProcess {

    public final static Logger log = LogManager.getLogger(PiProcess.class);

    public void receive(Task task) {
        task.setOutPi(pi(task.getInPi()));
        log.info(task);
    }

    public static double pi(long i) {
        double total = 0.0;
        for (long j = 1; j <= i; j += 4)
            total += 1.0 / j - 1.0 / (j + 2);
        return 4 * total;
    }
}

Voorbeeld process (zoals je kunt zien is er geen threading, blocking etc).

Maar er zitten allerlei bouwstenen in Prometheus die in sommige gevallen erg handig kunnen zijn bij het opzetten van multithreaded systemen. Idee is om threading wel zo veel mogelijk uit componenten te trekken zodat alleen nog een klein aantal specialistische componenten er van af weten.

[ Voor 24% gewijzigd door Alarmnummer op 14-08-2007 14:05 ]

[H!GHGuY]

LauPro noemt toch enkele dingen waar ik even op wil reageren:

Je zegt dat synchronisatie de performantie omlaag haalt wat geheel correct is. Als je echter "The free lunch is over" video en bijhorende slides bekijkt, zie je dat er echter een hele andere strategie zit aan te komen. Zoek bijvoorbeeld maar eens op transactional memory, atomic blocks, futures, versioned objects, etc.

Gebruik maken van dergelijke technieken kan de performantie-penalty die je betaalt voor MT zwaar omlaag halen.

Je mag dan gelijk hebben dat veel software een gemiddelde P3 nauwelijks voltrekt. Je vergeet echter dat een computer ondertussen een woonkamer-instrument is geworden. Entertainment (games, video etc) zijn niet meer weg te denken.

Je haalt ook aan dat alles wat I/O gebonden is niet kan versneld worden. Mis. Combineer MT met command queuing bvb. Als een thread staat te wachten op data dan is ie maar geblocked. Dan kan thread 2 (genomen dat ie niet afhankelijk is van de andere thread) lekker verder doen. En moet die thread 2 dan jammer genoeg ook data hebben, laat de harde schijf dan beslissen in welke optimale volgorde hij beide requests kan afhandelen en laat een mogelijke thread 3 dan maar de CPU nog wat entertainen.

Threading wordt heden ten dage net gebruikt OM onder andere I/O niet als blokkerend te ervaren.

Je moet ook dynamisch gaan threads spawnen volgens de effectieve bezetting en niet in het wilde weg 3000 threads spawnen. Bovendien moet je zo programmeren dat de threads mekaar neit voor de voeten lopen. Dit is waar het topic over gaat: Wie optimaliseert zijn software voor multi-core (en hoe).

Dat pakweg open-office slechts een beperkte winst kan halen uit multi-core mag dan voor de hand liggen, maar wil daarom niet zeggen dat het niet nuttig is.
quote: "90% van de tijd zit in 10% van de code"

Kun je die 10% multi-core aware maken en optimaliseren (inclusief I/O optimaliseren e.d.) dan kun je er zeker winst uithalen. Een gebruiker die geen 3s moet wachten eer zijn volledig complex werkblad is doorgerekend omdat hij een 1 heeft veranderd in 1.1 zorgt wel degelijk voor winst.

[LauPro]

H!GHGuY schreef op woensdag 15 augustus 2007 @ 15:43:
Gebruik maken van dergelijke technieken kan de performantie-penalty die je betaalt voor MT zwaar omlaag halen.

Mee eens, er zullen best technieken zijn die ervoor zorgen dat MT applicaties nog beter performen. Neemt niet weg dat dit alleen maar op gaat als het process in beginsel überhaupt wel kan worden MT'ed. En ik denk dat de cases die daarvoor geschikt zijn vrij klein zijn.

Je mag dan gelijk hebben dat veel software een gemiddelde P3 nauwelijks voltrekt. Je vergeet echter dat een computer ondertussen een woonkamer-instrument is geworden. Entertainment (games, video etc) zijn niet meer weg te denken.

Nee oke, maar als je het hebt over de ontwikkeling van games en videocodecs dan is dat naar mijn idee een hele niche markt.

Je haalt ook aan dat alles wat I/O gebonden is niet kan versneld worden. Mis. Combineer MT met command queuing bvb. Als een thread staat te wachten op data dan is ie maar geblocked. Dan kan thread 2 (genomen dat ie niet afhankelijk is van de andere thread) lekker verder doen. En moet die thread 2 dan jammer genoeg ook data hebben, laat de harde schijf dan beslissen in welke optimale volgorde hij beide requests kan afhandelen en laat een mogelijke thread 3 dan maar de CPU nog wat entertainen.

Volgens mij is het al meer dan 2 decennia zo dat op het moment dat process A staat te wachten op I/O dat B dan gewoon verder kan. Dus niets nieuws onder de zon. Waar het om gaat is: stel dat je een file hebt van 6 GB. En voor de bewerking (unrarren) moet het hele bestand langs gelopen worden. Dan denk ik niet dat het mogelijk is om daar een versnelling in te brengen. Je bent namelijk afhankelijk van I/O. En je kan maar 1 blok per keer uitlezen, verwerken en wegschrijven en dat moet sequentieel worden gedaan.

Met command queuing zorg je er voor dat de lees-/schrijfkop van de schijf minder fanatiek heen en weer hoeft te bewegen waardoor de transferate omhoog gaat. Helemaal als je dat combineert met cache (wat bij RAID-controllers vaak het geval is).

Threading wordt heden ten dage net gebruikt OM onder andere I/O niet als blokkerend te ervaren.

Om je programma niet te laten blocken op 1 I/O issue inderdaad.

Je moet ook dynamisch gaan threads spawnen volgens de effectieve bezetting en niet in het wilde weg 3000 threads spawnen. Bovendien moet je zo programmeren dat de threads mekaar neit voor de voeten lopen. Dit is waar het topic over gaat: Wie optimaliseert zijn software voor multi-core (en hoe).

Dat is ook wat ik eerder suggereerde inderdaad, liefst door de kernel gestuurd.

Dat pakweg open-office slechts een beperkte winst kan halen uit multi-core mag dan voor de hand liggen, maar wil daarom niet zeggen dat het niet nuttig is.
quote: "90% van de tijd zit in 10% van de code"

Ik zeg niet dat het voor OOo niet nuttig is, in tegendeel. Maar ik zie gewoon bij veel processen geen noodzaak om te gaat MT'en. Omdat het vaak kortzichting is (1 onderdeel goed geoptimaliseerd maar met alle onderdelen bij elkaar wordt het traag). Daarnaast zijn er nog de argumenten als het gaat om debugging. In dit topic stond een mooi voorbeeld van het uitvoeren van een berekeningen door 2 threads, dat soort constructies zijn een hell om te debuggen.

Kun je die 10% multi-core aware maken en optimaliseren (inclusief I/O optimaliseren e.d.) dan kun je er zeker winst uithalen. Een gebruiker die geen 3s moet wachten eer zijn volledig complex werkblad is doorgerekend omdat hij een 1 heeft veranderd in 1.1 zorgt wel degelijk voor winst.

Volgens mij zijn die berekeningen al gethread in OOo indien het kan.

Het grote punt is dat er nog geen memory is zonder blocking. Dat kan ook eigenlijk niet als je je data consistent wil houden. Als je ergens aan het schrijven bent, dan moet je gewoon een lock plaatsen. Uitlezen daarintegen is nooit een probleem. Dit is gewoon het fundament waarom er imo rond I/O voorlopig niet veel op MT gebied zou kunnen. Het zou pas effectief kunnen zijn als je een harde schijf zou kunnen maken die fysiek 2 koppen heeft (die zijn er al wel maar dan 1 rw en de andere ro). En dat die koppen dan onafhankelijk van elkaar kunnen laten lezen en schrijven. Met daarnaast een stukje syncing dat ze niet op dezelfde plek aan het schrijven zijn.

edit: Wat ik nog wil toevoegen is dat I/O tot op heden (op de desktop) altijd nog de grootste bottleneck is. Dus je kan wel een bewerking met 2 threads doen maar dat zal nooit sneller gaan dat je I/O subsystem aan kan.

[Confusion]

LauPro schreef op woensdag 15 augustus 2007 @ 16:23:
Ik zeg niet dat het voor OOo niet nuttig is, in tegendeel. Maar ik zie gewoon bij veel processen geen noodzaak om te gaat MT'en.

Tjah, er is ook geen noodzaak om uberhaupt een computer te gebruiken. Maar als je door middel van multithreading een applicatie beter kan maken, zij het doordat die sneller is of meer features kan hebben, dan heb je een competatievere applicatie. Wat [i]in jouw ogen[i/] 'noodzaak' is, is geen zinnig bruikbaar criterium.

Omdat het vaak kortzichting is (1 onderdeel goed geoptimaliseerd maar met alle onderdelen bij elkaar wordt het traag).

Natuurlijk, parallellisatie kann maar een eindige hoeveelheid winst bieden en de winst neemt af al naar gelang er meer winst geboekt is, doordat een eindige hoeveelheid van het proces noodzakelijkerwijs sequentieel moet verlopen. Dat is een klassieker van Amdahl. Maar daarbij moet je niet over het hoofd zien welk deel van het proces geparallelliseerd zou kunnen worden, als men zich er toe zou zetten en creatief zou zijn. Jouw voorbeeld van een compressiemethode waarbij je het gehele bestand moet hebben voor je aan decompressie kan beginnen, is natuurlijk een totale braindead benadering van bestandscompressie, als voor een toepassing grote hoeveelheden moeten worden verscheept en de decompressiesnelheid de vertragende factor is (en niet de verplaatsingssnelheid). Dan zal je dus een methode gebruiken waarbij alle data die binnenkomt on the fly gedecomprimeerd kan worden en als dat sneller kan door het te parallelliseren (en als de data sneller binnenkomt dan het gedecomprimeerd kan worden, dan kan dat), dan doe je dat dus.

dat soort constructies zijn een hell om te debuggen.

De tools om dat soort debugging makkelijker te maken zijn er, zullen nog beter worden en zal je ook kunnen leren beheersen. Dat iets moeilijk is, is geen argument voor de stelling dat het een verkeerde weg is, ook al voelt dat gevoelsmatig als de logische conclusie. Daar zit namelijk de verborgen aanname in dat er andere wegen zijn. Als die er niet zijn, zoals velen in dit topic denken, dan heb je straks gewoon geen keus.

[LauPro]

Confusion schreef op woensdag 15 augustus 2007 @ 16:51:
Tjah, er is ook geen noodzaak om uberhaupt een computer te gebruiken. Maar als je door middel van multithreading een applicatie beter kan maken, zij het doordat die sneller is of meer features kan hebben, dan heb je een competatievere applicatie. Wat [i]in jouw ogen[i/] 'noodzaak' is, is geen zinnig bruikbaar criterium.

Met noodzaak bedoel ik dat een applicatie inderdaad sneller wordt. En dat hoeft niet altijd zo te zijn met MT. Maar het vervelende met dit soort discussies is dat het maar in bepaalde gevallen op gaat. Daarom probleer ik steeds voorbeelden te geven in plaats dat we een beetjde de ruimte in praten met theoriën.

Jouw voorbeeld van een compressiemethode waarbij je het gehele bestand moet hebben voor je aan decompressie kan beginnen, is natuurlijk een totale braindead benadering van bestandscompressie, als voor een toepassing grote hoeveelheden moeten worden verscheept en de decompressiesnelheid de vertragende factor is (en niet de verplaatsingssnelheid). Dan zal je dus een methode gebruiken waarbij alle data die binnenkomt on the fly gedecomprimeerd kan worden en als dat sneller kan door het te parallelliseren (en als de data sneller binnenkomt dan het gedecomprimeerd kan worden, dan kan dat), dan doe je dat dus.

Helemaal gelijk, het zou on the fly moeten kunnen. Neemt niet weg dat bij bij decomprimeren veelal het I/O subsystem ipv de CPU de bottleneck is. En daarnaast is bijv. het rar formaat niet erg geschikt voor threading. Dat zou dus betekenen dat er *weer* een nieuw formaat moet komen, op zich wel leuk in theorie maar zijn altijd vervelende dingen in de praktijk.

De tools om dat soort debugging makkelijker te maken zijn er, zullen nog beter worden en zal je ook kunnen leren beheersen. Dat iets moeilijk is, is geen argument voor de stelling dat het een verkeerde weg is, ook al voelt dat gevoelsmatig als de logische conclusie. Daar zit namelijk de verborgen aanname in dat er andere wegen zijn. Als die er niet zijn, zoals velen in dit topic denken, dan heb je straks gewoon geen keus.

Ik ben het je eens dat het niet een heel sterk argument is, maar ook hier zou ik graag weer zeggen kom maar met voorbeelden. En met 'straks gewoon geen keus' is een beetje rigoureus. Er worden nog steeds hele applicaties met ASP 3 of PHP 4 ontwikkeld. Keus zal er altijd blijven en verwacht dat pure non-MT programma's nog zeker wel 3 decennia aanwezig zullen zijn.

[H!GHGuY]

LauPro schreef op woensdag 15 augustus 2007 @ 16:23:
Mee eens, er zullen best technieken zijn die ervoor zorgen dat MT applicaties nog beter performen. Neemt niet weg dat dit alleen maar op gaat als het process in beginsel überhaupt wel kan worden MT'ed. En ik denk dat de cases die daarvoor geschikt zijn vrij klein zijn.

De meeste applicaties draaien op dit moment zowiezo wel al met 2 of meer threads.
Vanaf het moment dat je iets doet wat CPU-intensief is, loont het zeker de moeite om eens te kijken of het (kosten-baten) de moeite loont om extra threads in te zetten. (Reken erop dat toekomstige talen/platformen verbeterde ondersteuning zullen bieden en dat de kost omlaag zal gaan voor gelijke baten) Op dit moment kan die kosten-baten voor het gros van de applicaties wel eens tegenvallen; Juist.

Nee oke, maar als je het hebt over de ontwikkeling van games en videocodecs dan is dat naar mijn idee een hele niche markt.

Ik heb het niet over de ontwikkeling ervan maar over het gebruik. Dat zowat elke PC in de huiskamer ingezet wordt voor games en/of multimedia is een feit. Daar moet ik je waarschijnlijk niet van overtuigen. Dat net die programma's er baat van kunnen hebben waarschijnlijk ook niet.

Dat een minderheid van de developers daarmee bezig is is natuurlijk wel een feit.

Volgens mij is het al meer dan 2 decennia zo dat op het moment dat process A staat te wachten op I/O dat B dan gewoon verder kan. Dus niets nieuws onder de zon. Waar het om gaat is: stel dat je een file hebt van 6 GB. En voor de bewerking (unrarren) moet het hele bestand langs gelopen worden. Dan denk ik niet dat het mogelijk is om daar een versnelling in te brengen. Je bent namelijk afhankelijk van I/O. En je kan maar 1 blok per keer uitlezen, verwerken en wegschrijven en dat moet sequentieel worden gedaan.

Sure. Maar de storage markt staat ook niet stil (zij het dat ze wel iets trager vooruit lijkt te gaan).
Een goed gedefragmenteerde schijf kan gerust wel wat throughput leveren (met goeie caching) voor een toepassing als dit. De komst van flash-geheugen kan gerust ook een versnelling geven.
(bvb door flash-chips te verdelen in banken van chips en logica toevoegen die zowel voor intelligente prefetching zorgt als voor balancing over alle banken)

Dat is ook wat ik eerder suggereerde inderdaad, liefst door de kernel gestuurd.

Behalve het aanbieden van primitieven (zoals we nu mutexen, semaphoren, threads e.d. kennen) voor MT denk ik niet dat je veel kernel support nodig hebt. Een message pump is bvb niet echt een kernel aangelegenheid hoewel die wel behoorlijk goed te threaden is (producer-consumer).

Ik zeg niet dat het voor OOo niet nuttig is, in tegendeel. Maar ik zie gewoon bij veel processen geen noodzaak om te gaat MT'en. Omdat het vaak kortzichting is (1 onderdeel goed geoptimaliseerd maar met alle onderdelen bij elkaar wordt het traag).

Zie mijn stukje over kosten-baten.

Daarnaast zijn er nog de argumenten als het gaat om debugging. In dit topic stond een mooi voorbeeld van het uitvoeren van een berekeningen door 2 threads, dat soort constructies zijn een hell om te debuggen.

Ik werk dagelijks in embedded software met meer dan 50 threads per subsystem waarbij dan nog eens tot 5 van die subsystemen samengevoegd worden tot 1 groot geheel dat synchroon moet lopen. Ik kan je garanderen dat je met de juiste tools het debuggen behoorlijke wat aangenamer wordt.
Ik heb ook nog dagen verspild aan het zoeken en reproduceren van deadlocks die sporadisch optreden. Goed gedesignede threading (ik zeg daarmee niet dat ons systeem goed (gedesigned) is ) en een deftig logging systeem kunnen deadlocks minimaliseren en zorgen dat je race-condities en dergelijke behoorlijk snel kan opsporen.

Het grote punt is dat er nog geen memory is zonder blocking. Dat kan ook eigenlijk niet als je je data consistent wil houden. Als je ergens aan het schrijven bent, dan moet je gewoon een lock plaatsen. Uitlezen daarintegen is nooit een probleem. Dit is gewoon het fundament waarom er imo rond I/O voorlopig niet veel op MT gebied zou kunnen. Het zou pas effectief kunnen zijn als je een harde schijf zou kunnen maken die fysiek 2 koppen heeft (die zijn er al wel maar dan 1 rw en de andere ro). En dat die koppen dan onafhankelijk van elkaar kunnen laten lezen en schrijven. Met daarnaast een stukje syncing dat ze niet op dezelfde plek aan het schrijven zijn.

Dat is nu net wat transactional memory doet. Een vorm van optimistic locking op geheugen.
Lees er zeker ook eens de wiki op na aangezien het wel meer is dan dat.

Wat ik nog wil toevoegen is dat I/O tot op heden (op de desktop) altijd nog de grootste bottleneck is. Dus je kan wel een bewerking met 2 threads doen maar dat zal nooit sneller gaan dat je I/O subsystem aan kan.

Juist maar daar hebben we jaren geleden al caching voor uitgevonden. Een hedendaagse PC bezit al snel 1-2GB aan RAM. Net de applicaties die datasets (al is dit een game world of een video) in het geheugen kunnen stoppen kunnen profijt hebben van multi-threading.

[LauPro]

H!GHGuY schreef op woensdag 15 augustus 2007 @ 18:19:
De meeste applicaties draaien op dit moment zowiezo wel al met 2 of meer threads.
Vanaf het moment dat je iets doet wat CPU-intensief is, loont het zeker de moeite om eens te kijken of het (kosten-baten) de moeite loont om extra threads in te zetten. (Reken erop dat toekomstige talen/platformen verbeterde ondersteuning zullen bieden en dat de kost omlaag zal gaan voor gelijke baten) Op dit moment kan die kosten-baten voor het gros van de applicaties wel eens tegenvallen; Juist.

Dat is ook al iets wat ik heb aangekaart. Veel optimalisaties zullen gebeuren op platform niveau en niet op applicatieniveau. Daarnaast spelen de toolkits een grote rol.

Ik heb het niet over de ontwikkeling ervan maar over het gebruik. Dat zowat elke PC in de huiskamer ingezet wordt voor games en/of multimedia is een feit. Daar moet ik je waarschijnlijk niet van overtuigen. Dat net die programma's er baat van kunnen hebben waarschijnlijk ook niet.

Je kan het leuk verpakken maar waar gaat het om, de twee kernpunten heb ik in mijn vorige posts uiteen gezet: gaming engines en video codecs. Een mediaplayer (of wat multimedia anders is) is niets anders dan een jasje richting de codec API. En verder zitten alle intensieve bewerkingen rond de codecs (opnemen, transcoden, afspelen etc). Natuurlijk wordt een PC intensiever gebruikt, maar daar krijgen we dan ook de CPU's met meerdere cores voor terug om al die applicaties tegelijk te laten draaien .

Dat een minderheid van de developers daarmee bezig is is natuurlijk wel een feit.

Geeft eigenlijk al aan dat vrij weinig developers rekening hoeven te houden met MT.

Sure. Maar de storage markt staat ook niet stil (zij het dat ze wel iets trager vooruit lijkt te gaan).
Een goed gedefragmenteerde schijf kan gerust wel wat throughput leveren (met goeie caching) voor een toepassing als dit. De komst van flash-geheugen kan gerust ook een versnelling geven.
(bvb door flash-chips te verdelen in banken van chips en logica toevoegen die zowel voor intelligente prefetching zorgt als voor balancing over alle banken).

Inderdaad allemaal leuke technologie maar het heeft allemaal niets te maken met multithreading in applicaties.

Behalve het aanbieden van primitieven (zoals we nu mutexen, semaphoren, threads e.d. kennen) voor MT denk ik niet dat je veel kernel support nodig hebt. Een message pump is bvb niet echt een kernel aangelegenheid hoewel die wel behoorlijk goed te threaden is (producer-consumer).

Imo is het aan de kernel om te bepalen hoe rijkelijk een applicatie met threads om mag gaan.

Zie mijn stukje over kosten-baten.

Beetje open deur, ik denk dat ik weer kan refereren naar mijn stukje . Het is altijd een kwestie van kosten/baten natuurlijk.

Ik werk dagelijks in embedded software met meer dan 50 threads per subsystem waarbij dan nog eens tot 5 van die subsystemen samengevoegd worden tot 1 groot geheel dat synchroon moet lopen. Ik kan je garanderen dat je met de juiste tools het debuggen behoorlijke wat aangenamer wordt.
Ik heb ook nog dagen verspild aan het zoeken en reproduceren van deadlocks die sporadisch optreden. Goed gedesignede threading (ik zeg daarmee niet dat ons systeem goed (gedesigned) is ) en een deftig logging systeem kunnen deadlocks minimaliseren en zorgen dat je race-condities en dergelijke behoorlijk snel kan opsporen.

Dit is dus wat ik bedoel met debugging hell. Het blijft imo gewoon inherent aan MT dat het lastig te debuggen is - daar is verder niets verkeerd mee maar het is een feit. Bij MT lopen er namelijk meerdere processen/threads tegelijk (als je een race condition enigzins wilt debuggen/simuleren) en de mens is gemaakt om zich op 1 ding goed te focussen (verder geen clichés hierover graag). Daar botst het al, dus je moet eigenlijk zo'n applicatie met meerdere personen debuggen wat ook weer complicaties geeft. Met I/O subsystem bedoelde ik overigens bijvoorbeeld een SATA controller met harde schijf. Niet zozeer CPU's oid.

Dat is nu net wat transactional memory doet. Een vorm van optimistic locking op geheugen.
Lees er zeker ook eens de wiki op na aangezien het wel meer is dan dat.

Ik weet wat transactional memory doet maar ook transactional memory kan je gebruiken bij non-threaded applicaties. Ik zie het dus niet als een voordeel direct gekoppeld aan threading.

Het hele 'free lunch is over' verhaal komt er op neer dat we voor de nieuwe generaties applicaties een aantal nieuwe tools moeten gebruiken. En daar is het optimaliseren voor MT er een van.

Juist maar daar hebben we jaren geleden al caching voor uitgevonden. Een hedendaagse PC bezit al snel 1-2GB aan RAM. Net de applicaties die datasets (al is dit een game world of een video) in het geheugen kunnen stoppen kunnen profijt hebben van multi-threading.

Ook bij caching heb je te maken met locking. Het is puur dat je een relatief traag geheugen vervangt door een tijdelijk snel geheugen - wat ook weer los van MT staat.

[Alarmnummer]

LauPro schreef op woensdag 15 augustus 2007 @ 16:23:
Volgens mij is het al meer dan 2 decennia zo dat op het moment dat process A staat te wachten op I/O dat B dan gewoon verder kan. Dus niets nieuws onder de zon. Waar het om gaat is: stel dat je een file hebt van 6 GB. En voor de bewerking (unrarren) moet het hele bestand langs gelopen worden. Dan denk ik niet dat het mogelijk is om daar een versnelling in te brengen. Je bent namelijk afhankelijk van I/O. En je kan maar 1 blok per keer uitlezen, verwerken en wegschrijven en dat moet sequentieel worden gedaan.

Op het moment dat cpu en io in verhouding met elkaar staan (dus niet dat iets io bound is) dan kun je mogelijk een performance winst halen door te multithreaden: als een process bezig io te doen (lees blocken) kan het andere process de cpu gebruiken. Uiteindelijk zal een van de resources een bottleneck gaan vormen, maar de kans is aanwezig dat het beter performed dan een single threaded oplossing.

En mijn indruk is dat de meeste developers actief zijn binnen serverside systemen en daar gaat multithreading steeds belangrijker worden.

[ Voor 6% gewijzigd door Alarmnummer op 15-08-2007 20:58 ]

[LauPro]

Alarmnummer schreef op woensdag 15 augustus 2007 @ 20:55:
Op het moment dat cpu en io in verhouding met elkaar staan[..]

Dit is voorlopig nog niet het geval lijkt me dus dit is een utopie voorlopig.

En mijn indruk is dat de meeste developers actief zijn binnen serverside systemen en daar gaat multithreading steeds belangrijker worden.

Weet je zeker dat dat handig is? Want ik kan me voorstellen dat het helemaal niet wenselijk is dat 1 user alle cores kan gebruiken (ivm de performance voor andere users).

(Nogmaals) Ik heb nu bijvoorbeeld een aantal terminal servers met resp. 4 of 8 cores. Komt vaak voor dat 1 gebruiker dan iets aan het doen is waardoor 1 core op 100% staat de stampen, de rest heeft daar dan geen last van. Mocht die applicatie 8 cores gebruiken dan zou dat wel irritant zijn voor de medegebruikers.

[Alarmnummer]

LauPro schreef op woensdag 15 augustus 2007 @ 21:37:
[...]
Dit is voorlopig nog niet het geval lijkt me dus dit is een utopie voorlopig.

Waar baseer je jouw conclusie op? Ik zit regelmatig achter systemen waar er grote hoeveelheden informatie verwerkt moeten worden, en waar io in verhouding staat met cpu.

Weet je zeker dat dat handig is? Want ik kan me voorstellen dat het helemaal niet wenselijk is dat 1 user alle cores kan gebruiken (ivm de performance voor andere users).

Dat weet ik wel zeker.

Gebruikers krijgen geen core. En normale gebruikers zullen ook zeker geen lang durende taken executen. Alleen speciale users (of triggers binnen het systeem) hebben de mogelijkheid om bv batch processen op te starten. En het doel is over het algemeen: probeer het zo snel mogelijk te verwerken. Dit soort systemen zijn trouwens vaak ook niet eens voor het brede publiek toegankelijk.

(Nogmaals) Ik heb nu bijvoorbeeld een aantal terminal servers met resp. 4 of 8 cores. Komt vaak voor dat 1 gebruiker dan iets aan het doen is waardoor 1 core op 100% staat de stampen, de rest heeft daar dan geen last van. Mocht die applicatie 8 cores gebruiken dan zou dat wel irritant zijn voor de medegebruikers.

Je hebt het over een heel ander type systeem. Als ik zo een rond kijk in de vacatures is denk ik wel 70/80% (misschien nog wel meer) serverside georienteerd (dus webapps bouwen die via het internet worden ontsloten). En niet een of andere terminal server.

Ik ken maar weinig mensen die desktop apps bouwen.

[LauPro]

Alarmnummer schreef op woensdag 15 augustus 2007 @ 21:55:
Waar baseer je jouw conclusie op? Ik zit regelmatig achter systemen waar er grote hoeveelheden informatie verwerkt moeten worden, en waar io in verhouding staat met cpu.

Ik dacht dat het al een besloten zaak was dat voor serverside omgevingen het wel degelijk wenselijk was om MT toe te passen. En de vorige post ging nog over multimedia-applicaties op de desktop.

Dat weet ik wel zeker.

Het was eigenlijk een retorische vraag.

Gebruikers krijgen geen core. En normale gebruikers zullen ook zeker geen lang durende taken executen. Alleen speciale users (of triggers binnen het systeem) hebben de mogelijkheid om bv batch processen op te starten. En het doel is over het algemeen: probeer het zo snel mogelijk te verwerken. Dit soort systemen zijn trouwens vaak ook niet eens voor het brede publiek toegankelijk.

Je zal op een manier zodra er meerdere gebruikers op een systeem werken systeemtijd of wat dan ook moeten verdelen. Natuurlijk wil je alles zo snel mogelijk klaar hebben maar sommige acties kosten nu eenmaal tijd. En dat het tijd kost is niet erg maar laat daar andere gebruikers geen last van hebben. Anders wordt het weer noodzakelijk om hier een policy voor te bouwen. Ik weet niet precies hoe het onder de Windows kernel is, maar volgens mij is het op dit moment nog niet mogelijk om per user een maximale 'bandbreedte' van het systeem te laten gebruiken - maargoed ik denk dat dit weer iets te implementatie specifiek is.

Je hebt het over een heel ander type systeem. Als ik zo een rond kijk in de vacatures is denk ik wel 70/80% (misschien nog wel meer) serverside georienteerd (dus webapps bouwen die via het internet worden ontsloten). En niet een of andere terminal server.

Ik ken maar weinig mensen die desktop apps bouwen.

Het topic ging vooralsnog vooral om desktop apps ivm de performance. Zeker omdat het topic eigenlijk gestart is met processoren die speciaal voor de consumentenlijn bedoeld zijn. Voor enterpriseomgevingen is het al een tijdje mogelijk om een 128 core systeem te kopen:

quote: http://www.sun.com/servers/highend/m9000

Features up to 32 or 64 high performance dual core SPARC64 VI processors and up to 2 TB memory

[flowerp]

Alarmnummer schreef op woensdag 15 augustus 2007 @ 21:55:
Ik ken maar weinig mensen die desktop apps bouwen.

Zie ook de openings post van dit artikel. Slechts 22% van de lezers van dit topic concentreerd zich volledig op desktop apps.

[flowerp]

LauPro schreef op woensdag 15 augustus 2007 @ 21:37:
[...]
Weet je zeker dat dat handig is? Want ik kan me voorstellen dat het helemaal niet wenselijk is dat 1 user alle cores kan gebruiken (ivm de performance voor andere users).

Bekijk het eens van de andere kant; 1 user die zeer lang ergens op moet wachten terwijl 7 van je andere cores gewoon niets staan te doen? Is dat geen verspilling van je resources?

[H!GHGuY]

LauPro schreef op woensdag 15 augustus 2007 @ 19:02:
Inderdaad allemaal leuke technologie maar het heeft allemaal niets te maken met multithreading in applicaties.
...
Ook bij caching heb je te maken met locking. Het is puur dat je een relatief traag geheugen vervangt door een tijdelijk snel geheugen - wat ook weer los van MT staat.

Toch wel. Zulke technologie zorgt dat de balans tussen I/O en CPU weer beter in evenwicht komt.

Imo is het aan de kernel om te bepalen hoe rijkelijk een applicatie met threads om mag gaan.

Imo heeft de kernel daar helemaal niets mee te zien. Een kernel moet kernellen en niet de gebruiker/programmeur beperken. Een OS is nog steeds een besturings-systeem. Dat ding moet een tool/basislaag zijn om software op te draaien. Geen beperking waar ik rond moet werken als ik iets wil.

Dat ik een systeem wil met 10000 threads is mijn probleem. Dat mijn software dan misschien niet zo goed verkoopt ook.

Dit is dus wat ik bedoel met debugging hell. Het blijft imo gewoon inherent aan MT dat het lastig te debuggen is - daar is verder niets verkeerd mee maar het is een feit. Bij MT lopen er namelijk meerdere processen/threads tegelijk (als je een race condition enigzins wilt debuggen/simuleren) en de mens is gemaakt om zich op 1 ding goed te focussen (verder geen clichés hierover graag). Daar botst het al, dus je moet eigenlijk zo'n applicatie met meerdere personen debuggen wat ook weer complicaties geeft.

Ik heb er in iedere geval geen zo'n moeite mee om multi-threaded te denken. Zolang je een goed systeem hebt is het in iedere geval behoorlijke eenvoudig. (Elke thread is verantwoordelijk voor iets. De rest van de threads blijven er met hun handen af. Willen ze iets, dan moeten ze maar een message zenden.)

Ik weet wat transactional memory doet maar ook transactional memory kan je gebruiken bij non-threaded applicaties. Ik zie het dus niet als een voordeel direct gekoppeld aan threading.

Het voordeel zit em in de performantie winst tov locking.

[flowerp]

H!GHGuY schreef op donderdag 16 augustus 2007 @ 19:28:
Ik heb er in iedere geval geen zo'n moeite mee om multi-threaded te denken. Zolang je een goed systeem hebt is het in iedere geval behoorlijke eenvoudig. (Elke thread is verantwoordelijk voor iets. De rest van de threads blijven er met hun handen af. Willen ze iets, dan moeten ze maar een message zenden.)

Helemaal mee eens. Als het idee van threads eenmaal goed in je eigen systeem zit dan is het helemaal niet zo gigantisch moeilijk en voelt het juist heel natuurlijk aan dat je verschillende taken op deze manier verdeelt.

Dat is dus eigenlijk ook weer een beetje het argument wat al een aantal keer eerder is genoemd; het is een omslag in gedachtegang, in zekere zin vergelijkbaar met de omslag van gestructureerd naar OO programmeren. Dat er toen mensen waren die grote moeite hadden met het concept 'object' is nu bijna niet meer te geloven. We gebruiken ze allemaal. De moeilijkheid die bij het correct gebruik van objecten komt kijken hebben we allemaal gewoon geaccepteerd als de uitdaging die bij ons beroept hoort.

LauPro vind het misschien een te moeilijke overgang, maar dat geldt zeker niet voor iedereen. De komende generatie programmeurs zal waarschijnlijk niet eens beter weten.

[LauPro]

flowerp schreef op donderdag 16 augustus 2007 @ 19:21:
Bekijk het eens van de andere kant; 1 user die zeer lang ergens op moet wachten terwijl 7 van je andere cores gewoon niets staan te doen? Is dat geen verspilling van je resources?

In het geval van een workstation zou je gelijk hebben. Echter bij een server zijn er meestal toch meer gebruikers actief. En als er structureel maar 1 user op een server zit dan is/was de oplossing misschien ietwat overgedimensioneerd .

H!GHGuY schreef op donderdag 16 augustus 2007 @ 19:28:
Toch wel. Zulke technologie zorgt dat de balans tussen I/O en CPU weer beter in evenwicht komt.

Ja maar - nogmaals - dat heeft niets te maken met MT, dat kan ook voordeel hebben bij een non-threaded applicatie als er daar meerdere van naast elkaar draaien.

Imo heeft de kernel daar helemaal niets mee te zien. Een kernel moet kernellen en niet de gebruiker/programmeur beperken. Een OS is nog steeds een besturings-systeem. Dat ding moet een tool/basislaag zijn om software op te draaien. Geen beperking waar ik rond moet werken als ik iets wil.

Dan begrijp je niet helemaal wat ik bedoel. Voor sommige algoritmes kan je afhankelijk van het aantal beschikbare cores meerdere threads starten. Hoeveel threads dat zijn ligt dus aan het aantal cores en imo iets wat de kernel mag regelen. En een kernel en OS vind ik toch wat anders - maar dat is weer een andere discussie.

Ik heb er in iedere geval geen zo'n moeite mee om multi-threaded te denken. Zolang je een goed systeem hebt is het in iedere geval behoorlijke eenvoudig. (Elke thread is verantwoordelijk voor iets. De rest van de threads blijven er met hun handen af. Willen ze iets, dan moeten ze maar een message zenden.)

Als je al aan gaf dat het enkele dagen duurde voordat je eruit was dan spreek je jezelf op dat punt tegen. En hoe je het wend of keert, je komt steeds op dat fundamentele punt terug.

Het voordeel zit em in de performantie winst tov locking.

Nogmaals zie ik dat niet gekoppeld aan MT, kom maar met een concreet voorbeeld zou ik zeggen .

flowerp schreef op donderdag 16 augustus 2007 @ 19:56:
LauPro vind het misschien een te moeilijke overgang, maar dat geldt zeker niet voor iedereen. De komende generatie programmeurs zal waarschijnlijk niet eens beter weten.

Ik geloof niet dat je me helemaal begrijpt. Ik programmeer al enige tijd OO & MT'ed applicaties (voornamelijk C++ maar ook Java). En als het nodig is voor een implementatie dan implementeer je threads (daar heb ik zelf geen problemen mee verder).

Maar ik blijf van mening dat de consumentenlijn van de CPU's die nu meerdere cores krijgen in eerste instantie bedoeld zijn om meerdere applicaties naast elkaar te kunnen draaien: het 'multimedia' aspect, dus P2P download op de achtergrond, parren en film kijken tegelijk. Dit heeft helemaal niets te maken met dat ik threads 'eng' vind of wat dan ook, het is imo een praktisch gegeven.

Waar we nu een beetje rondjes in lopen te praten komt door de verschillende omgevingen waar mensen voor programmeren. Laat ik er 3 definiëren:
• Desktop: Huis-tuin-en-keuken computer. Wordt gebruikt voor multimedia, vaak veel applicaties tegelijk. (P2P, IM, MM, www)
• Workstation: Computer speciaal voor specifieke werkzaamheden. Bijvoorbeeld fotobewerking/3D desinging/AutoCAD/development etc. Relatief weinig applicaties tegelijk open, maar wel zware applicaties.
• Server: Computer met meerdere services die erop gericht zijn om de clients zo snel mogelijk van respons te zien met de beschikbaare resources, optimaal gebruik is dus noodzaak.

Dit topic ging voor zover ik kan indelen over een workstation (dus 1 zware applicatie). In dat geval is het imo legitiem om daar naar te optimaliseren. Maar als we het hebben over de desktop, dan heb ik liever dat applicaties een lage footprint hebben en niet teveel cores gebruiken omdat er vaak meerdere naast elkaar draaien.

Als we het hebben over serveromgevingen dan is MT veelal noodzaak en dan zijn de applicaties als het goed is daar al voor gemaakt, de meeste polulaire DBMS'en kunnen dit al (nouja, behalve Firebird afaik). En dat lijkt me verder buiten dit topic staan. Daar het voor serveromgevingen al enige tijd gebruikelijk is om threads in te zetten.

[H!GHGuY]

LauPro schreef op vrijdag 17 augustus 2007 @ 00:03:
Dan begrijp je niet helemaal wat ik bedoel. Voor sommige alhoritmes kan je afhankelijk van het aantal beschikbare cores meerdere threads starten. Hoeveel threads dat zijn ligt dus aan het aantal cores en imo iets wat de kernel mag regelen. En een kernel en OS vind ik toch wat anders - maar dat is weer een andere discussie.

Een OS mag naar mijn mening hoogstens een "GetNbrOfCores()" functie of iets dergelijks implementeren. Wat ik als programmeur daarmee doe is mijn zaak, daar heeft de kernel helemaal niks mee te zien. Kijk je bijvoorbeeld naar de documentatie van make onder linux dan staat er dat het ideaal aantal compile-jobs wat tegelijk loopt gelijk is aan #cores + 1. Andere software kan dan mss optimaal draaien bij #cores*2 of zelfs gewoon met een vast aantal threads omdat verdere opsplitsing onzin is.
De kernel heeft er dus helemaal geen zaken mee hoe ik mijn software dimensioneer. Hoogstens mag hij me de tools aanreiken om dit op een eenvoudige manier te doen.
(Ik gebruik OS en kernel hier door elkaar, ja. In dit geval vind ik dit geen fout )

Als je al aan gaf dat het enkele dagen duurde voordat je eruit was dan spreek je jezelf op dat punt tegen. En hoe je het wend of keert, je komt steeds op dat fundamentele punt terug.

Je vergeet eventjes dat software evolueert. Bovendien werken er 20+ mensen op ons project en niet iedereen heeft hetzelfde licht gezien. Die 2 factoren zorgen dat we niet alleen oude code hebben die met een verouderd mechanisme werkt van wat wij nu implementeren, maar ook dat er code is die helemaal niet volgens dit stramien werkt.
Enigste voordeel hiervan is dat je gemakkelijk kan vergelijken hoe lang je nodig hebt om een fout op te lossen in elk systeem. Het verschil, kan ik je verzekeren, is groot.

Nogmaals zie ik dat niet gekoppeld aan MT, kom maar met een concreet voorbeeld zou ik zeggen .

Zie het als exponential back-off bij ethernet ten opzichte van het token bij token ring.

Bij token ring moet een toestel de token (~lock) in handen hebben om op het netwerk acties te mogen ondernemen. Zelfs als client A moet communiceren met client B en client C wil communiceren met client D. (Zie het als het locken van 10 variabelen met 1 lock. Als 10 clients elk repetitief 1 verschillende variabele willen zijn er telkens 9 andere die moeten wachten.)

Bij ethernet kan iedereen proberen om de actie uit te voeren, maar elke client voert de controle uit of de actie gelukt is (transactional memory commit) of als ze opnieuw moet gebeuren na een backoff delay (transactional memory rollback).
Neem hier terug het voorbeeld van de 10 variabelen en je ziet dat elke client kan doen wat hij wil met zijn variabele.

Zelfs voor 1 variabele met 1 lock (wat je micro-locking ipv macro-locking zou kunnen noemen) zie je dat elke client maar moet doen wat hij wil.
De reden waarom transactional memory een grote stap vooruit is is dezelfde waarom ethernet beter is dan token ring op een netwerk waarin: de kans op een collision heel klein is (2 threads willen dezelfde lock), en de overhead van token-passing (lock-nemen/vrijgeven) relatief groot is.

Dit topic ging voor zover ik kan indelen over een workstation (dus 1 zware applicatie). In dat geval is het imo legitiem om daar naar te optimaliseren. Maar als we het hebben over de desktop, dan heb ik liever dat applicaties een lage footprint hebben en niet teveel cores gebruiken omdat er vaak meerdere naast elkaar draaien.

Jij verliest 1 iets uit het oog.
Desktop applicaties zijn een consumer-product. Werkt software niet dan zal de gebruiker er ofwel mee leven, ofwel een concurrerend product kopen. Maar dat concurrerend product is meestal toch maar even "goed". Net doordat desktop computers steeds krachtiger worden, kunnen software-huizen het zich permitteren om "quasi-roekeloos" om te springen met resources.
Als een operatie 2s duurt dan is het de moeite niet om even te kijken of het niet in een halve seconde kan door te optimaliseren.
(ik overdrijf hier natuurlijk wel wat, maar in extremis komt het daarop neer)

[flowerp]

LauPro schreef op vrijdag 17 augustus 2007 @ 00:03:
[...]
In het geval van een workstation zou je gelijk hebben. Echter bij een server zijn er meestal toch meer gebruikers actief.

Er zijn op een server zeker meer gebruikers actief. Echter, deze gebruikers gebruiken niet allemaal altijd alle cores volledig. Wij hebben rond de 50 users op een oct core bak. Dikwijls zijn ze wel allemaal actief, maar is de belasting per cpu erg laag. 1 of 2 users doen dan opeens iets zwaars en moeten lang wachten. -TE- lang wachten. Dan blijkt dus dat 1 of 2 cores op 100% staan en de andere 7 of 6 nagenoeg niets doen.

Wat doe je dan om het voor die users sneller te krijgen?

Snellere cores kopen?

Helaas, we hebben al de snelste.

Meer geheugen? Snellere disks? Helpt niet. De taak is voornamelijk CPU bound.

Beter of slimmer algoritme / dingen voor berekenen? Dat kan zeker helpen, maar daar hebben we al honderden uren in gestopt.

De logische oplossing is dus gewoon om die zwaardere taken op te splitsen over de cores die op dat moment toch niet zo veel doen, ondanks dat er dus +-50 users op zitten.

Als je al aan gaf dat het enkele dagen duurde voordat je eruit was dan spreek je jezelf op dat punt tegen.

Ik denk niet dat hij zich tegenspreekt. Enkele dagen met een probleem bezig? Joh, ik ben wel eens weken met een (non-MT) probleem bezig. Dat is inherent aan het vak als je het mij vraagt.

[ Voor 11% gewijzigd door flowerp op 17-08-2007 21:12 ]

[MSalters]

LauPro schreef op woensdag 15 augustus 2007 @ 16:23:
Volgens mij is het al meer dan 2 decennia zo dat op het moment dat process A staat te wachten op I/O dat B dan gewoon verder kan. Dus niets nieuws onder de zon. Waar het om gaat is: stel dat je een file hebt van 6 GB. En voor de bewerking (unrarren) moet het hele bestand langs gelopen worden. Dan denk ik niet dat het mogelijk is om daar een versnelling in te brengen. Je bent namelijk afhankelijk van I/O. En je kan maar 1 blok per keer uitlezen, verwerken en wegschrijven en dat moet sequentieel worden gedaan.

Fout. Dit is juist een klassiek voorbeeld hoe je drie threads kunt gebruiken. De eerste thread is je disk read thread. Deze wacht meestal op I/O, maar als het OS een paar sectoren gelezen heeft staat de input thread klaar. De input thread zorgt ervoor dat de uncompress thread de extra data krijgt. Zolang de uncompress thread data heeft, zal de thread op 100% CPU draaien. Is er een blok uncompressed, dan gaat het naar de write thread en kan de compress thread door. De write thread kan vervolgens blokken op een write operatie.

Effect: Meer dan 100% core gebruik mogelijk, omdat de uncompress thread niet op I/O hoeft te wachten maar dat aan andere threads en cores uitbesteed. Is je input disk een andere dan je output disk, dan kunnen de 3 threads zelfs alle 3 nuttig werk doen. Op een single-core machine wisselen de threads elkaar gewoon af en is de performance hit te verwaarlozen.

[Olaf van der Spek]

MSalters schreef op zaterdag 18 augustus 2007 @ 01:15:
Fout. Dit is juist een klassiek voorbeeld hoe je drie threads kunt gebruiken.

In plaats van threads kun je hier ook async of non-blocking IO gebruiken. Het OS kan zelf ook read- en write-buffering doen, dus het voordeel van threads lijkt met hier toch niet groot.

Effect: Meer dan 100% core gebruik mogelijk,

CPU usage voor IO is toch verwaarloosbaar?

[ Voor 11% gewijzigd door Olaf van der Spek op 18-08-2007 12:38 ]