[alg] Gebruik maken van multiple cores

Geplaatst op dinsdag 07 november 2006 00:14

Acties:

Berichten: 1917
Reg. datum: 04 december 2001

Momenteel is het zeer duidelijk dat binnen afzienbare tijd de klok snelheden van de mainstream CPUs niet meer sterk omhoog zullen gaan, maar dat 'voorlopig' (volgens roadmaps tenminste de komende 5 jaar) er vooral ingezet zal worden op multiple cores. Zitten we momenteel op 2 a 4 cores, in de toekomst zullen dat er mogelijk velen tientallen zijn.

Ik vraag me dus af hoe de meeste developpers hier met dit gegeven omgaan. Wat ik in de praktijk zie is dat >90% van de mensen die ik tegen kom nog steeds doet alsof zijn of haar neus bloed. Het speelt natuurlijk wel mee dat eigenlijk ook wel 90% van de mensen tegenwoordig aan serverside programmeren doet, waarbij meerdere requesten van meerdere users altijd wel de cores kunnen opvullen, maar toch...

-echt- ontwerpen voor parallel programming zie ik nog bijna niemand doen. Met komt dikwijls niet verder als: "Nou, tsja... ik spawn weleens een threadje ergens voor". Een schrikbarend aantal mensen schijnt ook nog steeds vol overtuiging te denken dat multiple cores een tijdelijke hype is en dat "intel binnenkort gewoon weer de klok snelheden omhoog gaat gooien" (ook op tweakers dachten velen hier minder dan een jaar geleden nog zo over).

Op dit moment is het mischien nog net aan te verantwoorden. Als je de 2de core negeert dan laat je slechts (potentieel) 50% power liggen, en je kan er nog mee wegkomen door te stellen dat lang niet elke PC al dual core is.

Maar software plan je als het goed is toch een tijdje van te voren. Over een jaar als een grote meerdeheid dual draait en quads ook al lang niet meer puur exotisch zijn zullen klanten ook steeds meer gaan verlangen dat je ook alle cores in een systeem benut. Zelfs voor serverside kan dit gaan gelden. Je wilt namelijk niet dat 1 user lang moet wachten omdat ie een zware berekening uitvoert die slechts op 1 core kan draaien, terwijl de 15 andere cores in je server lichtelijk uit hun neus lopen te eten.

Vandaar dus mijn vraag, hoe serieus nemen jullie nu al ontwerpen voor meerdere cores?

Om in cijfers duidelijk te maken hoe de mensen hierover denken is mischien een pol wel handig:

Poll: Programmeer je voornamelijk client- of server side?
• Voornamelijk serverside
• Voornamelijk clientside
• Ongeveer gelijk

http://poll.dezeserver.nl/results.cgi?pid=151516&layout=2&sort=prc

^{Ook een poll maken? Klik hier}

Poll: Hou jij in je software ontwerp rekening met meerdere cores?
• ja, wil aanwezige hardware optimaal benutten
• Een beetje, voor background tasks spawn ik wel eens een threadje
• nee, ik wacht tot compilers mijn code automatisch verdelen over threads
• nee, meeste software draait snel genoeg op single core
• nee, meer cores=onzin, intel moet snel weer de clock omhoog gooien
• nee, requesten van meerdere users gaan al automatisch naar cores

http://poll.dezeserver.nl/results.cgi?pid=151524&layout=2&sort=prc

^{Ook een poll maken? Klik hier}

henk_DE_man wijzigde dit bericht 09-11-2006 17:07 (28%)
Reden: Een pol om te kijken hoeveel mensen nu concurency belangrijk vinden

Geplaatst op dinsdag 07 november 2006 00:26

Acties:

Door: MBV

getfirefox.com

Berichten: 6802
Reg. datum: 02 februari 2002

Ik hoop dat over een poosje de Intel-compiler zo slim omgaat met branching dat alles vanzelf gaat. Dat hoop ik voor alle mensen met legacy-software, en mensen die niet zo slim zijn om alles in threads uit te denken

.
In het begin (nu) wordt dual core vooral gebruikt voor dingen die echt serieus lang duren, of voor multitasking. Voor de standaard-dingetjes hoeft het ook niet zo nodig: Word hoef je toch nooit op te wachten (behalve dan HDD-gebruik). De echt rekenintensieve dingen konden alleen op een cluster, en zullen met dual-core dus geen probleem hebben.
Voor de andere dingen zal je heel sterk de afweging moeten maken: is die extra tijd in testen/debuggen enzo het me waard? Want met zwaar multithreaded programmeren komen ook moeilijke race-problemen enzo.

Ik ben benieuwd wat de rest ervan denkt, ik ben op het moment niet bezig met een applicatie die daar geschikt voor is (o.a. qua taal

)

Is 40 dagen offline: zie homepage

Geplaatst op dinsdag 07 november 2006 00:46

Acties:

Door: henk_DE_man

Berichten: 1917
Reg. datum: 04 december 2001

quote:
MBV schreef op dinsdag 07 november 2006 @ 00:26:
Voor de andere dingen zal je heel sterk de afweging moeten maken: is die extra tijd in testen/debuggen enzo het me waard? Want met zwaar multithreaded programmeren komen ook moeilijke race-problemen enzo.

Het is mischien een beetje zo dat het voor jouw en mischien ook wel voor mezelf "moeilijke race-problemen zijn". Toen ik nog informatica studeerde zag ik al dat er een zekere nadruk werd gelegd op concurency. In meerdere vakken kwam het thema terug Toch werd het in de praktijk nog helemaal niet als iets serieus gezien, maar echt als een academische oefening en meer niet. (dit was de tijd dat een 100Mhz CPU nog snel was btw)

