Intel waarschuwt developers voor komst duizenden cores

Ik denk eerder dat Intel erop wil wijzen dat niet alle huidige software het voordeel van meerdere cores benut. Het is natuurlijk wel zo, dat als de consument het nut van meerdere cores niet inziet, omdat ze toch niet optimaal benut worden door de software, diezelfde consument niet zo snel een multicore processor zal aanschaffen.

Tegenwoordig heeft bijna iedereen al een multicore processor. Probeer maar een doorsnee pc te kopen Zonder een dualcore. Bij budget laptops wil dat misschien nog wel lukken. Zelf mobiele telefoons krijgen al multicore processors. Kortom multicores hebben de toekomst, dus waarom zou men dat niet een beetje gaan pushen.

Daarnaast kan ik mij heel goed voorstellen dat toekomstige software gewoon op een singlecore kan draaien, zei het dan niet optimaal.
Maar wat Intel wilt bereiken is dat men de software zo gaat schrijven dat het met minimale of helemaal geen aanpassingen kan werken met een X aantal cores. Kortom software dat optimaal gebruik maakt van het aantal cores wat je hebt. Of dat er nou 2 zijn, wat nu meestal het geval is, of dat het er 500 zijn.

Het leuke van software geschreven voor multi-cores is dat het ook gewoon gaat werken op een singlecore. De twee systemen zijn onderling uitwisselbaar etc. Het punt is alleen dat wanneer een programma geschreven is voor multi-core processors, het veel sneller kan gaan dan wanneer het op een singlecore gedraaid wordt.

Bedenk bijvoorbeeld eens een programma die de inhoud van een X-aantal webpagina's binnenhaalt, en die verwerkt (heb ik eens gedaan). De singlecore-variant roept de pagina op, downloadt hem, en verwerkt het.

Het probleem daarmee is dat er maar een webpagina tegelijk gedownload wordt, het proces dat de zooi moet downloaden is dus 95% van z'n tijd bezig met het wachten op informatie. Als je nu 10 processen hebt die tegelijk uitgevoerd worden, heb je 10 die asynchroon downloaden en verwerken, waardoor er totaal veel meer gebeurt. Ik heb zelf zo'n programma eens gemaakt, en de snelheidswinst is enorm.

Hoezo freudiaans ;-)

Ik ken het verschil tussen algoritme en denkpatroon.

Op dit moment zijn de algoritmes gebaseerd op het serieel doorlopen van een aantal stappen.

Maar aangezien we steeds meer te maken krijgen met meerdere kernen moeten we onze algoritmes aanpassen. Niet mer serieel, maar parallel.

Dat betekent dus dat we onze denkwijze moeten aanpassen. In feite dezelfde ontwikkeling als de er op hardware niveau is gebeurd; we kunnen niet sneller in kloksnelheid, dan maar in aantal cores.

Sorry, maar je kan veel meer threads gebruiken dan dat je cores hebben, alleen zal er op iedere core slechts één thread tegelijkertijd actief zijn. De scheduler van je OS zorgt er echter voor dat al die threads schijnbaar tegelijkertijd actief zijn. Dus op dit moment ben je met een dual core helemaal niet beperkt tot twee threads!

Het enige nadeel van veel threads op minder cores is dat de overhead van de scheduling groter wordt (wat echter altijd weer een afweging is tegen het nu van het gebruik van meerder threads).

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.

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

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.

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

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

Je ziet de zaken toch wel verkeerd...

Met de huidige GPU's kan een GPU in weze hetzelfde als een CPU. Met het verschil dat een CPU volkomen is geoptimaliseerd voor een enkele thread, en een GPU voor vele threads, waardoor ze zeer verschillende prestaties laten zien voor bepaalde toepassingen. Maar ze kunnen dezelfde berekeningen uitvoeren. .

Die "beperkingen" dat de GPU dezelfde taak parrallel uitvoert, is een hele praktische, en zal ook in zekere mate waarschijnlijk ook voor CPU's gaan gelden mocht men inderdaad duizenden cores op een chip zetten. Want wat denk je nu? Dat als een CPU duizenden heeft, dan die dan allemaal volkomen andere dingen doen? Natuurlijk niet! Uiteindelijk zijn er op een desktop toch maar enkele taken actief. Het zal er dus op neer komen, dan een CPU een probleem, bijvoorbeeld een matrix berekening, gaat opsplitsen over al zijn cores, en veel cores dus nog steeds min of meer dezelfde dingen doen.

voorbeeldje voor thuisgebruiker:
fotobewerkingsfiltertje proberen, hmm er moet een keuze worden ingeven van, zeg, de hoeveelheid smoothing die ik wil tja, geen idee, dus hij/zij voert willekeurig getal in, bekijkt resultaat, verandert het getal,bekijkt nieuw resultaat, etc, dat is dus nu.
in toekomst:
fotobewerkingsfiltertje proberen, meteen wordt een hele reeks van waardes doorgerekend en de gebruiker kan door de resultaten heen bladeren zonder zich er van bewust te zijn dat aan elk resultaat een smoothing waarde zit.

Google zijn software is dan ook een schoolvoorbeeld van makkelijk paraleliseerbare software. Miljoenen klanten die elk relatief simpele operaties uitvoeren. Probeer hetzelfde maar eens met iets zoals Crysis of VMware, zelfs de genien bij google lopen weg als ze zulke dingen efficient op 100'en cores moeten laten lopen.