Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 163 reacties

Intel lijkt softwareontwikkelaars voor te bereiden op een verregaande uitbreiding van het aantal processorcores. Om een dergelijke strategie kans van slagen te geven, zouden programmeurs hun werkwijze drastisch moeten herzien.

Volgens één van Intels chipontwerpers, Anwar Ghuloum, zal de huidige trend van meer cores in processorontwerpen zich voortzetten: volgens hem zouden toekomstige cpu's over tientallen tot duizenden cores kunnen beschikken. Programmeurs zouden volgens Ghuloum met zo min mogelijk aanpassingen in hun algoritmes ternauwernood de mogelijkheden van dual- en quadcore-processors benutten: een strategie die op termijn ontoereikend zou zijn.

Ghuloum, hoofdontwikkelaar van Intel's Microprocessor Technology Lab, pleit dan ook voor programmeermethoden die rekening houden met meer cores dan zijn bedrijf momenteel in processors onderbrengt. Hij bepleit zijn stelling met het argument dat een dergelijke tactiek op termijn kosteneffectiever is dan het aanpassen van software naarmate meer cores per processor beschikbaar komen. Dat zou echter een fundamentele verandering in niet alleen de onderliggende algoritmes van software, maar ook de programmeertalen en libraries noodzakelijk kunnen maken. De daarmee gepaard gaande kosten die niet direct rendabel zullen zijn, zouden echter gecompenseerd worden door toekomstige voordelen voor schaalbaarheid.

Nehalem
Moderatie-faq Wijzig weergave

Reacties (163)

threaded programmeren is het lastigste wat er is in programeer landschap.
Eerst het uitsplitsen wat er threaded kan is al lastig maar dan met data integriteit rekening houden goeie synchronized locks gebruiken. Het "Before" en "After" goed snappen er zijn zoo veel hele kleine dingen dat dit gewoon heel heel lastig maakt en heel snel bugs kan bevatten. En het probleem is dat die bugs niet heel makkelijk te reproduceren zijn. Ze komen misschien voor. Als je zelf aan het testen bent komen ze nooit voor maar de load wordt wat hoger en bang 1 op de 1000 keer gaat het goed fout...

Daar komt nog bij als dat alle GUI libs die ik ken allemaal single threaded zijn. Dus alle gui related dingen MOET je in de Event Thread doen. Ook dit is weer lastig want dan kun je een mouse click bv wel snel in de achter grond gooien maar alles wat weer terug praat naar de gui moet dan weer in de event thread. En als dat weer moet wachten op user input...

het wordt er allemaal niet makkelijker op. Maar misschien vloeien de niet zulke goeie programmeurs wel af.. en is er meer werk voor mij ;)
Ik denk inderdaad dat dit voor veel programmeurs een lastig punt gaat worden. Je kan wel leuk meerdere threads aanmaken en overal semaforen omheen gaan hatseflatsen maar van een kluitje wachtende semaforen wordt je software niet per definitie sneller. Sterker nog, wel zullen meer te maken krijgen met problemen zoals deadlocks, resource starvation, threads die variabelen gebruiken die een andere thread nog diende te initialiseren, of weet ik wat voor concurrency problemen er nog meer allemaal zijn.

Ik hoop daarom ook dat Intel zich met deze boodschap richt op de meer low-level programmeurs en engineers die aan compilers werken. Misschien dat we in de toekomst programmeertalen krijgen die expressief genoeg zijn om optimalisaties op het gebied van parallellisme te kunnen automatiseren.
Daar komt nog bij als dat alle GUI libs die ik ken allemaal single threaded zijn.
En daar moet dus juist verandering in komen. (Al zijn GUI-libs misschien niet direct de meest voor de hand liggende libs om aan te passen.)
artikel:
Dat zou echter een fundamentele verandering in niet alleen de onderliggende algoritmes van software, maar ook de programmeertalen en libraries noodzakelijk kunnen maken.
Je kan wel leuk meerdere threads aanmaken en overal semaforen omheen gaan hatseflatsen maar van een kluitje wachtende semaforen wordt je software niet per definitie sneller.
Doe jezelf een plezier en koop The Art of Multiprocessor Programming, en leer over lock-free synchronization.

Het idee is dat je nooit semaforen moet gebruiken en ook geen extra threads moet aanmaken. In plaats van één taak per thread te hebb en te vertrouwen op het besturingssysteem om die te schedulen en synchroniseren, gebruik je beter slechts even veel threads als er cores zijn, en zorg je op applicatieniveau voor het schedulen van verschillende taken op een thread.

Dus per thread:

while(true)
{
Task task = getReadyTask(scoreBoard);
execute(task);
updateFinished(scoreBoard, task);
}

Indien je het scoreboard met lock-free synchronisatie implementeert (niet veel meer dan een lijst met taken - en lijsten zijn eenvoudig lock-free te maken), hoef je nooit naar het O.S. voor synchronisatie. Enkel wanneer alle taken op zijn kan je threads doen slapen en ze weer wakker maken wanneer er weer nieuwe taken zijn.
Intel kan waarschuwen wat het wil, maar de huidige generatie van programmeurs wil er gewoon amper aan. Zie hiervoor ook het vrij uitgebreide topic op got: [alg] Gebruik maken van multiple cores

Mijn hoop ligt bij een nieuwe generatie programmeurs die gewoon opgroeien met het idee dat parallel programmeren bij het ontwikkelwerk hoort.

Laten we eerlijk wezen, voor een programmeur die opgroeide met een single 68000 op 7Mhz en zijn hele leven sequentieel geprogrammeerd heeft blijft multi core iets raars. Iets waar je van weg moet blijven. Iets wat je alleen nodig hebt bij extreme scientific algorithms. Dat krijg je er gewoon niet uit. Ik probeer het bij collega's, maar stuk voor stuk... ze denken allemaal dat b.v. Java het volledig automatisch voor ze gaat doen...
Heeft niks met de huidige generatie van programmeurs te maken. Multi-process programmeren is lastiger dan SP, en zal altijd zo blijven. Als het aan software developers lag zou het gewoon SP blijven, want zij hebben er absoluut geen baat bij. Hardware developers lopen gewoon tegen natuurwetten op (zal ze leren om voor een minder puur wetenschapsgebied te kiezen.).
Heeft niks met de huidige generatie van programmeurs te maken. Multi-process programmeren is lastiger dan SP, en zal altijd zo blijven
Ik ben oud genoeg om nog net de kreten van de vorige generatie programmeurs te kunnen herinneren. Die zeiden grofweg hetzelfde: "OO programmeren is lastiger dan procedureel, en zal altijd zo blijven".

