Intel udgiver flerkerne programmeringsværktøj

Vil det løse alle problemerne man har med de flerkernede CPU'er? eller er det bare et stunt fra intel og amd?

Hvis Parallel Advisor bliver lavet ordentligt, så sker der store ting for os alle! Det betyder det vil blive meget nemmere for programmørene at lave applikationer der kan udnytte flerkernede CPU'er, og der med vil mange flere programmører også vælge rent faktisk at gøre det :-)

Det lyder rigtig godt, og der er også rimelig stor fokus på Parralel Computing i C# 4.0

LINQ, og nu også F#, er gode værktøjer til formålet. Derudover er det rigtig nemt at implementerer funktionelle sprog ind i .NET , som f.eks. Nemerle. Det bliver nok en af de første enterprise niveau løsninger til formålet. Hvor andre platforme (f.eks. Java) halter langt langt bagefter.

Visual Studio 2010 (CTP beta er ude nu), har også en del værktøjer ligesom dem Intel udgiver nu, til at debugge flere tråde osv.

Intels værktøjer er dog målrettet Visual C++, og ikke .NET ;-)

Men vi vil helt klart se mere fokus på parallel-computing de næste par år.

Den største problematik er at få programmørene til at forstå det paradigm skift der skal til for at kode til flere kerner, da mange udviklerer i dag stadigvæk har svært ved at forstå simpelt funktionel kode, hvilket er det paradigm man skal arbejde sig over i mod for optimal programmering.

Lyder cool!

loddo (1) skrev:

Vil det løse alle problemerne man har med de flerkernede CPU'er? eller er det bare et stunt fra intel og amd?

Mange af de problemer, som man kan identificere ved multikerneprocessorer og udnyttelse af dem, er strukturelle, hvorfor du aldrig vil kunne løse alle problemer med dem.

Når det er sagt, så vil disse værktøjer være en stor hjælp, og som du kan se af dine egne, din skoles og/eller din arbejdsplads' computere, så vil du kunne se store ydelsesforbedringer samt bedre "oplevelse" ved at bruge multikerneprocessorer - selv ved brugen af applikationer, der kun kan køre på én tråd.

Det er altså et skridt på den rigtige vej, og det er helt klart en bro til fremtiden (jf. problemerne med at gøre produktionsteknikken mindre, øge spændingen og frekvensen i processorer osv.), da vi vil bevæge os den vej.

Til sidst: Læs #3

fjollet, istedet skulel de lave kernerne om således at OS'et så kernerne som en stor processor.

nu bliver det således at applikationer enten er single core ELLER multi core, og idag kender vi kun til max 8 kerner pr. CPU, men om nogen år snakker vi multi-multi-multi kerner og så er dette værktøj forældet og applikationer der laves nu ligeledes.

udvikle nu nogle kerner som afvikler programmer på lige fod uanset hvor mange CPU kerner der er, således at alle programmer også gamle CS-pakker eller renderinger udnytter hvad end der er...

#6

Det lyder som en god ide, det laver jeg lige i aften. Tak for tippet!

#6

Det er ikke optimalt. Du vil netop gerne have lov som udvikler, at bestemme hvad hver enkelt kerne laver.

F.eks. lad een kerne udregne fysik, og den anden render grafik.

dan1el (6) skrev:

fjollet, istedet skulel de lave kernerne om således at OS'et så kernerne som en stor processor.

...og dermed fratage applikationerne deres mulighed for at udnytte kernerne.

Hvis OS'et ser én kerne, bruger den én kerne. Uanset hvor mange der er. Det er praktisk umuligt at udnytte flere kerner, til at simulere én stor kerne.

dan1el (6) skrev:

nu bliver det således at applikationer enten er single core ELLER multi core,

Du siger det som om det er et problem?

dan1el (6) skrev:

og idag kender vi kun til max 8 kerner pr. CPU, men om nogen år snakker vi multi-multi-multi kerner og så er dette værktøj forældet og applikationer der laves nu ligeledes.

Jeg kender ikke dette værktøj, men det er helt normalt at gamle værktøjer erstattes af nye.