Ik heb echter in de praktijk meegemaakt dat een generatie voor mij dezelfde soort problemen had met de overstap van procedurele naar OO code. Die oudere generatie kon niet met objecten omgaan, terwijl de nieuwe, jongere generatie het zo oppikte en de huidige generatie zich eigenlijk amper niet kan voorstellen wat het is om niet-OO te programmeren.

Zou het niet kunnen dat de nu komende generatie die vanaf het begin getraind wordt om parallel te denken hier veel makkelijker mee omgaat als de huidige generatie? Voor hun zijn race conditions en synchronisations misschien gewoon een 2de natuur, net zoals wij met het grootste gemak polymorphisme en inheritance etc toepassen. En ja, het zijn zulke simpele concepten maar ik heb 'oude' C programmeurs destijds hier echt kapot op zien gaan, tot op het punt van ontslag nemen aan toe.

Geplaatst op dinsdag 07 november 2006 00:55

Acties:

Door: .oisyn FP ProMod

programulator

Berichten: 20.848
Reg. datum: 26 september 2000

Tja, het hangt natuurlijk puur af van de software die je maakt. De gemiddelde applicatie zal ook geen meerdere cores nodig hebben aangezien hij sowieso al niet eens 1% van de totale load van het systeem voor z'n rekening neemt. Ik denk dat het gros van de mensen hier wel in die doelgroep valt.

Uiteraard zijn wij er wel mee bezig, al is het alleen maar omdat we die kant worden opgeduwt door de consolefabrikanten (hoewel op de PC natuurlijk precies dezelfde situatie heerst...). Het blijft een moeilijk iets though, processen zijn erg moeilijk op te delen. Wat wij voornamelijk zien is niet zozeer dat bestaande code opgedeeld wordt over de cores (gebeurt natuurlijk wel, maar met een hele grove korrel), maar dat we de overige cores voor hele andere (nieuwe) dingen gaan gebruiken. Aan de andere kant doen we het ook al jaren; rendering, sound en disc IO lopen ook allemaal parallel aan de main core.

[Tomb Raider: Underworld] - [Deus Ex 3] - [My javascript wolfenstein project]

Geplaatst op dinsdag 07 november 2006 02:47

Acties:

Door: Korben

Bliep

Berichten: 1021
Reg. datum: 10 januari 2001

Het enige wat inderdaad wel meer gedaan wordt is afzonderlijke processen binnen een applicatie parallel laten lopen. Denk aan physics, AI, netwerkcode... Het probleem is dat sommige dingen niet effectief te parallelliseren zijn.

Denk aan het toepassen van een complex effect op een geluidsbestand. Elke sample die verwerkt wordt kan een vorige verwerkte sample nodig hebben voor de berekening. Als je dan parallelliseert gaat het alleen maar nog langzamer omdat na elk sample de thread ook nog moet wachten op de/een andere thread die het voorgaande sample verwerkt.

Een ander voorbeeld is het encoden van een MP3'tje. Ja, je kunt per frame een core er op los laten, maar dat kan dan alleen bij ABR, wat toch zeldzamer en zeldzamer wordt omdat het kwalitatief gewoon inferieur is. Als je met VBR gaat werken, moet je toch weer wachten op andere threads, of je moet naderhand met data gaan schuiven, wat óf heel veel geheugen kost, óf heel veel I/O, wat je voordeel gelijk de kop in drukt.

quote:
.oisyn schreef op dinsdag 07 november 2006 @ 00:55:
Tja, het hangt natuurlijk puur af van de software die je maakt. De gemiddelde applicatie zal ook geen meerdere cores nodig hebben aangezien hij sowieso al niet eens 1% van de totale load van het systeem voor z'n rekening neemt. Ik denk dat het gros van de mensen hier wel in die doelgroep valt.

Daarbij komt nog dat veel developers überhaupt nog moeten leren hoe ze efficiënt met de processor om moeten gaan, zelfs op 1 core. Nog steeds zijn er zoveel programma's die niet een UI thread en tenminste één worker thread hebben, en zelfs Windows-componenten maken zich hier schuldig aan.

| C2D E6600 @ 3 GHz / Gigabyte GA-P35-DQ6 / 2 GB DDR2-800 / GeForce 8800GTS 640 MB / 1650 GB SATA
| Crysis \o/ | Call Of Duty 4 \o/ | UT3 \o/

Geplaatst op dinsdag 07 november 2006 07:47

Acties:

Door: Alarmnummer

-=Spring=-

Berichten: 8330
Reg. datum: 29 juli 2001

Om in serverside problematiek te blijven:

De meeste servlet containers, applicatie containers, databases maken allemaal gebruik van meerdere threads, dus die meerdere cores die zullen wel gebruikt gaan worden (mits je os/kernel dat toelaat uiteraard). Het percentage rekenintensieve applicaties is erg klein tov het aantal webapplicaties dat gebouwd worden.

Dus ik denk dat 99% van de serverside java programmeurs zich onwetend kunnen houden (zoals ze nu ook doen aangezien de container de meeste thread problematiek al voor hun coordineerd). En isolation icm immutability (en database transactie die de echte concurrency control voor je uitvoert) is je grootste vriend om concurrency control gerelateerde complexiteit te reduceren

Voor die andere 1%... yess... eindelijk iets spannends

We gaan trouwens nog veel visibility problemen krijgen door de introductie van multicores. Aangezien visibility problemen zich op singlecores niet zullen voordoen. Daarom leken de oude libraries altijd goed te werken, maar zulen ze op de multicores vaker onvoorspelbare problemen op gaan leveren.