Parallel programmeren hoeft absoluut niet moeilijker te zijn. Net zoals objecten aan kunnen sluiten bij een natuurlijke gedachte gang, zo kunnen parallelle processen dat ook. Het kan eenvoudiger zijn als iets in een aparte thread draait, omdat dat process dan ook echt geïsoleerd is van de andere dingen die er binnen je applicatie gebeuren.

Zo heb ik b.v. een applicatie waar een thread op de achtergrond periodiek een andere server checked voor bepaalde events (polling) en bij veranderingen een globale structuur update. Andere threads die deze data willen benaderen doen dat via -1- guarded method die een (thread safe) copy teug geeft.

Dit update process via een thread laten lopen is werkelijk makkelijker dat het niet via een thread te doen. De access methods regelen eenvoudig, maar strak de toegang. Dit is sowieso een goede practice, zelfs in een single threaded applicatie.

Zodra locks, barriers, blocking queues, etc een 2de natuur voor je zijn geworden is het echt niet bijzonder moeilijk om te programmeren. Je moet je afhankelijkheden en data stromen strak kunnen definiëren. Kun je dat niet dan val je waarschijnlijk af als je parallel moet gaan programmeren, maar eigenlijk was je dan waarschijnlijk ook al niet zo geschikt voor single threaded programmeren. Ook daar is lukraak allemaal variabelen van waarde veranderen niet al te best voor de onderhoudbaarheid van je code.
Een thread safe copy maken is niet in alle situaties geschikt.. Neem een IDE zoals NetBeans of Eclipse, deze compileren een tekst die aan veranderingen onderhevig is. Snel een kopie maken van de ingevoerde tekst is leuk bij een tekst van enkele kilobytes, bij een megabyte wordt het al minder leuk ... nog leuker wordt het als de resultaten van de parser (die dus in een andere thread loopt) gemerged moeten worden met de geedite tekst. Voor dit laatste moet de geedite tekst geblokkeerd worden.

Ik heb zelf een vrij eenvoudige variant geschreven van een tekst-editor die op de achtergrond parsed ... en eenvoudig een 100% kopie maken van de tekst is inefficient. Een goede combinatie van welke data thread-safe is (geshared kan worden over alle threads) en welke data een read/write lock mechanisme nodig heeft is zeer belangrijk. En ik ben van mening dat de taal cq de compiler hier enorm kan helpen (en synchronized in Java is niet voldoende). En ik ben ook van mening dat MP programmeren 1 dimensie (en misschien wel 2) extra toevoegd aan SP programmeren.
Ik ben oud genoeg om nog net de kreten van de vorige generatie programmeurs te kunnen herinneren. Die zeiden grofweg hetzelfde: "OO programmeren is lastiger dan procedureel, en zal altijd zo blijven".
Jou leeftijd boeit me niet veel. Maar OOP is in veel opzichten lastiger dan procedureel. Programma structurering is opeens veel belangrijker geworden, en dat is best lastig. OOP heeft veel problemen van procedureel programeren opgelost, maar het heeft er ook een hele boel niet geintroduceerd. Met AOP kunnen veel van de OOP problemen opgelost worden. AOP is lastiger dan OOP, want het introduceerd weer een nieuwe abstractie laag.

1 belangrijke eisen van echt MP is dat er _geen_ global state is. Als je een global state introduceerd is je software een heel stuk minder schaalbaar. Zeker als je naar duizenden cores gaat. Tenzij je 1 super krachtige core hebt die je global state kan beheren. Je kan wel met copies werken, maar dat introcueerd weer enorm veel overhead en de standaard concurrency issues as meerdere copies gecommit worden.

read-only MP is makkelijk
Probeer nu maar eens deze applicatie efficient over >100 cores te verdelen... Quasi onmogelijk om dat manueel voor het merendeel van de applicaties te doen.
Volgens mij denk je verkeerd

i..p.v. 'hoe kan ik het proces verdelen over 1000 cores?'

zou je je moeten afvragen

'hoe kan ik het proces verdelen over zoveel mogelijk (als zinvol is) treads?'


Het is onnozel om je proces onnodig op te delen, de applicatie wordt zelfs langzamer, en aan de andere kant, als je teveel treads hebt wordt de boel vanzelf gecued.

Het is maar net wat nuttig is :D

<edit>
het beste is om je app een thread te laten spawnen wanneer nodig is (of forken)

[Reactie gewijzigd door j0nathan op 3 juli 2008 00:32]

Dit was gewoon een voorbeeld om aan te geven dat manueel je applicatie over threads verdelen niet meer opgaat voor het merendeel van de applicaties eens je over xtallen cores begint te spreken.
En nu kan je inderdaad nog makkelijk weg komen met een single thread applicatie, maar als je een cpu hebt met honderden cores die elk individueel maar de performantie hebben van een oude celeron cpu dan wil je dat je applicatie op een of andere manier (liefst zo simpel / automatisch mogelijk, tijd is geld) toch verdeelt kan worden over zoveel mogelijk cores ==> paradigm shift.
Veel programmeurs willen best ontwikkelen voor multi-cores. Hellas is het (nog) veel te moeilijk.

De kunst is dus om het simpeler te maken.


Vroeger moest je nadenken over het vrijgeven van het geheugen na je programma. Tegenwoordig heb je automatic garbage collection (bijv. in Java). Hetzelfde moet je zien te bereiken met parallel computing.

De oproep van Intel is zo gek nog niet.
Vroeger moest je nadenken over het vrijgeven van het geheugen na je programma. Tegenwoordig heb je automatic garbage collection (bijv. in Java).
Een grove misconceptie als je het mij vraagt (sowieso bedoel je tijdens je programma, daarna boeit het eigenlijk niet meer zo ;)). Geheugen is een resource, net als een file op disk, een netwerkverbinding, etc.. Dat je in Java niet meer na hoeft te denken over het physiek vrijgeven van geheugen wil nog niet zeggen dat je in z'n geheel niet meer na hoeft te denken over de lifetime van je resources. Veel Java applicaties, vooral van de beginnende programmeurs, zitten nog vol met resource leaks en gebruiken veel meer geheugen dan nodig, "omdat je er toch niet over na hoeft te denken".

Diezelfde fout moet met parallel programmeren ook niet gemaakt worden, en flowerp stipte het zelf al aan: "dat lost de compiler wel voor me op". Het zou mooi zijn als dat altijd zou werken, maar de praktijk heeft bewezen dat dat gewoon niet het geval is. Code moet ervoor ontworpen zijn. Als ik de volgende implementatie van een faculteit-functie maak:
f(n) := n * f(n - 1)
f(0) := 1
Dan is er geen compiler die dat kan parallelliseren, omdat elke stap afhankelijk is van de vorige (en dus inherent sequentieel en dus singlethreaded).
@ .oisyn