Applikationerne bliver ikke mere forældede af denne grund. Gamle single-kerne-progammer kan sagtens fungere på en 100-kerne CPU. Splinter-nye programmer som ikke er egnet til fler-kerne afvikling vil også fungere fint på en 100-kerne CPU.

Nogle opgaver kan deles op i få separate opgaver, som kan løses på hver sin CPU. Så er det fint at have lige så mange kerner, men intet problem at have flere.

Andre opgaver kan deles op i ufatteligt mange små bidder, som kan strøes ud over det antal kerner man nu har til formålet, om det så er én eller 100.

dan1el (6) skrev:

udvikle nu nogle kerner som afvikler programmer på lige fod uanset hvor mange CPU kerner der er, således at alle programmer også gamle CS-pakker eller renderinger udnytter hvad end der er...

Hvis det ligner én kerne, så er det én kerne, og en-kerne-CPU'er ser jeg ikke mange af i den nærmeste fremtid. Der er ingen grund til det ønske.

Men hvad så med OpenCL? Har alle glemt om den "standard".

nå, men det gav jo lidt genklang... men hvis nu Kernerne kunne håndtere kernerne, istedet for at hver applikation skal speciel designes til flere kerner ?

nemt at sige ...så kommer der en opdatering, men forestil jer nu at man har Photoshop CS2 (ikke multi-core og ikke GPU) og man ikke lige har lyst til at punge ud CS4 opdateringen.

der findes tonshvis af special udviklede systemer, som skal opdateres hver gang man finder ud af at udnytte hardware bedre, man forsøger, bl.a. med openCL at ligge "problemerne" ud til udviklerne af end-user udviklerne, hvorfor kan de ikke bare lave kernerne bedre tila t håndtere multi-kerner således at man ikke skal have alle software udviklere igang når der kommer noget nyt ?

lige tilføjes min idé om forbedret kerne håndtering af multi-kerner ikke er min egen helt 100, men noget jeg læste i en powerpoint show fra Intel til Apple udvikler messen sidste år... da de selv siger om 8 års tid vil der værer tusinder/millioner af kerner og det vil værer dem der driver hastigheds udviklingen (og ikke frekvens hastigheden).

#10:
OpenCL er rettet imod GPU'er og derfor irrelevant her.

loddo (1) skrev:

Vil det løse alle problemerne man har med de flerkernede CPU'er? eller er det bare et stunt fra intel og amd?

Hvis du intet kender til Intels værktøjer, så vil jeg forslå dig at tie stille...

dan1el (11) skrev:

men hvis nu Kernerne kunne håndtere kernerne, istedet for at hver applikation skal speciel designes til flere kerner ?

Joh, men det er altså lidt af en fantasi-verden.

Et program er groft sagt en liste med instruktioner, der skal udføres fra en ende af. Man kan ikke bare lige splitte det ad og udføre dem hver for sig. Det skal programmet altså være designet til.

Hvis du har en 7-punkts opskrift på en lækker kage, kan du jo heller ikke bare dele dem ud til 7 kokke, og få en kage ud af det. (Men det kan da være at én person kan blande dej, mens en anden laver kagecreme.)

terracide skrev:

OpenCL er rettet imod GPU'er og derfor irrelevant her

Nej, OpenCL er rettet mod alle typer parallelle PU'er.

terracide skrev:

Hvis du intet kender til Intels værktøjer, så vil jeg forslå dig at tie stille...

Manden stiller et relevant spørgsmål, så gi ham dog et svar hvis du har det, eller så burde DU tie stille..

OpenCL er et sprog som virker på tværs af CPU, GPU, DSP'er osv. Således at koden er ligeglad med om det bliver eksekveret på CPU eller GPU'en

Cancerman (16) skrev:

OpenCL er et sprog som virker på tværs af CPU, GPU, DSP'er osv. Således at koden er ligeglad med om det bliver eksekveret på CPU eller GPU'en

Ja, men det er et sprog du vil benytte på driver niveau!

Hvis vi skal skrive end-user software med brug af eksisterende teknologier som f.eks. C# eller C++, så skal der værktøjer som dette til.

Så kunne man for den sags skyld ligeså godt benytte Haskell, som allerede tillader parralels.