Alarmnummer wijzigde dit bericht 07-11-2006 09:07 (11%)

Blog pveentjer.wordpress.com and working on Prometheus

Geplaatst op dinsdag 07 november 2006 09:14

Acties:

Door: MBV

getfirefox.com

Berichten: 6802
Reg. datum: 02 februari 2002

quote:
henk_DE_man schreef op dinsdag 07 november 2006 @ 00:46:

Zou het niet kunnen dat de nu komende generatie die vanaf het begin getraind wordt om parallel te denken hier veel makkelijker mee omgaat als de huidige generatie? Voor hun zijn race conditions en synchronisations misschien gewoon een 2de natuur, net zoals wij met het grootste gemak polymorphisme en inheritance etc toepassen. En ja, het zijn zulke simpele concepten maar ik heb 'oude' C programmeurs destijds hier echt kapot op zien gaan, tot op het punt van ontslag nemen aan toe.

Toch blijft je testen veel moeilijker: onder load kan zich ineens een crash voordoen, die zich zonder zware load niet had voortgedaan. Onder load van een ander proces kan zich een race-probleem voordoen wat niet ontstond bij volledige belasting door de applicatie zelf. Testen is een hele slag complexer geworden, doordat je de load mee moet nemen.

Tuurlijk heb ik wel wat threading gehad op het HBO (alhoewel dat veel te weinig is) en er zijn hier op de TU/e ook wat vakken die ik kan volgen hierover. Erg interessant natuurlijk, maar zeggen dat het net zo makkelijk wordt als OOd gaat me wat ver. OOd/OOp is niet inherent complexer, het is een andere manier van denken. _{ik ben van die generatie die zonder OO niet kan programmeren ja}.Met threads krijg je 'gratis' meer complexiteit, tenzij de compiler het automatisch (en goed) voor je oplost.[/ME]

Is 40 dagen offline: zie homepage

Geplaatst op dinsdag 07 november 2006 09:19

Acties:

Door: MTWZZ

Hertog Jan schopt kont

Berichten: 1476
Reg. datum: 12 mei 2000

quote:
MBV schreef op dinsdag 07 november 2006 @ 09:14:
[...]
Tuurlijk heb ik wel wat threading gehad op het HBO (alhoewel dat veel te weinig is)

You lucky bastard

Volgens mij is dat al meer dan de gemiddelde HBO IT student krijgt en wat IMHO echt schandalig is.

Met Series III Land Rover -> De Generaal!

Geplaatst op dinsdag 07 november 2006 09:47

Acties:

Door: MBV

getfirefox.com

Berichten: 6802
Reg. datum: 02 februari 2002

Ik zat dan ook op de beste HBO informatica (Technische Informatica, TH Rijswijk), en zit nu op beste TU

Is 40 dagen offline: zie homepage

Geplaatst op dinsdag 07 november 2006 19:15

Acties:

Door: H!GHGuY

BooBs for BraiNs

Berichten: 1444
Reg. datum: 02 december 2002

Multi-core developen is voor 90% van de applicaties overkill. Eenvoudige programma's hebben het niet nodig. Andere zijn I/O bound. Je blijft dus over met de typische applicatie die 100% CPU eist met slechts een minimum aan I/O.

Noem binnen de 10 seconden 10 soorten applicaties die aan dit karakter voldoen. Om je even op weg te helpen: games, audio/video en-/decoding (mits beperkte bitrate) en daar zijn mijn 10 seconden reeds op.
Games zijn reeds mooi op weg. Audio en video decoding zijn soms behoorlijk moeilijk. Je kan een MPEG2 stroom gerust per GOP op een processor te encoden. Maar probeer dit niet met H.264.

Zelfs al kan je nog 10tallen applicatie-types noemen, het moet ook nog de moeite zijn en blijven. Ik kan me inbeelden dat het schedulen van verschillende processen op verschillende cores bij multi-tasking op dit moment de grootste performance boost geeft. Neem bijvoorbeeld een virus-scanner die op de 2de core draait en de data die core 1 wil inlezen (gebufferd natuurlijk) scant op virussen.

Zoals Alarmnummer aangaf: de meeste serverside software is er reeds voor geoptimaliseerd. Een multi-core browser of word processor lijken me klinkklare onzin.

Bovendien is het voor de meeste programma's niet eens de moeite. Het extra werk dat steekt in debuggen (race-condities, SMP problemen e.d.) haalt het meestal niet bij het voordeel. Zelfs op single-core kun je al behoorlijk irritante race-condities hebben.

Yo momma's so fat, Dr. Martens had to kill 3 cows just to make her a pair of shoes.

Geplaatst op dinsdag 07 november 2006 21:04

Acties:

Door: Confusion Moderator W&L

Fallen from grace

Berichten: 10.936
Reg. datum: 10 april 2001

Zolang ik geen tekort aan processorcapaciteit heb of voorzie, zie ik geen reden expliciet het werk over meerdere cores te gaan verdelen. Zeker aan de client kant is het alleen maar prettig dat de gebruiker andere dingen kan blijven doen, terwijl onze applicatie 1 core flink belast.

Wie trösten wir uns, die Mörder aller Mörder?

Geplaatst op dinsdag 07 november 2006 21:34

Acties:

Door: Grijze Vos

Berichten: 2773
Reg. datum: 20 december 2002

quote:
MBV schreef op dinsdag 07 november 2006 @ 09:47:
Ik zat dan ook op de beste HBO informatica (Technische Informatica, TH Rijswijk), en zit nu op beste TU

offtopic:
Volgens mij hebben wij het over PGP op Ubuntu gehad laatst bij IS.