Uiteraard geldt bij parallel processors aansturen dat je binnen de door jou gestelde functie geen / slecht meerdere processors zou kunnen gebruiken ter optimalisatie van de snelheid. (als meerdere processors serieel geplaatst zouden zijn zou dit voor jou situatie bijvoorbeeld ook een hogere doorvoer kunnen opleveren; het nadeel van jou voorbeeld is alleen in deze dat het aantal keren van het doorlopen van de functie variabel is)

Bij parallelle coding moet het echter uit parallel af te handelen onderdelen bestaan.
Als je de door jou genoemde functie met meerdere n waarden zou willen uitvoeren zou je iedere uitvoering door een andere core kunnen laten afhandelen, hetgeen sneller het resultaat kan opleveren..
Een toepassing van een goeie vorm van caching zou je daarnaast versneld het antwoord kunnen geven van een functie die al eerder is uitgevoerd.
(Eerst n=99 en daarna n=100 berekenen zou met een goede caching voor 99% snelheidswinst moeten zorgen bij het ophalen van het n=100 resultaat)

Het probleem zit hem vaak echter in het garanderen van de serialiseerbaarheid van de parallelle verwerkingen.
Vergelijkbare problemen komen voor binnen database systemen en worden d.m.v. transacties gewaarborgd.
Het nadeel van transacties is echter een flinke beperking in je mogelijkheden om te parallelliseren.
Je zal naar een vergelijkbaar systeem toe moeten wil je goed met meerdere cores om kunnen gaan.

Situaties waarin parallellisatie eenvoudig en goed benut kan worden zijn bijvoorbeeld image rendering (Video bewerking / In game berekeningen uitvoeren die bepalend zijn voor de weer te geven beelden)

Situaties waarin dit slecht te realiseren is zijn o.a. faculteit functies (een goede caching zal daarvoor beter kunnen werken; bijvoorbeeld via opslag van variabelen en resultaat in databases); andere functies waarbij het resultaat afhankelijk is van het resultaat van zijn voorganger.
In de meeste lussen zal het gebruik van parallellisatie "gewenst" worden en zal dit weinig problemen opleveren wanneer gegarandeerde seriële afhandeling niet nodig is; is dit nl. wel het geval dan is een soort transactie manager een vereiste.
Je mist het punt.

Vroeger moest je nadenken over garbage collection, nu gaat dit ' automatisch'

Nu moet je nadenken over multithreading, later gaat het automatisch.

Maar of jij nu na moet denken over parallel processing of de ontwerper van de compiler, maakt dat wat uit ?

Een van de twee moet anders gaan denken. En dus moeten er andere technieken komen. En over enkele jaren snap je niet eens meer hoe je het met slecht een processor op kon lossen.
Op compiler niveau mutithreaden zal er zeker komen of is er al. Bepaalde code blokjes die goed herkenbaar zijn, en easy op te splitsen kan de compile zelf doen. Complexe taken nog niet. Dus op hele fijne low level manier, doe je toch al aan multi threaden. De winst is natuurlijk niet veel aangezien alleen 'n deel(tje) van de code geparaleliseerd wordt. Wat neer komt op 'n specifiek code blokje even een boost krijgt. Om het veel beter en grootschaliger te doen, moet je taken die geschikt zijn voor parralelisatie zelf mutithreaded maken. En taken die dat oorspronkelijk niet zijn zodanig ombouwen dat meer parralelisatie mogelijk wordt.

Dus met het oplossen van 'n software probleem houd je al rekening hoe je dit Multithreaden kan doen. Dat zal niet altijd gaan en soms heel moeizaam. Of niet zo optimaal.

Uiteindelijk krijg je een target market waar single dual en quad oude chips geworden zijn en mainstream is zoiets als 16 of 32 als budged 48 en 64 als midrange en high-end 128 256 cores.

In die situatie zal de mainstream vraag naar adoptive multitasken aan de hand van aantal cores zeer gewenst zijn. En dan moet het meer. De software engeneers die dan uit de IT opleidingen ondertussen lopen zouden al Multithreaded zijn opgevoed. Tenzij studie weer eens mijlen ver achter loop op bedrijfs leven in de IT software enginering. En vetereanen moeten er ook aangeloven om er intesiever mee bezig te zijn. En mutitasken op 'n Core detecting manier wordt eerder 'n standaard software enginering requierment.

Over die garbage collector.
Als performance belangrijk is. Kan dan eventuel de programeur de tijd aangeven wanneer de garbage frequenter geleegd wordt in minder critische tijd stippen. Dus niet automatisch een grote collectie even vrijgeven. Maar in kleine frequente stappen.
Of instances her gebruiken.
Door 'n object manager die objecten met 'n bool bfree; hergebruikt en opnieuw initialiseerd en dus 'n herboren object wordt. waardoor je de garbage collecting minimaliseerd. En ermee ook geheugen fragmentatie tegen gaat.
Geheugen pool zal vaker bij PC geen probleem zijn genoeg reserve.
Bij consoles met hun 512. niet zo.
Vroeger moest je nadenken over garbage collection, nu gaat dit ' automatisch'
Blijkbaar mis jij het punt, want mijn punt is dat je "garbage" (lees: resources) nog steeds niet goed wordt opgeruimd. Je weet alleen dat het "uiteindelijk weleens een keer gebeurt". Maar dat wist je toen ook al, namelijk als je je applicatie afsloot. Als jij een reference naar een nogal heavy-weight object laat rondslingeren terwijl je hem eigenlijk niet meer nodig hebt, gaat de GC niet voor jou beslissen dat hij maar opgeruimd kan worden. Denken dat een GC al je resourceproblemen voor je oplost is een misconceptie en een uthopie. Zo ook bij denken dat een compiler jouw code fatsoenlijk gaat parallelliseren zonder dat jij daar expliciete hints voor gaat geven over hoe het moet gebeuren.

[Reactie gewijzigd door .oisyn op 2 juli 2008 23:48]

Als jij een reference naar een nogal heavy-weight object laat rondslingeren terwijl je hem eigenlijk niet meer nodig hebt, gaat de GC niet voor jou beslissen dat hij maar opgeruimd kan worden.
Als ik een kist met rottend fruit op mijn eettafel laat staatn wordt deze ook niet automatisch opgehaald door de afvaldienst. Kortom als jij iets niet bestempeld als zijnde afval zal niemand het komen ophalen. Er kunnen inderdaad 'leaks' ontstaan in je programma door rondslingerende referenties. Dat wil niet zeggen dat een Garbage Collector zoals Java kent het de programmeur wel een stuk gemakkelijker heeft gemaakt. Zoals jezelf ook al aangeeft hints in een programmeertaal kunnen veel helpen.