Så OpenCL er altså overhovedet ikke relevant i sammenhæng med denne her nyhed.

#17 Jeps. Det er rigtigt.
Jeg mener heller ikke, at jeg har påstået at OpenCL er et alternativ til Intels eller C# nye tiltag - og jeg ser personligt frem til begge. :-)

Men OpenCL er ikke rettet mod GPU'er og det var det jeg lagde vægt på.

Så du kan godt sige, at det ikke er relevant i denne nyhed men det blev unægtelig bragt på banen. Så hvorfor ikke få facts'ne om det på plads når vi nu har det oppe.

Cancerman (18) skrev:

Men OpenCL er ikke rettet mod GPU'er og det var det jeg lagde vægt på.

Det er vel så ikke korrekt, da de eneste udnyttelser af OpenGL på markedet er til GPUer.

#19

G != C

eller har jeg misforstået noget?

Windcape (8) skrev:

Det er ikke optimalt. Du vil netop gerne have lov som udvikler, at bestemme hvad hver enkelt kerne laver.

Problemer er jo bare at :

Windcape (3) skrev:

Den største problematik er at få programmørene til at forstå det paradigm skift der skal til for at kode til flere kerner, da mange udviklerer i dag stadigvæk har svært ved at forstå simpelt funktionel kode, hvilket er det paradigm man skal arbejde sig over i mod for optimal programmering.

Jeg holder med dan1el, der må være nogen der laver noget smart. Måske bliver det ikke helt optimalt, man der kommer noget. Måske kompilere der kan "omskrive" koden til flere kerner. Det er meget oplagt.

Typisk at jeg-ved-alt-og-kan-ikke-tænke-selv-nørderne sabler det ned.
Det kræver viden, indsigt, forståelse, mod og stor naivitet at påstå at noget er umuligt.
Som med alt andet umuligt, er det bare et spørgsmål om at pumpe tid og penge i projectet.

#22
Det smarteste jeg har se endnu, er nye syntaxer i programmeringssproget.

Fx:

for( i=0; i < 1000000; i++) {
doSomething(array[i]);
}

(hvor "array" er et array med en størrelse på 1000000.)

Det er skide svært at optimere på. Løkken køres en million gange, men hver gang har "i" en anden værdi, men "i" kan jo kun have én værdi af gangen.
Denne ekstremt simple struktur kan en compiler måske gennemskue og omskrive, men i princippet er det umuligt. Det skal ikke være meget mere kompliceret før det også er umuligt i praksis.

foreach(element in array) {
doSomething(element);
}

Her har compileren mulighed for at se, at der intet er i denne løkke, som er afhængig af de andre gennemløb. Metoden "doSomething" kan være markeret (af programmør eller compiler), eller man kan ganske enkelt definere "foreach" til at være paralel. Denne løkke forhindrer ikke afvikling på 2 kerner, eller en million kerner for den sags skyld.

Den slags ændringer i sproget er det jeg tror vil rykke mest.

Man kan måske komme et stykke ved automatisk at finde ud af hvad der kan køres paralelt. Men den typiske måde at skrive løkker mm. på forhindrer dette i at virke i de fleste tilfælde.

Sjovt du nævner foreach: http://msdn.microsoft.com/en-us/library/dd460688(V...

Derudover kan der læses meget mere på http://blogs.msdn.com/pfxteam/

Og paradigm skiftet handler så om at stoppe med at tænke i iterationer, men mere som rekursive kald. ForEach i et funktionelt sprog er i princippet en række rekursive kald.

Og sådanne kald kan du så sprede ud på flere kerner.

Derudover er værktøjerne som Intel har lavet, mest til at debugge, da det klart er den sværeste del af at arbejde med flere kerner.

JensOle (22) skrev:

Jeg holder med dan1el, der må være nogen der laver noget smart. Måske bliver det ikke helt optimalt, man der kommer noget. Måske kompilere der kan "omskrive" koden til flere kerner. Det er meget oplagt.

Det findes allerede i stor stil.

Problemet er jo netop at få lov at bestemme selv, da compileren langt fra altid gør det optimalt. Nogle gange gør den det slet ikke, fordi det ikke er åbenlyst muligt.