Hanlon's Razor: "Never attribute to malice that which can be adequately explained by stupidity."

Geplaatst op dinsdag 07 november 2006 22:42

Acties:

Door: flowerp

Berichten: 1888
Reg. datum: 13 september 2003

quote:
H!GHGuY schreef op dinsdag 07 november 2006 @ 19:15:
Multi-core developen is voor 90% van de applicaties overkill. Eenvoudige programma's hebben het niet nodig.

Dit vind ik een behoorlijk domme, of op z'n minst naieve opmerking. Het past precies in het rijtje dat 640kb genoeg zou zijn of dat de meeste applicatie's niet meer dan 100Mhz nodig zouden hebben.

Heb je er wel eens bij stil gestaan zoals de TS stelt dat een enkele core binnen afzienbare tijd NIET meer significant sneller wordt. Een enkele core zoals we die nu kennen zit toch echt wel op de grenzen wat haalbaar is. Als wij niet voor multi-core gaan developen kunnen Intel & Co net zo goed stoppen met het uitbrengen van nieuwe CPU's.

Voor multi-tasking is dual core nog een goede oplossing. Je draait dan al je background zut op de ene core en hebt de andere vrij voor je foreground app.

Op het moment dat we op 80 cores zitten (google maar eens op 80 cores idf) dan kun je gewoon niet meer met deze stelling wegkomen. Gebruikers gaan zeker niet 80 taken op full-load tegelijk uitvoeren.

De stelling is simpel; des te meer cores er komen, des te meer performance je laat liggen.

quote:
Een multi-core browser of word processor lijken me klinkklare onzin

Precies wat men vroeger zei; een word processor op een 100Mhz CPU moeten draaien is klinkklare onzin. De grootste overeenkomst is de beperkte visie die mensen zoals jij hebben. Toen keek men naar het huidige aanbod en zag dat word processors op 33Mhz machines redelijk draaiden. Mensen met weinig inbeeldings vermogen konden slechts lijntjes doortrekken en in hun belevings wereld was een word processor op een 100Mhz CPU dus ook inderdaad onzin.

Maar kijk eens naar vandaag de dag. De laatste generatie word processors doet en kan steeds meer. Complexe vector graphics, real-time spell checking, en weet ik wat nog meer voor dingen. Feit is dat de laatste versies van bijvoorbeeld Writer or Word verre van 100% soepel draaien op zelfs mijn 3800+ X2. Het draait niet slecht, maar zeker in de wat grotere documenten gaan dingen als her-formateringen zeker niet instant. Zolang dat niet gebeurd is er zeker nog ruimte voor verbeteringen.

flowerp wijzigde dit bericht 07-11-2006 23:04 (30%)

Ruim baan voor de geemancipeerde vrouw!

Geplaatst op dinsdag 07 november 2006 23:03

Acties:

Door: RobIII Moderator PRG/SEA/WEB

Papa van LucaIII \o/

Berichten: 15.723
Reg. datum: 18 december 2001

quote:
flowerp schreef op dinsdag 07 november 2006 @ 22:42:
Op het moment dat we op 80 cores zitten (google maar eens op 80 cores idf) dan kun je gewoon niet meer met deze stelling wegkomen. Gebruikers gaan zeker niet 80 taken op full-load tegelijk uitvoeren.

De stelling is simpel; des te meer cores er komen, des te meer performance je laat liggen.

Vet! Notepad op 80 cores!

Het is natuurlijk ook nogal afhankelijk van wat je applicatie doet; zoals reeds aangegeven staan een flink aantal (kantoor)applicaties doorgaans 99% van de tijd met hun vinger in de neus te wachten op input van de gebruiker. Applicaties die meerdere threads kunnen gebruiken omdat het nut heeft (zoals bijvoorbeeld in meerdere threads renderen, in de achtergrond "spellingscontrole" doen, server-apps etc.) zullen hooguit over nog méér cores gespreid worden (="winst") maar vind ik het me nogal bot om te stellen dat het dezelfde vergelijking is als de roemruchte "640Kb ought to be enough for everybody".

Euh, wat ik dus probeer te zeggen is dat het lang niet altijd nuttig is (en soms zelfs onwenselijk) om je app over meerdere cores te smeren (en dan heb ik het nog niet eens over de extra ontwikkeltijd die er in gaat zitten die ook betaald moet worden en waar het gebruikers worst zal wezen of de app op 1 of 37 cores draait als het toch in een "flits" klaar is). Euh... het is dus niet zo "zwart/wit" als jij het stelt

Er zijn gradaties.

quote:
flowerp schreef op dinsdag 07 november 2006 @ 22:42:
Maar kijk eens naar vandaag de dag. De laatste generatie word processors doet en kan steeds meer. Complexe vector graphics, real-time spell checking, en weet ik wat nog meer voor dingen. Feit is dat de laatste versies van bijvoorbeeld Writer or Word verre van 100% soepel draaien op zelfs mijn 3800+ X2. Het draait niet slecht, maar zeker in de wat grotere documenten gaan dingen als her-formateringen zeker niet instant. Zolang dat niet gebeurd is er zeker nog ruimte voor verbeteringen.

Nogmaals; het moet ook te doen zijn in meerdere threads; je kunt wel een stuk of 80 threads hebben lopen, maar als die allemaal op die ene staan te wachten voordat zelf verder kunnen is het natuurlijk nonsense om uberhaupt die treads te starten. Met dat her-formatteren sla je de spijker op z'n kop; Ik zie niet in hoe ik dat over meerdere threads zou kunnen verdelen.

Meer threads is niet altijd beter.