@jvo
Om je commentaar kan ik zowel lachen als ook huilen. Een paar templatjes bouwen is echt niet voldoende om zaken goed te paralleliseren net zo min als het ervan uitgaan dat een bepaalde bibliotheek dergelijke zaken voor je oplost. Naar mijn idee heb je nog weinig kaas gegeten van multithreaded programeren
Een garbage collector moet je eigenlijk zelf aansturen. Ik werk zelf vaak in Java. (Niet voor games.) Je moet weten wanneer er ruimte is om op de ruimen, de referenties weghalen en de GC aanroepen. Scheelt eigenlijk niet veel van een situatie waarbij direct geheugen vrijmaakt.

@DikkeDouwe
Ik wil niet zeggen dat een paar templates voldoende zijn. Ik wil zeggen dat een basissysteem voor het gelijktijdig laten draaien van taken herbruikbaar is. Je zal uiteindelijk zelf moeten bepalen wat parallel te draaien is of parallel te maken is. Oh, en ik doe het regelmatig, maar dan moet ik het wel in het ontwerp meenemen natuurlijk. Dat is het belangrijkste. Achteraf voeg je het niet even toe.
Ik zeg niet dat een compiler parallel computing even gaat oplossen. Ik zeg niet dat garbage collection een perfecte oplossing is.

Ik zeg dat garbage collection inmiddels redelijk werkt, in tegenstelling tot de jaren 80, toen moest ik nog echt nadenken omdat ik maar 1K had.

Ja, als je niet nadenkt, gaat het nog steeds mis. Maar het is stukken verbeterd. Uiteindelijk zal je nog steeds moeten nadenken als je gaat programmeren, maar er zal in de nabije toekomst een situatie ontstaan waarbij we rekening mogen/moeten houden dat er multi-cores zijn en daar kunnen we maar beter rekening mee houden, want voorlopig zie je echt geen verbetering in het aantal Ghz.
Kijk, dit vind ik dus irritant: kereltjes die komen roepen dat garbage collection de oplossing is, en denken dat men tegenwoordig niet meer hoeft na te denken over geheugen efficiëntie. Vreemd genoeg zijn het diezelfde kereltes die komen klagend dat bv hun PC Crysis niet kan draaien, en het de schuld is van de programmeurs die niet efficiënt genoeg programmeren...

wake-up call: efficiënt programmeren en automatische garbage collection (en Java in zn geheel als je het mij vraagt) gaan NIET samen.

Jouw geloof dat men nu niet meer nadenkt over geheugenallocatie, en later niet meer over multithreading, is dus een bizar naïeve droom.
Wake- up call : niet iedereen die een voorbeeld geeft over garbage collection is een kereltje.

Het zelf (moeten) vrijgeven van overbodige resources heeft niets te maken met efficient programmeren.

Ik laat het aan jouw discretie over of het in Java goed geimplementeerd is, maar in principe maakt het niets uit of je dit vrijgeven zelf goed doet of een ander het goed doet.

Tenzij je op het standpunt staat dat het alleen maar goed is als je alles (dus inclusief de compiler) zelf geschreven hebt.

Mijn geloof is niet dat men niet meer na hoeft te denken over geheugenallocatie of multithreading. Mijn geloof is wel dat beide (tzt) beter geimplementeerd zullen zijn zodat in 80/90 procent van de gevallen dit redelijk simpel te implementeren is.

Goed en efficient programmeren zal (uiteraard) altijd een kunst blijven.
persoonlijk vind ik het juist heerlijk om precies te weten in mijn programma's wanneer welk geheugen 'weg' is en wanneer er wat in staat. Ik denk er dus wel degelijk over na als ik calloc/malloc/free. Daarmee programmeer ik efficienter, en niet als een of andere garbage collecter zomaar mijn geheugen wist/vrijgeeft.
Tja, ik vind programmeren in Assembler ook heel fijn. Het neemt wel veel meer tijd in beslag, en over het algemeen zal de code meer bugs bevatten dan geschreven in een hogere programmeertaal (bij gelijke complexiteit van het programma natuurlijk). Waarschijnlijk werk je aan Opera die na een paar uurtjes draaien 500Mb intern geheugen nodig heeft (ben even de bron vergeten, maar het kwam hier niet zo lang geleden nog voorbij)?
Enne, een gc geeft geheugen niet "zomaar" vrij. Dat doet ie alleen als er geen referenties meer naar zijn, maw. als je er zelf ook niet meer bij kunt.
Het maakt wel degelijk uit of je hetzelf doet of de Garbage collector en waar het uitmaakt is performance.
De garbage collector kan beslissen om tijdens een zeer CPU intensieve operatie te gaan garbage collecten. In een time critical applicatie is dit niet wenselijk en zeer storend.
Als je zelf je geheugen los laat kun je garanderen dat de CPU niks aan het doen is in deze situatie.
Een van de redenen waarom de meeste AAA games nog steeds in C++ worden gedaan en niet in een GC taal is performance.
En zoals hieronder ook al wordt aangegeven is het bijhouden van referenties nog steeds noodzakelijk ook in GC talen.

[Reactie gewijzigd door NC83 op 3 juli 2008 01:05]

Mwah, het is een kwestie van een soort van template hiervoor. Is in mijn ogen net zoiets als undo/redo ondersteunen. Kwestie van een aantal basisklassen en daarna is het niet veel extra werk. In die zelfde lijn kan je de "acties" die je programma doet ook parallel maken met een standaard setje klassen die er voor zorgen dat dat geregeld wordt. Een soort van scheduler dus. Hangt wel af van het soort programma natuurlijk. Het heeft geen nut te proberen en enkele faculteitsberekening proberen parallel te maken. Wel kan je 100 (onafhankelijke) faculteitsberekeningen naar de scheduler sturen. Of beeldbewerkingen per blok van 64x64 pixels. Etc. Kwestie van het werk iets verder opdelen.
Twee belangrijke dingen zijn gaande: 1) De chipbakkers hebben moeite om 1 hele snelle kern te maken, dus maken we er -tig minder snel. 2) Huidige programmeertalen en hun compilers zijn niet gebouwd met multicore systemen in het achterhoofd.

Programmeurs gaan vermoeien met het drama dat multithreading heet is onzin. Geen enkele serieuze software toko die daar in zal investeren. Voor maar wenige applicaties is multicore-support werkelijk interessant, omdat het ook prima kan lopen op een single-core.

Dus op naar betere comilers en wat aanpassingen aan huidige talen, daar zal het grootste verschil gemaakt kunnen worden.
Erg kort door de bocht geredeneerd. Single-threaded werken is een gevolg van het feit dat men zulke ingewikkelde CPUs vroeger niet kon maken. Dus moest je allerlei truuks uithalen om ervoor te zorgen dat je toch dingen semi-parallel kunt doen.