myplacedk (23) skrev:

Men den typiske måde at skrive løkker mm. på forhindrer dette i at virke i de fleste tilfælde.

Forhåbenlig er der ingen tilbage som benytter for(;;) til at itererer over en collection af elementer.

Hvor den måske bliver brugt er til noget lign. dette her:

var people = List() {
"Windcape", "myplacedk", "JensOle"
}

var coolPeople = List();

for(i=0;i<2;i++) {
coolPeople.add(people[i])
}

Hvis det så skal omskrives til funktionelt:

var people = List() {
"Windcape", "myplacedk", "JensOle"
}

var coolPeople = people.Take(2);

Og så kan vi parallel hvad der foregår i Take() funktionen.

Windcape (26) skrev:

Forhåbenlig er der ingen tilbage som benytter for(;;) til at itererer over en collection af elementer.

Jo, det er skam meget almindeligt. Tag serielle iteratorer med, og så tror jeg du rammer langt de fleste.

Iterator i = collection.iterator();
while (i.hasNext()) {
doSomething(i.next());
}

Den er jo heller ikke nem for en compiler at gøre noget ved.

var people = List() { "Windcape", "myplacedk", "JensOle" }
var coolPeople = List();
for(i=0;i<2;i++) {
coolPeople.add(people[i])
}

Uhh den gjorde ondt.

Det kunne jo være at kompileren ikke kiggede logisk og inteligent på løkkerne, man istedet kiggede på resultatet af de forskellige mulittråds muligheder, der kunne være, og så sammen holdte det med resultatet af en enkelt tråds løsning.

Og nej. Jeg vil kan ikke uddybe, hvordan man kan bevise at resultaterne altid vil blive det samme.

Rent faktisk så benytter Parallel LINQ TPL intern til at sprede operationerne ud på flere kerner.

TPL er i princippet det du mener med at kompileren gør arbejdet for en.

myplacedk (27) skrev:

Den er jo heller ikke nem for en compiler at gøre noget ved.

Det er faktisk synd at Java ikke har rigtige iterators.

Deres nuværende iterator implementation eksisterer jo kun fordi det var en god løsning, på hvad generics lists håndterer i dag.

Men det er vel entligt rigtigt, det har taget mig næsten et år at indoktrinere mine klassekammerater til at benytte foreach hvis de kan. Altså for(T value : values) i java.

myplacedk (23) skrev:

#22
Det smarteste jeg har se endnu, er nye syntaxer i programmeringssproget.

Fx:

for( i=0; i < 1000000; i++) {
doSomething(array[i]);
}

(hvor "array" er et array med en størrelse på 1000000.)

Det er skide svært at optimere på. Løkken køres en million gange, men hver gang har "i" en anden værdi, men "i" kan jo kun have én værdi af gangen.
Denne ekstremt simple struktur kan en compiler måske gennemskue og omskrive, men i princippet er det umuligt. Det skal ikke være meget mere kompliceret før det også er umuligt i praksis.

Den slags løkker har man kunnet parallelisere i årtier bl.a. i Fortran.

Idag vil man typisk bruge en Fortran 95 compiler med OpenMP.

Langtfra umuligt.

myplacedk (23) skrev:

#22

foreach(element in array) {
doSomething(element);
}

Her har compileren mulighed for at se, at der intet er i denne løkke, som er afhængig af de andre gennemløb. Metoden "doSomething" kan være markeret (af programmør eller compiler), eller man kan ganske enkelt definere "foreach" til at være paralel. Denne løkke forhindrer ikke afvikling på 2 kerner, eller en million kerner for den sags skyld.

Foreach løkker giver ikke garanti for at en iteration ikke afhænger af tidligere iterationer.

C# eksempel (absurdt men illustrativt):

using System;

namespace E
{
public class Program
{
public static void Main(string[] args)
{
int[][] a = { new int[] { 1 }, new int[] { 2 }, new int[] { 3 } };
int atmp = 0;
for(int i = 0; i < a.Length; i++)
{
a[i][0] += atmp;
atmp = a[i][0];
}
for(int i = 0; i < a.Length; i++)
{
Console.WriteLine(a[i][0]);
}
int[][] b =  { new int[] { 1 }, new int[] { 2 }, new int[] { 3 } };
int btmp = 0;
foreach(int[] v in b)
{
v[0] += btmp;
btmp = v[0];
}
foreach(int[] v in b)
{
Console.WriteLine(v[0]);
}
}
}
}

