IBM tættere på optisk interconnect mellem CPU-kerner

<Sjov og spas>Havde de nu bare været lidt hurtigere på fingrene - så havde vi haft 64 kerna da vi kørte win98 !</sjov og spas>

Det er rigtig nice at se de fremskridt de laver inden for CPU'er / Hardware generelt - vil tro at denne teknologi også vil være med til at spare på strømforbruget. Hvilket altid et et plus.

Er det virkelig så fedt med flere kerner??

Jeg har personlig ikke mere end ET resurcekrævende program igang. Dette være sig hovedsalig et spil. Jeg kan derfor ikke se den store brug for mere end to kerner i mit tilfælde (en til OS og en til spillet)

Nu ved jeg godt de siger at spil i fremtiden bliver multitrådet, men hvor mange tråde tror I lige de laver??

Det er jo lidt det samme som grafikkort industrien gør i øjeblikket. De opgiver at gøre kortene hurtigere, men vil heller kikke på multi GPU (SLI).

Er det virkelig det vi vil have?? Og der må vel være en grænse for antallet af kerne, som vil forbedre performance. Hvor går den grænse (4, 16, +100)??

... Eneste gode jeg kan se her er mindre varme, som burde være lig mindre strømforbrug. Men det er selvfølgelig også en god ting :o)

#2 Sprog som C++ som typisk bliver brugt til spil har elendig understøttelse for multitrådet/multiprocess-programmering. Efterhånden som moderne sprog med bedre understøttelse for multiprogrammering bliver taget i brug vil vi se flere og flere spil der kan udnytte et vilkårligt antal kerner (i praksis i hvert fald).

De dele af spillene der laver grafiske effekter (shaders) bliver allerede nu kodet i meget specialiserede sprog der gør det muligt at afvikle dem parralelt (og alle moderne grafikkort udnytter dette).

#4
Hvad snakker du om, spade!??
C++ har da rigtig god understøttelse, kun dig der ikke ved en disse om C++, stop bashing når du ikke ved en skid. Er selv C++ programmør og jeg klager sku ikke.

Og angående spil, så kan siges at Eve online udnytter flere kerne processor i fremtiden. Såvel som mange andre spil, mange ting som man kan smide over på andre processer.

#2 og #4
tror nu ikke IBM udvikler dette med spil som hensigt.
Tror mere det er til supercomputere så man kan overkomme problemet med at man på et tidspunkt ikke kan smide flere kerner/cpu'er i. Varme/energi besparelsen er jo bare et plus.

Fremtidens supercomputere bliver nok den største del af et udviklet samfund. Så lad os håbe de bliver brugt fornuftigt :)

Den mindre varmeudvikling, vil gøre det nemmere at placere CPU-kerner endnu tættere på hinanden og dermed skabe plads til flere kerner.

De kan placere dem 1mm tættere på hinanden. JUHUU!!! Det er jo langt fra CPU'ens bus der er strømslugeren.

Glem ej at hastigheden hvorved de forskellige komponenter kommunikerer bliver øget med en faktor 100!

Det er alligevel noget der kan mærkes

#2 For det første er dette næppe tiltænkt lige præcis dig og dine krav.

MHT multiprocessor / multicore løsninger så er det ganske brugbart - men du har ganske ret i at Windows-platformen sakker bagefter med hensyn til parallelhåndtering. (Jeg går ud fra at det er Windows du hentyder til, da du fortæller at du har vænnet dig til kun at have et ressourcekrævende program kørende af gangen).

MHT GPU'erne, så er branchen efterhånden nået dertil hvor varmen og fabrikationsprocessen er flaskehalsen. Nogle fabrikanter har f.eks luftet tanken om at droppe 2D delen, for at emulere dette i 2D delen - for således at kunne spare transistorer - dermed plads og hvad der nu ellers medfølger.

#8 Især for designerne, der idag har timingproblemer med deres designs. Man vil kunne lave langt større og komplekse processorer

#5: Pas på med at knytte dig følelsesmæssigt til et sprog, det er ikke godt for blodtrykket ;-) Men måske har du ret - hvilke C++ multprogrammeringsværktøjer er det du tænker på?

Sjovt som folk misforstaar teknologiske fremskridt og ser dem som isolerede teknologier. Dette er blot et skridt paa vejen og hvem ved hvad det sammen med en lang raekke andre teknologier kan foere til. Maaske kan vi ikke lige se hvad daelen det skulle goere godt for lige nu, men jeg er sikker paa det vil aabne mange nye muligheder.

Hvad snakker du om, spade!??
C++ har da rigtig god understøttelse, kun dig der ikke ved en disse om C++, stop bashing når du ikke ved en skid. Er selv C++ programmør og jeg klager sku ikke.

Det er jeg fuldstændig uenig med dig i. Det gælder ikke kun C++ men også mere moderne sprog som Java og C#.

De har alle sammen en meget simpel model til at styre tråde i form af monitors og signals som er så bøvlet at kode med at den gennemsnitlige programmør laver langt flere bugs når han laver multitrådede programmer end når han laver enkelttrådede og de fleste har store problemer med at gøre det effektivt. Det kan man blandt andet se med de problemer der har været med at udnytte PS3ens regnekraft.

Man pakker så disse monitors ind i lidt højere abstraktioner som semaforer og mutexes, men det ændrer ikke på at det er helt utilstrækkeligt hvis multitrådet programmering skal være den helt almindelige måde at programmere på.