Taken verdelen is in veel gevallen gewoon slimmer (wat denk je dat sneller klaar is: een muur van 100 meter waar 100 man serieel - d.w.z. meter voor meter - aan werkt of een muur van 100 meter waar 100 man parallel aan werkt - d.w.z. iedereen doet tegelijkertijd een meter).

Ja, je moet je van een aantal zaken bewust zijn die feitelijke allemaal neerkomen op één simpel principe: zaken kunnen ineens asynchroon gebeuren (d.w.z. buiten een simpele sequentie van opdrachten).

Tot op zekere hoogte zul je dat met betere compilers kunnen oplossen, maar naast het feit dat die ook geschreven moeten worden, moet je als programmeur ook gewoon snappen wat er gebeurt.
Nee IOrien heeft helemaal gelijk. De klok snelheid van micro processoren lopen te limit van de golflengte op. Plus optimaal gebruik maken van het aantal transistoren, wat nog steeds toeneemt, wordt ook steeds complexer.
Oplossing: maak een kleine core en stop er heel veel van in een IC.

Nieuwe probleem: hoe programeer ik dat ding?
de huidige programeertalen zijn allemaal sequentieel van opzet. C C++ VB Java.
b.v. C is niet thread safe.

Dat de compiler even de code parallel maakt is wel een hele simpele veronderstelling.
Ook de veronderstelling dat als je 100 processoren hebt het 100 keer sneller gaat dan een processor is fout.
Zie http://en.wikipedia.org/wiki/Amdahl%27s_law
Parallel processen is niet iets van de laatste tijd al tientale jaren wordt er onderzoek na gedaan en er is maar een conclusie: HET IS MOEILIJK!!!!
Ik vind dat dat gewoon een taak van het OS of de box waarin de applicatie draait (dotnet/java) is. Dat moet maar zorgen dat de applicatie 500 miljoen cores kan gebruiken. Tegenwoordig distantieren we ons zo ver mogelijk van geheugenverbruik en dat soort zaken: daar moet de CLR van dotnet maar mooi voor zorgen.
Hetzelfde voor cores: ze doen maar!
En hoe ga jij het OS in godsnaam laten beslissen hoe hij jouw algoritme kan verdelen over verschillende threads?
een algoritme is sequentieel, en in veel gevallen kan het niet anders, dus het OS dit late analyseren is een quasi onmogelijke taak.
Dat "Java" het allemaal voor hen gaat doen is geen "raar idee" Dit is namelijk al mogelijk. Het gaat echter wel ten kosten van de performance ten opzichten van zelf geoptimaliseerd programmeren. ( Dit geld niet alleen voor JAVA )
Deels ben ik het met je eens en deels niet
Het ligt er maar heel erg aan waarvoor je programmeerd

Ik maak bijvoorbeeld web-systemen (PHP). Ik zou bij god niet weten hoe ik dat paralel zou moeten doen, als PHP het al ondersteunde. Bij webpagina's zit je de hele tijd op de IO te wachten. De data van files die je moet hebben, de data van de database,etc

Je kan niet paralel omdat je vervolgstappen afhankelijk zijn van die data waar je op zit te wachten.
Dit klinkt bij mij een beetje als een onzin verhaal. Er zit natuurlijk een kern van waarheid in dat de meeste applicaties hier geen gebruik van kunnen maken. Echter zijn het slechts enkele applicaties die hiervan gebruik zullen hoeven maken, namelijk de echte resource vreters. Ik denk dat zeker wanneer dit soort snelle processoren op de markt zijn, minder dan 5% van alle software veel resources nodig heeft om soepel te draaien. De meeste mensen zullen misschien gebruik gaan maken van meer dingen tegelijk, maar dat gaat vanzelf al goed als dit lichte programma's zijn.

Daarbij meen ik me te herinneren van de roadmap die Intel een aantal maanden geleden presenteerde dat ze werken aan processoren die een virtualisatielaag hebben. Waardoor er fysiek duizenden cores zouden kunnen zitten in een processor, maar dat er maar 1 zichtbaar is voor het OS. Als dat de toekomst is, dan is het sowieso bullshit om alle programmatuur voor te bereiden op het gebruik van veel threads. Zeker aangezien dit opzich al een stevige vertraging opleverd en het werk van een programmeur niet makkelijker maakt.
Er is helaas geen andere manier om hogere prestaties te halen dan om thread-parallelisme te benutten. Alle andere vormen van parallelisme zijn uitgeput en de kloksnelheid verhogen zit er ook niet meer in.

Maar het hoeft helemaal zo rampzalig niet te zijn voor de programmeur. Declaratieve programmeertalen, in tegenstelling tot imperatieve talen, lenen zich uitstekend om door de compiler afzonderlijke taken te identificeren en te verdelen over meerdere cores.

Kijk ook naar hardwarebeschrijvingstalen zoals VHDL. Alle bewerkingen zijn impliciet parallel, tenzij gesynchroniseerd met de klok of een ander signaal. In imperatieve talen is alles serieel, tenzij expliciet parallel. We moeten dus over gaan naar een vorm van programmeren die zich veel beter leent om op veel cores te draaien. SystemC is ook bijzonder interessant aangezien het om een bibliotheek in C++ gaat waarbij ook alle 'processes' parallel draaien, en dat schaalt dus ook nu al zeer goed met het aantal cores.
Echter zijn het slechts enkele applicaties die hiervan gebruik zullen hoeven maken
Correctie: het zijn slechts enkele applicaties van rond 2008 die hiervan gebruik zullen hoeven maken.

In 1980 waren er maar HEEL ERG WEINIG applicaties die 1MB geheugen nodig hadden. Betekent dat dat een geheugen van >1MB onzin is als je maar 1 programma draait.

Absoluut niet!

Een programma uit 1980 is amper meer te vergelijken met een programma van vandaag de dag en 32MB voor 1 programma knippert amper iemand voor met z'n ogen. 1MB voor 1 applicatie is vandaag de dag helemaal niets. Terwijl in 1980 een complete main frame amper 1MB geheugen had.
Ik snap de discussie niet zo. Ik vraag me af wat er zo moeilijk is aan rekening houden met multi cores. Volgens mij is het veel makkelijker om een zeker abstractie aan te houden en taken te scheiden. Efficiént load verdelen over 2 of meer cores is voor software ondoenlijk, en voor de programeur eveneens. Daarnaast draaien er gewoon al meerdere taken simultaan. Neem het volgende stuk code:

if (bSave=true) then begin
SaveFile(sFileName,pData);
UpdateRepository( sFilename, sNow, sComment);
end;

SaveFile duurt 10 seconden
Update repository duurt 5 seconden
Serieel = 15 seconden.