loddo (1) skrev:

Vil det løse alle problemerne man har med de flerkernede CPU'er? eller er det bare et stunt fra intel og amd?

Der findes ingen simpel automatisk måde at parallelisere afviklingen af algoritmer på. Uanset hvordan man gør det, så kræver det at programmøren tænker over problemet.

dan1el (6) skrev:

fjollet, istedet skulel de lave kernerne om således at OS'et så kernerne som en stor processor.

Det begyndte man på for over 10 år siden. Det har betydet at man er gået fra at bruge adskillige clockcycler per instruktion til at man i dag kan køre to instruktioner per clockcycle når det går godt. Der er bare en grænse for hvor meget man kan forbedre performance på den måde. Den grænse er vi ved at have nået. Der er ikke længere nogen vej udenom, at programmører er nødt til at tænke over hvordan deres algoritmer kan paralleliseres, hvis de ønsker bedre performance.

dan1el (6) skrev:

idag kender vi kun til max 8 kerner pr. CPU, men om nogen år snakker vi multi-multi-multi kerner og så er dette værktøj forældet og applikationer der laves nu ligeledes.

En god parallel algoritme designes så den kan afvikles på så mange kerner som muligt. Hvis man har færre kerner, så afvikles dele af algoritmen bare i sekvens i stedet. Det teoretiske grundlag har eksisteret længe. Vi blev undervist i det, da jeg studerede på universitetet.

Det der manglede på det tidspunkt var gode sprog og compilere til at gå fra blot at have algoritmer til at have effektive programmer.

Der er to typer overhead som kommer ind i billedet. Der er kompleksiteten af algoritmen, som nogen gange er dårligere for en parallel algoritme end for en sekventiel algoritme. Desuden vil der også være en konstant faktor. Hvis ikke man kan få produktet af de to ned under antallet af kerner, så kan parallelisering ikke betale sig.

Jeg kan ikke huske hvor gode parallel algoritmer, der fandtes for forskellige problemer, så de eksempler jeg giver her svarer på ingen måde til konkrete algoritmer.

Sekventiel sortering kan gøres i tid O(n log n).

Hvis man har en parallel algoritme, der kan gøre det i tid O(log n) med O(n log n) tråde, så vil det betyde at man udfører O(log n) gange så meget arbejde ved at bruge den parallel algoritme.

Hvis man har en anden parallel algoritme, der kan gøre det i tid O((log n)^2) med O(n/log n) tråde, så vil denne anden algoritme være "langsommere" end den første parallel algoritme, men kun udføre samme mængde arbejde som en sekventiel algoritme.

I praksis har man slet ikke så mange kerner. Så i stedet for at udføre alle trådene i parallel er man nødt til at udføre nogen af dem i sekvens. Så en algoritme med lavere totalt arbejde vil næsten altid være at foretrække, selvom den ikke parallelisere lige så meget. Det er ligegyldigt om det maksimale antal kerner algoritmen kan udnytte er 100.000 eller 1.000.000, hvis du alligevel ender med at afvikle den på 8 eller 32 kerner. Til gengæld er det altafgørende om algoritmen bruger samme mængde beregningsresourcer som en parallel eller om den bruger 20 gange så mange.

Der er et par praktiske problemer ved fremgangsmåden, men det er til gengæld nogen som en passende mængde engineering kan løse. For det første er disse teoretiske algoritmer synkrone algoritmer, så alle tråde skal afvikles med præcist samme hastighed. Det afviger fra hvordan hardware og scheduling i OS i praksis fungerer. Det er også et problem for at bare afvikle nogle af trådene i sekvens når algoritmen kunne udnytte flere kerner end man faktisk har.

Det med den sekventielle afvikling kan løses ved at interleave afviklingen af trådene i stedet for at gøre dem strengt sekventielt. Det har også basis for at udnytte CPU pipelining bedre.