RobIII wijzigde dit bericht 07-11-2006 23:10 (40%)

We all get along with some glue and duct tape here and there - but when the sh*t hits the fan, don’t blame the duct tape.

Trotse papa van Luca! | Pick My Icon!

Geplaatst op dinsdag 07 november 2006 23:19

Acties:

Door: flowerp

Berichten: 1888
Reg. datum: 13 september 2003

quote:
RobIII schreef op dinsdag 07 november 2006 @ 23:03:
Het is natuurlijk ook nogal afhankelijk van wat je applicatie doet; zoals reeds aangegeven staan een flink aantal (kantoor)applicaties doorgaans 99% van de tijd met hun vinger in de neus te wachten op input van de gebruiker.

Mischien zelfs wel 99.9%. Er is dan ook niet een tekort aan continue CPU power, maar aan burst cpu power. Op het moment DAT de gebruiker wat doet is er wel zeker nut voor meer CPU power.

quote:
Euh, wat ik dus probeer te zeggen is dat het lang niet altijd nuttig is (en soms zelfs onwenselijk) om je app over meerdere cores te smeren (en dan heb ik het nog niet eens over de extra ontwikkeltijd die er in gaat zitten die ook betaald moet worden en waar het gebruikers worst zal wezen of de app op 1 of 37 cores draait als het toch in een "flits" klaar is).

Het punt is dat lang niet elke applicatie met alles in een flits klaar is. Als ik nu even snel kijk naar de programma's in mij dock; Mail, Safari, iTines, iPhoto, VPC, TextEdit, Eclipse, dan is hier alleen TextEdit min of meer instant in alles. In alle andere apps gaat er van alles gewoon niet in een flits.

Wat ik hier proef is dat men toch wel erg anti multi-core is. Wat stellen jullie dan voor, dat de huidige desktop CPU's als 'final' verklaard worden en dat nieuwe CPU's (met dus meer cores) alleen nog voor servers gemaakt gaan worden?

Het 'leuke' is ook dat men op de FP stelt dat multi-core onzin is omdat er nog te weinig software is die er gebruik van maakt en dat de developers maar eens haast moeten gaan maken met hun software geschikt te maken. Kijk je dan hier dan zie je dat de developers (wij dus) stellen dat multi-core onzin is omdat bijna elke denkbare applicatie al snel genoeg draait.

quote:
Ik zie niet in hoe ik dat over meerdere threads zou kunnen verdelen.

Dat is nou het hele punt. JIJ ziet dat niet in, omdat je niet getraind bent in parallel denken.

Natuurlijk, ik stel het even een beetje zwart/wit of bot, en ik weet ook wel dat sommige dingen niet of nauwelijks te paralleliseren zijn, maar dat is ook om een beetje de discussie uit te lokken. Van "kan niet, doen we niet. Punt." wordt ook niemand beter.

Multi-core is de (voorlopige) toekomst en like it or not, op een gegeven moment zul je toch mee moeten doen. Een klassieker op dit gebied is nog steeds het artikel van Herb Sutter van alweer een poosje geleden: http://www.gotw.ca/publications/concurrency-ddj.htm

flowerp wijzigde dit bericht 07-11-2006 23:29 (16%)

Ruim baan voor de geemancipeerde vrouw!

Geplaatst op woensdag 08 november 2006 00:45

Acties:

Door: MBV

getfirefox.com

Berichten: 6802
Reg. datum: 02 februari 2002

quote:
Grijze Vos schreef op dinsdag 07 november 2006 @ 21:34:
[...]

offtopic:
Volgens mij hebben wij het over PGP op Ubuntu gehad laatst bij IS.

offtopic:
key signen?

Wie ben jij dan? Man, uit '82, woonplaats eindhoven, IS gevolgd is nog een groep van +- 30 man

quote:
flowerp schreef op dinsdag 07 november 2006 @ 23:19:
[...]

Mischien zelfs wel 99.9%. Er is dan ook niet een tekort aan continue CPU power, maar aan burst cpu power. Op het moment DAT de gebruiker wat doet is er wel zeker nut voor meer CPU power.

Yup. Er is alleen altijd die kosten-afweging: als we alles in assembly schreven, dan was het wél in een flits klaar geweest, maar dat doen we ook niet. Waarom niet? Kost te veel ontwikkeltijd, en is niet te onderhouden. Je ziet op het moment juist een trend naar nog grotere performance-vreters: laten we in plaats van C++ naar Javascript overstappen, makkelijker te onderhouden (Firefox).
En dan kom je direct weer bij een punt waar je er voordeel uit kan halen: hoe meer high-level een programma geschreven is, hoe meer je kan doen met multi-threading.
Stel je eens een binary-search voor, die in Haskell is geschreven. 1 van de 2 branches kan steeds op een andere proc verder draaien, wat best wel eens performance kan schelen. Dat kan de compiler vrij eenvoudig vinden, met een while-loop in C kan dat veel moeilijker.

quote:

[...]

Het punt is dat lang niet elke applicatie met alles in een flits klaar is. Als ik nu even snel kijk naar de programma's in mij dock; Mail, Safari, iTines, iPhoto, VPC, TextEdit, Eclipse, dan is hier alleen TextEdit min of meer instant in alles. In alle andere apps gaat er van alles gewoon niet in een flits.

Moet jij eens voor de gein gaan debuggen (we zitten toch in /14?) waar die tijd in gaat zitten. Ik durf te wedden dat de wachttijden (op Windows iig) voor meer dan de helft uit HDD-access bestaat. MacOS X ken ik niet, op Linux zit ik daarentegen wel continue op mijn proc te wachten met Eclipse