Als beide nu een als separate threads worden uitgevoerd, en er is een overhead van 1 seconde hiervoor dan zal het process zelf maar 11 seconden duren. 2 threads exrra, 4 seconden winst.

Code zou dan misschien worden:
if (bSave=true) then begin
pThrA= NewThread(SaveFile(sFileName,pData));
pThrB= NewThread(UpdateRepository( sFilename, sNow, sComment));
while (pThrA.running or pThrA.running) do;
Dispose(pThrA);
Dispose(pThrB);
end;

Een ander leuk voorbeeld is bijvoorbeeld een spel zoals C&C Generals. Wat als ieder soldaatje, ieder gebouwtje, ieder wagentje een eigen object is die in een eigen thread draait. Dan zullen de cores wel snel vollopen, maar dan hebben 100+ cores ook veel meer zin.
Maar jij mist je error-handling... Als je het in 1 thread doet, kun je code niet uitvoeren, maar in multi-thread moet je een roll-back gaan doen.

//Dit is single thread
if(bSave && SaveFile(sFileName, pData) == SUCCESS) {
UpdateRepository(sFilename, sNow, sComment);
}

In jouw voorbeeld heb je sowieso een probleem. Wat als het een groot bestand is en het duurt 1 sec om hem op te slaan?

ERROR: FileNotFoundException.

Dus ThrB zal moeten wachten op ThrA, dus in je voorbeeld doe je er 10+5+1 = 16 sec over!

Hij is wel te fixen, de kans is groot dat je je commit met een byte stream gaat doen, oftewel geef pData mee aan UpdateRep, maar dan nog zul je ook rollback code moeten genereren.
Het lijkt me niet verstandig om elke unit zijn eigen thread te geven, dat loopt wel erg snel uit de klauwen, en gebruikt een hoop nutteloze overhead. Je wilt stukken code die niet per sé achter elkaar hoeft parraleliseren (zoals de som van een grote array uitrekenen oid).

offtopic:
* wwwhizz gaat naar zn Parallel Computing tentamen
De problemen treden niet zozeer op als er constant parallel gewerkt kan worden, maar wanneer er gebruik moet worden gemaakt van inherent serieele resources, zoals (in het spelvoorbeeld) uitvoer naar het scherm, of disk I/O.

Je kunt al die wagentjes wel een eigen thread/core geven, maar op een gegeven moment (elke <n> milliseconden) moet er één compleet frame naar het scherm gestuurd worden. Op zo'n moment moet je synchroniseren. Als je dat niet goed opzet ben je alle voordelen van parallelisatie direct weer kwijt.
Dit komt goed overeen met wat ik laatst over Larabee tegenkwam; x86 (waarsch x64) stream processors.

Een hoop mini x86(-64) cores die individueel sloom, maar collectief snel zijn. Waarschijnlijk dan wel asymetrisch, een paar snelle cores voor legacy doeleindenen plus een hele hoop simpele. Productie yield vaart er wel bij, met het uitschakelen van defecte stream processors door redundantie.

Door gebruik van x64 instructieset word paralleliseren eenvoudiger (simpeler x64 dochterprocessen te starten, geen CUDA of close-to-metal nodig, een enkele compiler.).

(edit) te sloom getypt, leonpwner1 was me 5 minuten voor (/edit)

[Reactie gewijzigd door Toontje_78 op 2 juli 2008 22:40]

Tja... heel makkelijk gezegd dat software massief parrallel moet... maar in de praktijk is dat behoorlijk lastig.

Anandtech heeft een heel aardig voorbeeldje geleverd, bij het bespreken van de verschillen tussen ATI's RV770 en NVidia GT200:
http://www.anandtech.com/video/showdoc.aspx?i=3341&p=6

Het probleem is dit: Je kunt alleen meerdere cores tegelijk aan hetzelfde probleem laten werken, wanneer die onafhankelijke taken kunnen doen. Maar heel veel taken zijn niet compleet onafhankelijk. En dan wordt het heel lastig om te taken netjes te verdelen.


Eén ding is in ieder geval zeker... Een programmeur kan in zijn software geen duizenden cores afhandelen. Idioot om te vragen dat software developers daar aan gaan denken. Het ontwerp van een programma kan hooguit multithreaden over tientallen cores. Wanneer men aan honderden of zelfs duizende cores gaat denken, dan moet dat op een veel lager niveau gebeuren. En dat is dus niet iets waar de normale software programmeur over moet nadenken, maar waarover de software engineers van Intel moeten nadenken!!
Eén ding is in ieder geval zeker... Een programmeur kan in zijn software geen duizenden cores afhandelen. Idioot om te vragen dat software developers daar aan gaan denken. Het ontwerp van een programma kan hooguit multithreaden over tientallen cores. Wanneer men aan honderden of zelfs duizende cores gaat denken, dan moet dat op een veel lager niveau gebeuren. En dat is dus niet iets waar de normale software programmeur over moet nadenken, maar waarover de software engineers van Intel moeten nadenken!!
Fout. Je denkt hier te veel in termen van threads en locks. Je moet denken aan taken en afhankelijkheden. In declaratieve talen kan je die op eenvoudige wijze programmeren zodat je snel tot zeer veel onafhankelijke taken komt die met de hulp van de compiler harmonieus op meerdere cores uitgevoerd worden.

De sleutel is abstractie. Denk bijvoorbeeld even hoe je zou programmeren zonder functies, met enkel spronginstructies om naar andere stukken code te gaan (e.g. Unstructured BASIC). Dat wordt snel een onhanteerbare soep. Door een abstractie zoals functies in te voeren en tools zoals compilers te gebruiken die de effectieve addressen beheren is het heel wat simpeler. Zo ook met multi-threading. Zelf een tiental threads beheren wordt ook rap een soep, maar abstraheer het als taken en laat een scheduler ze in de juiste volgorde draaien op beschikbare cores en het wordt al snel veel overzichtelijker.
Eén ding is in ieder geval zeker... Een programmeur kan in zijn software geen duizenden cores afhandelen. Idioot om te vragen dat software developers daar aan gaan denken.
Stel, het doel van mijn programma is het comprimeren van een film. Mijn uitvoerbestandsformaat werkt door van ieder frame onafhankelijk te comprimeren en deze frames vervolgens weer achter elkaar te plakken. Neem dan de volgende code:

F = verzameling frames
herhaal X keer, met X = aantal cores op deze machine:
maak een thread die functie g gaat uitvoeren
wacht tot alle threads gestopt zijn

g():
while true:
lock F
als F is leeg: unlock F; stop
pak een frame uit F, noem hem f
unlock F
comprimeer f

Voila, een programma die bovenstaand probleem oplost en meeschaalt naar ieder mogelijk aantal cores.