Problemet med OS scheduleringen kunne løses ved at OS tillader at beregningstunge programmer kan angive at de skal scheduleres på flere cores på en gang. Har man 16 cores kan det sagtens accepteres at en beregningstung process lægger beslag på 8 på samme tid i en evt. ekstra lang time slice. De ting der har brug for at få en CPU tildelt med kort varsel er typisk ikke så CPU krævende, og kan sagtens scheduleres på de resterende 8.

Der er stadig et problem i at cores ikke afvikler kode synkront - selv hvis programmet har fået flere cores tildelt på samme tid. Så der kræves altså synkronisering imellem de forskellige skridt. Den type synkronisering er dyrt, og kræves efter hvert skridt af algoritmen. Men når der interleaves flere tråde på en core skal der kun synkroniseres efter at de alle sammen har udført deres skridt. Så i ovenstående eksemepel ville der så kun være tale om O((log n)^2) synkroniseringer gennem algoritmen.

Et problem med interleavingen er, at den bidrager til den konstante faktor jeg nævnte. Interleavingen kan sikkert gøres mere effektiv, hvis nogle af kravene er kendt på compile time. Men det er ikke så hensigtsmæssigt, hvis man på compile time skal vide om det tilgængelige antal cores vil være 8 eller 32. Det er stadigvæk en fordel hvis alt der skal til for at udnytte flere cores er en recompilering og ikke et redesign af programmet. Men måske man kan gøre det smartere og compilere noget kode som f.eks. kan understøtte 1 - 64 cores uden at have det store overhead til interleaving.

Jeg har ingen anelse om hvorvidt det nævnte værktøj løser de problemer jeg har beskrevet her. Men det er den vej man skal gå, hvis man vil have software der kan udnytte ekstreme antal cores. Selv hvis første generation af compilere til parallele programmeringssprog genererer kode, der kun kan bruges til et specifikt antal cores, vil det stadigvæk være et skridt i den rigtige retning. Hvis man først har udviklet sprogene og startet på at skrive kode, så kan fremtidige compilere øge det antal supporterede tråde. Det vil også give basis for at udvikle nye instruktionsset der ikke kan afvikles lige så hurtigt, men bedre kan paralleliseres. For når først parallel kode er normen, så er det helt acceptabelt at hver enkelt core er 10 gange langsommere end i dag, hvis der til gengæld kan laves 100 gange så mange cores i en CPU.

Min forklaring nåede vist langt omkring. Min oprindelige pointe var nu ret simpel. Når først man går i gang med at parallelisere, så kan man lige så godt gøre det rigtigt og understøtte mange cores. Man skal undgå at kode efter et bestemt antal cores - ligesom man skal undgå at kode efter en bestemt mængde RAM. Et program der kræver præcist 512MB RAM for at fungere fornuftigt er ikke optimalt hvis det betyder at det ikke kan bruges på en maskine med 256MB RAM og du ender med at kun udnytte halvdelen, hvis det kører på en maskine med 1GB RAM.

Windcape (26) skrev:

Hvor den måske bliver brugt er til noget lign. dette her:

var people = List() {
"Windcape", "myplacedk", "JensOle"
}

var coolPeople = List();

for(i=0;i<2;i++) {
coolPeople.add(people[i])
}

Hvis det så skal omskrives til funktionelt:

var people = List() {
"Windcape", "myplacedk", "JensOle"
}

var coolPeople = people.Take(2);

Og så kan vi parallel hvad der foregår i Take() funktionen.

Det ikke noget specielt godt eksempel.

At erstatte en løkke med et metode kald paralleliserer jo ikke noget. Det flytter kun problemet et andet sted hen.

arne_v (33) skrev:

Det flytter kun problemet et andet sted hen.

Ja, men det var også ideen.

Som jeg har forstået det er det nemmere at paralleliserer metoder, end programmørenes hundrede forskellige måder at skrive løkker på.

Fordi det kunne også være skrevet som:

var cp = new List() { people[0], people[1] }

Og så skulle man pludselig paralleliserer konstrukturen på new List() ?

terracide (13) skrev:

Hvis du intet kender til Intels værktøjer, så vil jeg forslå dig at tie stille...

.. mangler du et knus?

Hvis jeg intet ved om intels værktøjer, så finder jeg jo ikke ud af mere ved IKKE at spørge, vel? .. smarte ;)

#15 thx.

#32 thx :)

#35:
Du "spurgte" ikke bare, du lagde op til det var et PR-stunt...om igen.

arne_v (31) skrev:

Foreach løkker giver ikke garanti for at en iteration ikke afhænger af tidligere iterationer.

Ikke i sig selv. Men sproget kan definere en foreach som værende en paralel konstruktion, eller sproget kan måske selv se om løkken kan afvikles paralelt.
(Jeg kan så bedst lide den første lige nu, men det andet er nok det bedste længere ude i fremtiden.)

#36
Så vidt jeg ved står alle og tuder over at det er umuligt at bruge alle de kerner som de smækker i deres CPU'er. Det ville være rimeligt nice hvis Intel og AMD kom med en løsning inden det går helt galt, og alle devs begår selvmord.

Så mit spørgsmål er, om det faktisk er noget der virker, eller om de bare er en halv løsning for at promovere deres nye (og kommende) cpu'er. Forstår ikke hvorfor det er forkert at spørge om - altså, medmindre du ikke ved det :)

umiddelbart tolker jeg din "Hvis du intet kender til Intels værktøjer, så vil jeg forslå dig at tie stille..." til: "nej, det virker på ingen måde og intel er en synkende skude". Hvis det ikke er tilfældet, så sig dog noget..

/me hugs terracide

loddo (38) skrev:

Så vidt jeg ved står alle og tuder over at det er umuligt at bruge alle de kerner som de smækker i deres CPU'er. Det ville være rimeligt nice hvis Intel og AMD kom med en løsning inden det går helt galt, og alle devs begår selvmord.

De skulle hellere gå i gang med at udvikle multitrådede programmer med de værktøjer, de allerede har. Det er jo ikke fordi at der overhovedet ingen værktøjer findes. Og hvis ikke udviklerne er tilfreds med de tilgængelige værktøjer, så kunne de jo udvikle nogle bedre.

Men egentlig tror jeg ikke jeg har hørt nogle udviklere beklage sig over manglen på værktøjer. Min fornemmelse har indtil videre været, at dem der har beklaget sig har været slutbrugere. Og det er jo personer, som burde være ligeglade med hvilke værktøjer der bliver anvendt.

Windcape (34) skrev:

Ja, men det var også ideen.

Som jeg har forstået det er det nemmere at paralleliserer metoder, end programmørenes hundrede forskellige måder at skrive løkker på.

Det gælder helt generelt at det er godt at samle ens funktionalitet i en subroutine/funktion/metode, saa man kan forbedre implementeringen et sted.

Men det er ikke en specifik problemstilling for parallelisering.

Det specifikke problem for parallelisering er at skrive Take eller de tusinder af egne løkker så de udføres parallelt.

loddo (38) skrev:

Så vidt jeg ved står alle og tuder over at det er umuligt at bruge alle de kerner som de smækker i deres CPU'er. Det ville være rimeligt nice hvis Intel og AMD kom med en løsning inden det går helt galt, og alle devs begår selvmord.

Udviklerne har flere årtiers erfaringer med at lave programmer som kan køre parallelt på flere CPU'er (at det idag f.eks. er 16 kerner i 2 sokler fremfor 8 kerner i 8 sokler har ikke meget betydning for udviklerne).

Udviklerne ved hvad der kan laves og hvad der ikke kan laves med de nuværende værktøjer.

Og jeg mener ikke at det er udviklerne som græder.

Det er vist mest gruppen af PC brugere som ikke ved en snus om hvad man har lavet på servere i lang tid og som ikke selv kan programmere der er i panik.

Der er nye udfordringer. De fleste desktop apps kan ikke paralleliseres på samme måde som server apps alle scientific apps.

Og der er gamle udfordringer. Multithreaded apps er notorisk vanskeligere at lave korrekte end singlethreaded apps.

Så nye og bedre værktøjer kan sagtens bruges.