Man kan gå en anden vej som handler om at lave sprog uden side effekts. I disse tilfælde kan compileren bestemme hvad der skal beregnes parallelt og hvad der skal gøres serielt. Blandt andet har holdet som opfandt Java hos SUN i sin tid gang i et spændende projekt kaldet Fotress hvor de arbejder med de her ting.

Når først vi kommer dertil hvor sprogene understøtter sådan nogle ting direkte, så er svaret på #2's spørgsmål at vi aldrig kan få kerner nok, for vi vil altid kunne udnytte én mere!

#12

Ja og man kunne også bare lave et program ,som man kunne skrive til hvad man vil have, og så ville den lave et.

Det kan da ikke være sprogets problem at folk ikke kan programmere, bare sproget kan garantere at det gør hvad man siger det skal gøre.

Tror i øvrigt ikke jeg kan finde et program der er singletrådet

Ja og man kunne også bare lave et program ,som man kunne skrive til hvad man vil have, og så ville den lave et.

Det kaldes en compiler

Det kan da ikke være sprogets problem at folk ikke kan programmere, bare sproget kan garantere at det gør hvad man siger det skal gøre.

Du er nødt til at prøve at forstå hvad et programmeringssprog er. Det er en abstraktion oven på den måde computeren arbejder på. Ja, et sprog gør hvad man beder det om, men der bliver også gjort en masse ting for dig.

Skal du bekymre dig om at arrangere registre effektivt? Nej, for der er en compiler som lader dig definere noget som kaldes variable. De findes ikke i computeren, men compileren oversætter til noget som gør!

Skal du bekymre dig om at håndtere at frigøre hukommelse som du ikke længere bruger? I nogle sprog ja, men i andre er det håndteret for dig!

Skal du bekymre dig om low level håndtering af parallellitet? Ja, men måske kunne man gøre noget smartere...

Jeg synes at det er det rene vås med at "det ikke er sprogets problem". Med den logik er det eneste, som en programmør bør kode i, maskinekode (ikke assembler, men maskinekode).

Tror i øvrigt ikke jeg kan finde et program der er singletrådet

Næ, men du kan heller ikke finde et C++ program der deler arbejdsopgaverne op på den optimale måde til at dele ud på vilkårligt mange kerner. Overvej som et meget simpelt eksempel den her række statements:

int a,b,c;
a = computeA();
b = computeB();
c = a + b;

Du ved at beregningen af a ikke har nogen forbindelse til beregningen af b. Derfor er det (antaget af beregningerne ikke er trivielle) mere effektivt at beregne dem samtidigt på hver sin kerne. Hvor meget kode skal du så fyre af før det rent faktisk sker i C++/Java? (Svaret er meget og du skal have fingrene direkte ned i at starte og joine tråde). Ville det ikke være smartere hvis compileren gjorde det for dig i de tilfælde hvor den kan se at det ikke er et problem?

#14

Du snakker jo compilere ikke sprog..

Du beskylder sproget for at være skyld i at programmøren laver bugs, jeg siger at det ikke er sprogets skyld at gøre..

Nu arbejder jeg på VxWorks platformen, hvilket også er C++, men der har du meget mere indflydelse på styringen af tråde, og laver du lort i den og får deadlocks osv, så er det nu din egens kyld.

Fordi det kan laves uden deadlocks og det kan laves så det fordeles på flere kerne, hvis dine evner er til det...

Du snakker jo compilere ikke sprog..

Det er to sider af samme sag...

Du beskylder sproget for at være skyld i at programmøren laver bugs, jeg siger at det ikke er sprogets skyld at gøre..

Nej, jeg beskylder manglen på features i sprogene for at medføre fejl.

Nu arbejder jeg på VxWorks platformen, hvilket også er C++, men der har du meget mere indflydelse på styringen af tråde, og laver du lort i den og får deadlocks osv, så er det nu din egens kyld.

Du forstår vist ikke hvad jeg mener. Jeg snakker om automatisk at parallellisere uafhængige ting, så man udnytter kernerne. Selvfølgelig skal du også selv kunne håndtere tråde men i nogle tilfælde er det smartere at lade nogen gør det for dig, så du kan bruge tiden på noget andet.

Fordi det kan laves uden deadlocks og det kan laves så det fordeles på flere kerne, hvis dine evner er til det...

Hvis mine evner er til det så kan jeg også spille tid på at skrive det hele (inkl trådhåndtering) i assembler, men hvorfor hævlede skulle jeg det hvis jeg havde et bedre sprog som håndterede det?

#16
Hvis du mener at det kan gøres i assembly, og compileren eneste formål er at oversætte fra C++ til assembly / maskinkode, hvor er det så skrevet at C++ er skyld i at uafhængelige tråde ikke bliver fordelt på flere kerner ?

Kunne det ikke tænkes at det er fordi compilerne ikke er lavet til at håndtere flere kerner ? men det har jo ikke noget at gøre med sproget C++, det er jo kun en standard

#17 Seriøst, jeg skulle ikke have nævnt C++. Jeg skulle bare have sagt 'mainstream sprog'. Jeg ved ikke hvad din pointe er med fantasier om compilere der måske en dag kan gøre noget magisk med din kode - andre sprog virker nu!

Måske en C++-mand kan overbevise dig om at der er visse mangler - Tim Sweeney (startede Epic games, kendt for Unreal Engine): http://www.st.cs.uni-sb.de/edu/seminare/2005/advan...