Ik weet dat dit een overgesimplificeerd probleem is, dat het meestal wat moeilijker is, en dat niet alle problemen zich uberhaupt goed laten parallelliseren. Desalnietemin is het meestal niet _heel_ veel moeilijker dan dit voorbeeld.

[Reactie gewijzigd door RedLizard op 3 juli 2008 00:52]

Daar heb je een voorbeeld van een beschamend parallel problem.

Die zijn niet te moeilijk te programmeren (Matlab heeft die functie iig voor for lussen, evenwel had ik op dat moment geen multii core ter beschikking om taken parallel op uit te voeren))
Er zijn veel reacties in de sfeer van prestatieverhoging. Logisch want dat is natuurlijk het hele doel van het gebruikmaken van meerdere cores. Het blijkt echter enorm moeilijk te zijn om multi-threaded te programmeren. In de ideale wereld bevat een cpu dus één supersnelle core die alles in zijn eentje afhandelt. Waarom nemen we dat dan niet als uitgangspunt?

Laten we eens naar de huidige stand van zaken kijken. De mainstream processors zijn nog steeds x86-gebaseerd, in feite een enorm verouderde architectuur die duidelijk tegen zijn grenzen aanloopt. Er bestaan alweer een poosje veel snellere en efficiëntere architecturen, waaronder IA64, die de bijbehorende native software veel sneller kunnen draaien dan x86 met al zijn uitbreidingen en optimalisaties. Misschien moet de industrie toch maar 's overwegen om de grote stap naar bijv IA64 te pushen. Groot nadeel is weliswaar dat alle bestaande x86-software dan geëmuleerd moet worden en dat is, zacht gezegd, traag. Het gevolg is echter ook dat de stimulans om voor IA64 te programmeren en compileren enorm zal zijn, nog veel groter dan bij x86-64. Een groot nadeel met een groot voordeel dus.

Nu ben ik absoluut geen expert op dit gebied, verre van zelfs. Ik weet wel dat je doorgaans het probleem in de wortel moet aanpakken. Multi-cores komen op mij heel erg over als een cosmetische ingreep om een inherent probleem van iedere core afzonderlijk te pogen te omzeilen. Ik vind het daarom behoorlijk opvallend hoe conservatief zelfs de IT-wereld, mogelijk de meest turbulente industrie die er bestaat, over kan komen.

[Reactie gewijzigd door 2fish op 3 juli 2008 01:41]

Het concept van één supersnelle core die alles in zijn eentje afhandelt, is gewoon datgene wat we tot nu toe altijd gehad hebben. En dat concept loopt zo langzamerhand tegen de limieten aan van wat nog zinvol is.
hmm, wanneer zouden we bij 1000 cores belanden dan?

[hypothesis mode]
er van uitgaande dat met elke verkleining van het procede twee keer een verdubbeling plaatsvind van het aantal cores:

65nm 1x, 2x
45nm 2x, 4x
32nm 8x, 16x
22nm 32x, 64x
16nm 128x, 256x
11nm 512x, 1024x

11nm wordt ergens in 2015 verwacht.
[/hypothesis mode]
twee keer een verdubbeling
Elke verkleining maakt plaats voor ongeveer twee maal zoveel transistors.

90 nm 1-2 cores
65 nm 2-4 cores
45 nm 4-8 cores
32 nm 8-16 cores
22 nm 16-32 cores
16 nm 32-64 cores
11 nm 64-128 cores

Om dus sneller tot 1024 cores te geraken moeten de cores zelf kleiner. Dat kan bijvoorbeeld door out-of-order-execution achterwege te laten. Een enkele core is dan minder krachtig, maar omdat op hetzelfde oppervlak er vier of acht keer meer passen is de totale rekenkracht groter.

Toch heb ik daar mijn bedekingen bij of dit zal gebeuren voor de desktopmarkt. Het zal niet zomaar geaccepteerd worden dat single-threaded software trager gaat lopen. Kijk bijvoorbeeld naar AMD's Phenom processoren. Om ze native quad-core te maken hebben ze de cores zelf niet bijzonder sneller gemaakt en ook op cache bespaard. Intel's dual-cores zijn echter populairder omdat de Core 2 architectuur meer werk kan verrichten omdat die complexer is met meer cache.
daar heb je wel een punt daarom moeten developers zorgen dat hun software een onbeperkt aantal cores ondersteunt en zorgen de taken effiecient verdeeld worden op de cores en de laatste instructie sets ondersteunt worden anders zie je inderdaad maar weinig prestatie winst. ook mogen de meeste developers onderhand x64 bit wel gaan ondersteunen want dat heeft ook zeker wel zijn voordelen tegenover x86.
daarom zou het denk ik als zowel intel als amd development tools leveren aan software bouwers zodat deze beide architecturen makkelijker volledig kunnen gaan benutten.
Aantallen cores hebben niets te maken met de grootte van het procede. GPU's zitten op een groter procedee dan CPU's, maar hebben veel meer cores.

De kwestie is gewoon dat parralelle systemen potentieel efficienter omgaan met het aantal transistoren/oppervlakte, mits je ook inderdaad voor elkaar krijgt dat al die cores ook inderdaad aan het werk kunnen worden gehouden.

Afhankelijk van de toepassing, kun je dus gewoon besluiten om meer cores te draaien. Precies wat GPU's al jaren doen. Intel kast best nu een CPU met duizend cores maken. Zou alleen totaal nutteloos zijn, omdat de software er geen gebruik van kan maken.
Toch zie ik liever dat de CPU de zaken afhandelt alsof deze één core heeft. Zijn we meteen van dit programmeer probleem af. Hoe simpler, hoe beter.
De zaken afhandelen alsof het één core heeft, is nu juist het hele probleem. Dat is precies wat men de afgelopen 20 jaar gedaan is. Men heeft intern uiterst ingewikkelde slimme CPU's gemaakt, die naar buiten toe heel simpel lijken. Maar er zijn limieten over hoe ver je daar meer door kan gaan. Het wordt steeds inefficienter om dat te doen.

Een paar jaar geleden is mijn tot de conclusie gekomen dat dat een heilloze weg is. De limiet van die methode is gewoon bereikt, en het is gewoon noodzakelijk dat de software specifiek voor multicore geschreven wordt. De huidige CPU's zijn multi-core, omdat het pure verspilling van transistoren zou zijn om nog single core te bouwen.
Chip Multi-Processor Scalability for Single-Threaded Applications (2005)

Zelfs al gooide men alles in de strijd om de single-threaded prestaties te verbeteren, dan zou men na 3-5 jaar tegen de absolute limiet aanlopen.

We kunnen er dus absoluut niet omheen om multi-threaded te gaan. Dat men het nu al doet in plaats van over 3-5 jaar is omdat de totale prestaties hoger kunnen zijn dan op een complexe single-core, mits wat inspanning van de programmeur.