. Toch eens die java-code naar een executable compileren met GCC

quote:
Wat ik hier proef is dat men toch wel erg anti multi-core is. Wat stellen jullie dan voor, dat de huidige desktop CPU's als 'final' verklaard worden en dat nieuwe CPU's (met dus meer cores) alleen nog voor servers gemaakt gaan worden?

Ik stel voor dat we wachten totdat intel de Intel C++ compiler 10 afheeft, die vanzelf alles in threads gooit als dat kan

. Tot die tijd laten we de CPU lekker uit z'n neus vreten, behalve voor dingen waar de kostenvergelijking tussen ontwikkel/test-tijd <=> snelheid richting snelheid gaat. Duidelijk gescheiden taken in een aparte thread gooien als dat relatief eenvoudig is (autoformat, spellcheck), taken die echt teveel tijd kosten in threads ophakken mits mogelijk (voor veel taken is te bewijzen dat dat niet zinvol is door de berg data die heen en weer moet enzo), en hopen dat die compilers snel komen

quote:
Het 'leuke' is ook dat men op de FP stelt dat multi-core onzin is omdat er nog te weinig software is die er gebruik van maakt en dat de developers maar eens haast moeten gaan maken met hun software geschikt te maken. Kijk je dan hier dan zie je dat de developers (wij dus) stellen dat multi-core onzin is omdat bijna elke denkbare applicatie al snel genoeg draait.

Moet je eens goed kijken waar die mensen op geilen: games. Heb je het nieuws een beetje gevolgd? valve gaat multicore proggen, zodat de developers van games zich daar niet mee bezig hoeven te houden. Kijk, dat bedoel ik nou ongeveer (alhoewel zo'n engine geen compiler is). Standaard-oplossingen zodat je zelf niet moeilijk hoeft te doen, hergebruik van oplossingen enzo.
Daarnaast weten de meeste developers dat bijna alle applicaties 10x sneller kunnen, simpelweg door efficienter om te gaan met die ene processor. Kost wel veel tijd=geld om dat voor elkaar te krijgen.

quote:
Dat is nou het hele punt. JIJ ziet dat niet in, omdat je niet getraind bent in parallel denken.

Ach ja, JIJ gooit alles automatisch in threads? JIJ maakt daarbij nooit fouten? Ga JIJ dan eens lekker aan firefox knutselen om te zorgen dat dat Javascript multithreaded wordt, ik wordt helemaal ziek van die animaties die 100% trekken

_{ja, ik heb ook dat firefox-flash bericht gezien, zie vorige punt}

quote:
Natuurlijk, ik stel het even een beetje zwart/wit of bot, en ik weet ook wel dat sommige dingen niet of nauwelijks te paralleliseren zijn, maar dat is ook om een beetje de discussie uit te lokken. Van "kan niet, doen we niet. Punt." wordt ook niemand beter.

Moet ik echt een taak verzinnen waarbij te bewijzen is dat multi-tasking zinloos is?

Daarnaast zijn er op het moment nog niet echt de tools voor om goe multithreaded te ontwikkelen. Goede test-suites om race-problemen te zien, dat soort gein heb ik allemaal nog niet gezien.

Is 40 dagen offline: zie homepage

Geplaatst op woensdag 08 november 2006 08:32

Acties:

Door: Confusion Moderator W&L

Fallen from grace

Berichten: 10.936
Reg. datum: 10 april 2001

quote:
flowerp schreef op dinsdag 07 november 2006 @ 23:19:
Dat is nou het hele punt. JIJ ziet dat niet in, omdat je niet getraind bent in parallel denken.

Ach schei uit, "getrained in parallel denken". Sorry hoor, maar zulke rocket science is het schrijven van een multithreaded app in een taal die daar grondige ondersteuning voor heeft nou ook bepaald weer niet. Het vereist niets anders dan bedenken welke taken onafhankelijk van anderen kunnen worden uitgevoerd en op welk moment de informatie weer gebundled kan/moet worden. En dan hebben mensen gelijk: wat ga jij multithreaden aan het operationele gebruik van een wordprocessor?

Ja, natuurlijk stop je de instant spell-check in een aparte thread, maar afgezien daarvan is er verdomd weinig dat je winst op gaat leveren. Juist omdat je burst CPU power nodig hebt, heb je dus ook burst memory bandwidth nodig om de gegevens weer bij elkaar te krijgen en de I/O overhead maakt doet ieder voordeel va multithreaden in dat soort situaties teniet. Als ik er naast zit: leg me dan alsjeblieft uit waarom, in plaats van op te merken dat ik "niet getrained zou zijn om parallel te denken". Ik ben uberhaupt niet getrained om software te schrijven, functioneel noch OO te denken of om 'in design patterns' te denken.

Wie trösten wir uns, die Mörder aller Mörder?

Geplaatst op woensdag 08 november 2006 09:09

Acties:

Door: Grijze Vos

Berichten: 2773
Reg. datum: 20 december 2002

quote:
MBV schreef op woensdag 08 november 2006 @ 00:45:
[...]

offtopic:
key signen?
Wie ben jij dan? Man, uit '82, woonplaats eindhoven, IS gevolgd is nog een groep van +- 30 man

offtopic:
Ik ben degene waar je al twee weken naast zit.

Grijze Vos wijzigde dit bericht 08-11-2006 09:09 (3%)

Hanlon's Razor: "Never attribute to malice that which can be adequately explained by stupidity."

Geplaatst op woensdag 08 november 2006 09:24

Acties:

Door: djingelz

Berichten: 121
Reg. datum: 25 juli 2006

Parallel programmeren zal in de toekomst steeds belangrijker worden, daar ben ik van overtuigd. Ik denk dat flowerp dan ook een goed punt heeft dat ontwikkelaars vaker zouden moeten nadenken over de eventuele mogelijkheden om parallelisme toe te passen. Het is inderdaad iets waar programmeurs vaak niet (of nauwelijks) bij stil staan en het zou wel goed zijn als ze dat zouden doen.

Het parallel denken is echter niet eenvoudig en veel programmeurs zijn dat inderdaad niet gewoon. Ik heb echter wel mijn twijfels of het goed zou zijn dat iedereen parallel leert denken en ermee gaat werken. Ik denk dat deze stap een stuk groter is (misschien wel niet vergelijkbaar) dan bijvoorbeeld de overstap van procedureel naar object oriented terwijl deze stap al bergen programmeurs in grote problemen bracht/brengt.

CPU bakkers zijn gewend om parallel te denken (ze doen niet anders) en hier wordt dit al zeer lang gedaan. De technieken die in deze branche ontwikkeld zijn spelen hier ook helemaal op in en bij een chip ontwerp kan het model op verschillende niveaus worden getest en geverifieerd. Voor deze branche is het echter bittere noodzaak om met een goed ontwerp te komen want een fout in het ontwerp kost veel geld en is niet te herstellen bij de reeds gefabriceerde produkten. Dit in tegenstelling tot software waarbij het mogelijk is om deze te updaten zodra er een fout wordt gevonden. Dat is een zwakte van software maar het is meteen ook een sterkte waardoor er zoveel software is tegenwoordig.

Parallelisme is een "nieuwe" dimensie in software die een grote rol gaat spelen. Deze nieuwe dimensie maakt het echter weer een slag moeilijker om software te testen en foutvrij te maken. Dit is volgens mij ook een belangrijke reden voor bijvoorbeeld Valve een engine maakt die deze dimensie voor je wegneemt. Het is voor veel developers nu al moeilijk om bug-vrije software te schrijven en de introductie van een nieuwe dimensie zou vele van hen geen goed doen.

Ik verwacht dan ook dat het in de toekomst niet belangrijk wordt voor een programmeur om parallel te kunnen denken (al is het goed dat hij dat zo nu en dan wel doet

) maar dat deze problemen worden opgevangen door een bepaalde abstractielaag (o.i.d.). Enerzijds kan een programmeur daardoor blijven denken zoals hij nu al doet en anderszijds blijft de software beter onderhoudbaar.

Quidquid agis, prudenter agas, et respice finem!

Geplaatst op woensdag 08 november 2006 10:24

Acties:

Door: Alarmnummer

-=Spring=-

Berichten: 8330
Reg. datum: 29 juli 2001

quote:
Confusion schreef op woensdag 08 november 2006 @ 08:32:
[...]Juist omdat je burst CPU power nodig hebt, heb je dus ook burst memory bandwidth nodig om de gegevens weer bij elkaar te krijgen en de I/O overhead maakt doet ieder voordeel va multithreaden in dat soort situaties teniet.

Oeh oeh.. ik ook. Een nadeel van multithreaden over meerdere cores met gescheiden caches is dat je vaak 'synchronisatie' nodig bent (gebeurt mbv memory barriers) wat de snelheids winst van een cache gedeeltelijk teniet doet. In theorie zou een proces met 2 threads en 2 cores door cache invalidatie langzamer kunnen lopen dan een systeem met 2 threads over 1 enkele core (met dezelfde snelheid) doordat het vaker met main memory (of een langzamere cache) zal moeten communiceren.

ps:
daarom is het ook zo belangrijk dat snelle cpu's (die een groot aantal threads gaan draaien) ook zo'n grote hoeveelheid cache hebben. Je wilt namelijk niet dat het draaien van een bepaalde thread de cache entries voor een andere thread eruit gaat knikkeren. Als dit namelijk wel gebeurd dan kan iedere thread iedere keer na het inschedulen weer data uit main memory (of een langzamere cache) halen. Een cache word meestal met een groter geheugen blok gevuld: in de cache wordt namelijk niet alleen de data opgehaald die nodig is, maar ook de data die waarschijnlijk nodig is. Door deze eigenschap loopt je cache dus nog sneller vol.

Alarmnummer wijzigde dit bericht 08-11-2006 10:32 (30%)

Blog pveentjer.wordpress.com and working on Prometheus

Geplaatst op woensdag 08 november 2006 10:27

Acties:

Door: MBV

getfirefox.com

Berichten: 6802
Reg. datum: 02 februari 2002

quote:
Grijze Vos schreef op woensdag 08 november 2006 @ 09:09:
[...]

offtopic:
Ik ben degene waar je al twee weken naast zit.

offtopic:
Die 2 keren dat ik zo laat was dat ik naast een willekeurig iemand ging zitten omdat er weinig plek meer was dus, en jij hebt waarschijnlijk op mijn laptop gezien dat ik MBV was? Zomaar een gokje

'k voel me weer eens echt een nerd, ik ken amper mensen die niet bij mij in het schakeltraject zaten...

quote:
djingelz schreef op woensdag 08 november 2006 @ 09:24:
Ik verwacht dan ook dat het in de toekomst niet belangrijk wordt voor een programmeur om parallel te kunnen denken (al is het goed dat hij dat zo nu en dan wel doet ) maar dat deze problemen worden opgevangen door een bepaalde abstractielaag (o.i.d.). Enerzijds kan een programmeur daardoor blijven denken zoals hij nu al doet en anderszijds blijft de software beter onderhoudbaar.

Vergeet niet dat ook als de problemen op dat niveau worden weggenomen, debuggen alsnog een stuk lastiger wordt dan het nu is. Ook compilers maken soms fouten, en fouten hierin (verondersteld onafhankelijke dingen parallel zetten, terwijl ze niet onafhankelijk zijn) zal erg lastig debuggen worden.

Is 40 dagen offline: zie homepage

Geplaatst op woensdag 08 november 2006 10:46

Acties:

Door: barfieldmv

Berichten: 778
Reg. datum: 24 maart 2004

Multi threaded applicaties worden pas belangrijk als er veel rekenwerk gedaan moet worden dat niet in een flits af is. Bij de meeste task-switches van applicaties word er vooral veel gewacht op I/O subsystemen, niet zozeer op de cpu.

Ik denk dat er veel te winnen is door kleinere worksets te gebruiken in applicaties en goed op onnodige loopjes te letten.

Voordat je begint met het schrijven van een applicatie maak je een technisch plaatje van de functionaliteit. Zitten daar veel parralelle processen tussen of zware reken stukken dan is mulithreading de oplossing (8 cores, 8 wav2mp3 threadjes) zit je echter met een linaire rekensom (mp3 vbr) dan moet je wat veranderen aan: of je algoritme, of gewoon verzinnen dat je tientallen andere zaken op de achtergrond kan uitvoeren.

Maw er komen idd steeds meer cores bij en voor optimaal gebruik van je PC is het gebruik van meerdere threads dan ook noodzakelijk . Als ik nu zelf een applicatie ontwikkel gebruik ik meerdere threads en dat is puur voor het updaten van wat grafisch werk.

Geplaatst op woensdag 08 november 2006 10:56

Acties:

Door: djingelz

Berichten: 121
Reg. datum: 25 juli 2006

quote:
MBV schreef op woensdag 08 november 2006 @ 10:27:
Vergeet niet dat ook als de problemen op dat niveau worden weggenomen, debuggen alsnog een stuk lastiger wordt dan het nu is. Ook compilers maken soms fouten, en fouten hierin (verondersteld onafhankelijke dingen parallel zetten, terwijl ze niet onafhankelijk zijn) zal erg lastig debuggen worden.

Je hebt gelijk dat debuggen niet makkelijker wordt en ik ben dan ook benieuwd hoe dit in de toekomst gerealiseerd gaat worden.

Het is ook mogelijk dat een compiler fouten maakt (het blijft software

) maar het zal voor een programmeur een verademing zijn dat hij/zij daar niet zelf voor verantwoordelijk is.

Wat ik me overigens ook afvraag is hoe je rekening houdt met parallelisme. Zoals hier al wordt aangegeven zijn er op dit moment situaties waar het geen voordeel is om multi-threading te gebruiken omdat de overhead te groot is terwijl er andere systemen zijn waar dit wel het geval is. Hoe ontwerp je een applicatie die bijvoorbeeld op zowel een single core processor als een 80 core processor goed moet draaien? Dat lijkt me een hele uitdaging waarbij een dergelijke abstractielaag een goede rol kan spelen (al is dat natuurlijk ook weer overhead

Quidquid agis, prudenter agas, et respice finem!

Geplaatst op woensdag 08 november 2006 11:21

Acties:

Door: .oisyn FP ProMod

programulator

Berichten: 20.848
Reg. datum: 26 september 2000

quote:
Alarmnummer schreef op woensdag 08 november 2006 @ 10:24:
[...]

Oeh oeh.. ik ook. Een nadeel van multithreaden over meerdere cores met gescheiden caches is dat je vaak 'synchronisatie' nodig bent (gebeurt mbv memory barriers) wat de snelheids winst van een cache gedeeltelijk teniet doet. In theorie zou een proces met 2 threads en 2 cores door cache invalidatie langzamer kunnen lopen dan een systeem met 2 threads over 1 enkele core (met dezelfde snelheid) doordat het vaker met main memory (of een langzamere cache) zal moeten communiceren.

Beetje kort door de bocht. Ten eerste hangt het heel erg af van de architectuur. AMD heeft met z'n hyperthreading namelijk een veel betere communicatie tussen de verschillende processoren dan intel ooit had met z'n multicpu solutions (en dan heb ik het over het P3 tijdperk, geen idee hoe het met de nieuwe chips is). Ten tweede zorgen alle threads op 1 CPU ervoor dat je cache sowieso veel minder effectief is omdat er veel meer contexts zijn waarin code wordt uitgevoerd (dus meer memory die wordt getouched, dus cache loopt sneller vol)

Bottom line is dat je er gewoon weinig over kunt zeggen; er zijn gewoon simpelweg teveel factoren.

[Tomb Raider: Underworld] - [Deus Ex 3] - [My javascript wolfenstein project]

Geplaatst op woensdag 08 november 2006 11:23

Acties:

Door: MBV

getfirefox.com

Berichten: 6802
Reg. datum: 02 februari 2002

als je het zelf hebt gedaan is het wat makkelijker te verhelpen dan wanneer intel het heeft gedaan.
Voor de compiler is het heel eenvoudig om rekening te houden met 80 of 1 core: een vlag voor welke processor je aan het bouwen bent

Voor jezelf is dat veel lastiger. En zelfs met 80 cores is het nog maar de vraag of een operatie de overhead waard is van extra I/O.

edit:
iosyn: hyperthreading is van intel, dat wannabe-2core gebeuren, weet je nog?

MBV wijzigde dit bericht 08-11-2006 11:25 (11%)

Is 40 dagen offline: zie homepage

Gathering of Tweakers

Update Tracker

Active Topics

Frontpage Nieuws