[Reactie gewijzigd door c0d1f1ed op 3 juli 2008 00:32]

iets in de trant van 128 bits processing voor een quadcore oid.. en dan alle programma's native 128 bits geven.. etc..
gewoon grotere instructies tegelijk kunnen uitvoeren, ipv vele kleine tegelijk.

32 bits gaat er sowiso uit, net als 16 bits, 13 jaar geleden.
Complete onzin, helaas. Je hebt net VLIW beschreven. Dat is hoe de Itanic werkt, 128 bits instructies & speculatieve uitvoering. En kijk eens hoeveel tweakers nu een Itanic PCtje hebben.
16 bits ging eruit omdat het al snel niet meer simpel was. 16 bits is 64KB, voor 640KB had je al 16+16 bits nodig (8086). De stap van 16+16 naar 32 bits is logisch, dat maakte zaken een stuk simpeler. Het aantal apps wat meer dan 4GB nodig heeft is erg klein; daarnaast hoeft alleen het OS 64 bits te zijn. Het voordeel van 32 bits adressen tov 64 bits is namelijk dat je twee keer zoveel pointers in je caches kwijt kunt.
Om dezelfde reden heeft ARM naast de originele 32 bits instructies ook 16 bits instructies ingevoerd (Thumb ISA). Meer bits is niet altijd beter; soms is minder bits juist sneller.
Het probleem is dat CPU's dit al jaren doen. En alles wat er daarmee aan performance uitgeperst kon worden is er al uitgeperst.
Waarom doen ze dan niet hetzelfde als GPU bakkers? gewoon ervoor zorgen dat meerdere cores door de software wel als 1 core worden behandeld. Snap ook niet dat ze dat niet doen. Als je een beetje logisch nadenkt moet je zelf toch ook wel begrijpen dat het niet te doen word om straks een programma te maken wat bv goed werkt op pc's met tussen de 4 en 40 cores om maar even wat te noemen.
Waarom doen ze dan niet hetzelfde als GPU bakkers? gewoon ervoor zorgen dat meerdere cores door de software wel als 1 core worden behandeld.
Dat is een software-abstractie geen hardware-abstractie. De programmeurs van de drivers van de GPU hebben even goed te maken met een chip die honderden zoniet duizende threads draait, alsook CUDA programmeurs. Maar voor grafische zaken is dat relatief gemakkelijk omdat er nu eenmaal miljoenen pixels te verwerken zijn. SwiftShader schaalt ook naar meerdere CPU-cores zonder dat de applicatieprogrammeur zich daar iets van hoeft aan te trekken.

In de toekomst gaan we denk ik meer en meer bibiliotheken zien die naar de buitenwereld een eenvoudig serieel verwerkingsmodel hebben maar binnenin een complex spel van onderverdeling in subtaken en het schedulen op meerdere cores spelen.
Even heel simpel gesteld :

Een programma bestaat uit 10,000 regels programmacode. Als we die tegelijktijd af kunnen handelen (ik weet het het is een erg simpele veronderstelling) duurt het op een dual core 5,000 kloktikken en op een 1,000 core slechts 10 tikken.

Moeten we alleen anders leren denken dan in

IF A
Then
ELSE
B

Willen we de kracht van multicores kunnen gebruiken, dan moeten we op een andere manier gaan programmeren. En we moeten wel, want we kunnen met de huidige technieken niet veel sneller in kloksnelheid, maar nog wel in aantal kernen.
Daar denk jij ook te simpel.

Neem het volgende:

If A=0 then
begin
<Code 1>;
end
else
begin
<Code 2>;
end;

Hierin moet je wel weten WAT A is. Oftewel, de uitkomst van A zal wel bekend moeten zijn voor je verder kan. Hoeveel cores je ook hebt en hoe goed je Code 1 en 2 ook hebt geprogrammeerd om met alle cores te werken, zolang je A niet weet kun je gewoon niet verder.

Je zou wel kunnen voorspellen en al heel wat voorwerk kunnen doen. De efficiëntie gaat wel achteruit aangezien je dan zowel Code 1 als Code 2 moet uitvoeren. Als je dan A weet dan kun je 1 van de 2 uitkomsten pakken, echter:

Wat als Code 1 en Code 2 de variabele A gebruiken... Dan kunnen ze ook daar weer niet verder.

Je merkt wel dat dit een zeer ingewikkeld in elkaar zit. Er zijn wel oplossingen bedacht maar ik vraag me af of het echt effectief is en werkt. Code wordt nog altijd aan de hand van een flowchart ingevoerd en een computer werkt nog steeds op basis van 1 en 0, wel of niet, true or false.

Bij een flowchart is het ook zo dat alles na elkaar komt, je moet tenslotte weten wat de uitkomst van de vorige stap is voor je die kan verwerken. Je kan software wel opslitsen, maar dan hebben we het over threads die geen verband met elkaar hebben. Je kan vast wel begrijpen dat je op het laatst niet meer threads kan verzinnen om je CPU aan het werk te houden.

Nee, dan zijn rouwe GHz-en aan kracht nog steeds de enige optie om het echt sneller te krijgen. In mijn ogen zit x86 aan zijn limiet. Kijk maar wat Intel van plan is met Larrabee (zie hierboven), AMD met zijn Fusion en Radeon GPGPU. NVIDIA met CUDA. Allemaal oplossingen om bepaalde taken een stuk beter uti te voeren zoals physics.

Ik denk dat dat een trend is die zich door gaat zetten, cores die gespecialiseerd zijn voor bepaalde taken. Daarnaast krijgen we in de toekomst ook nog Quantumprocessors welke niet meer werken met het standaard 1 en 0.
Sure. Soms moet je antwoord A hebben voor je met B verder gaat, maar tegenwoordig 'schijnt' men iets te hebben dat branch prediction heet.

En anders reken je uit wat er gebeurd als A 1 is en wat er gebeurd als A 2 is (voorbeelden). Zolang de processor(en) maar snel/voldoende genoeg zijn maakt dat ook niet uit.

Ghz zijn niet de enige manier om sneller te zijn.
Dat staat dus ook in mijn verhaal, maar ga jij maar alvast de uitkomst bepalen voor A is 0 tot oneindig ;)
Waarom 0 tot n, je kunt ook beperkte mogelijkheden opgeven; lijkt mij een bruikbare methode.
Dat kan zeker, maar niet altijd. We kunnen wel doorgaan op deze manier maar als er in de kern te veel punten blijven die absoluut niet kunnen worden opgelost dan houd het op.
Omdat GPU bakkers gebruik maken van de belangrijkste eigenschap van 3D graphics: het is "Embarrassingly parallel". Gewone programmas zijn dat niet, en dus moet Intel van hele andere technieken gebruik maken.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True