64 kärnor kan bli vanligt redan 2012

Sådana instruktioner är på för hög nivå för att kunna göras i processorn. Möjligen skulle de kunna göra instruktioner eller principer som hjälper detta. Som att skydda sig mot skadlig kod (virus) kör hur som helst så kan vissa områden av minnet flaggas med "no execute" biten. Då blir det omöjligt för hårdvaran att köra instruktionspekaren från det stället. Men det är inte den färdiga lösningen.
Båda dina förslag kan OS:et ta hand om. Men jag vill hävda att det är en dålig idé att så här distinkt dela upp resurserna. Det är bättre med en pool som alla får använda av.

Vi tar ett exempel
Det finns x antal fraktdotterföretag (processer) som inom samma moderbolag (operativsystemet (schemaläggaren)) äger 64 lastbilar. Första problemet: Man kan inte ha ett enda fraktföretag mer då det bara finns 64 lastbilar att tillgå.
Använder de istället en gemensam pool där lastbilarna används när de behövs så kan hur många företag som helst finnas. Sen det normala för varje företag är att de kanske kör 1 pall 1 km bara (låg processoranvändning). Väldigt ineffektivt. Men något företag kanske har 100 pallar som de behöver frakta snabbt (hög processoranvändning). I första modellen så har företaget bara 1 lastbil och måste åka fram och tillbaka massvis. I det senare med poolen så kan de direkt ta 5 lastbilar eller hur många det nu krävs.
Men nu skulle ett ensamt företag kunna använda alla lastbilar och att blockera för de andra (process starvation). Men här har schemaläggaren ansvaret att om ett företag inte fått köra på "länge" så får de köra fast det är väldigt lite de ska göra, bara för att få snabb responstid.

Denna lösning för processexekveringen är lämplig för persondatorer och terminalservrar där många ska dela på samma resurser fast de inte använder det till max. Det är resursslöseri att exklusivt tilldela varje användare 1 kärna.
Tittar man på superdatorer, alltså kluster som används för högprestandaberäkningar så har man istället så att de olika användarna får ansöka om processortid (till ett schemaläggarprogram). När ens tur kommer så får man exklusiv tillgång till alla processorer (eller en begränsad partition av klustret). Man vill unvika massa process switching och man vet att användarna skriver program som (förhoppningsvis) utnyttjar beräkningsprestandan till max.

http://en.wikipedia.org/wiki/X86_virtualization
Man kunde redan tidigare köra flera operativsystem samtidigt i virtuella maskiner. Problemet är dock att vissa instruktioner som används i kernel mode (ring 0) måste tolkas. Ett gästoperativsystem kan inte få tillgång till dessa på hosten. Med de här virtualiseringsteknikerna (intel VT och AMD-V) tror jag gör att processorn själv kan ge illusionen av detta. Det snabbare upp exekveringen. Detta säger inget om dedikering av kärnor.

En GPU är i naturen väldigt parallelliserad. 8800GTX innehåller ju 128 streamprocessorer. Eftersom vad grafikkortet ska göra är väldigt specifikt likartat med olika data så kan man öka antalet streamprocessorer som de kallas (eller pipes för väl?) och få mer prestanda. Totalt för hela grafikkortet så ska man ju uppnå samma resultat vid varje gång - en och samma bild.
Man skulle kunna vända på det och säga att de har 128 simpla kärnor (nästan säga det iaf).
Nvidias G80 GPU har 681 miljoner transistorer och upptar en yta av 480 mm^2. Tillverkad på 90nm process. Man kan jämföra med conroe-processorkärnan (dual core). Den har väldigt många transistorer också (hittade ingen siffra nu) och tillverkad på 64nm. Men ytan är 143 mm^2.a
Så G80-kretsen är ett monster. Att klämma in två stycken sådana i samma die ger nog väldigt mycket bekymmer. Bättre att förbättre arkitekturen och öka antalet streamprocessorer i samma processor. Ska man ha helt olika kärnor så får man flytta ut till separata krestar som det görs nu med SLI och crossfire.

Bra sagt! Tyckte iofs också att KimTjik's förslag kändes lite som slöseri med processorresurserna. Sen är det ju inte kul att inte kunna ha mer användare än processorer i systemet.

jaja, men då ändrar du ju ekvationen, så får man inte göra

Men det är ju jusst det som är problemet och därför som man börjat köra på kärnor mycket mer...

Du som var med (jag var själv med), kan inte du nämna vart du var och lyssnade på gates när han sa ovanstående? Eller är det som du sa, att det är pratiskt att kunna skriva sin egna historia?

Är du HELT säker på att du vet vad du snackar om?

Det beror väl problemet, om det är lätt att parallellisera eller inte.
Exempelvis matrismultiplikation kan lätt delas upp och skalar väldigt bra med antal trådar. Men att ta ett spel som är rätt sekventiellt (allt måste bli klart till varje frame) så är det nog en mardröm. Det utvecklarna lyckats gjort hittills är mest att dela upp olika problemområden till olika kärnor (AI, ljud, grafik, fysik). Att finfördela varje sådant och få det att skala bra däremot tror jag de inte haft så stor framgång med ännu.

Dom ligger väl redan långt före?

Nej, utvecklingen har äntligen börjat gå åt rätt håll! Flera kärnor är den ingenjörsmässiga och tekniskt rättframma lösningen på "problemet" att öka prestanda exponentiellt över tid. Att mjukvaruutvecklare inte hinner med för att skriva ett program som skalar bra över flera processorer är ett helt annat problem. Dagens datorsystem kör sedan länge flera tiotals program samtidigt, helt oberoende av varandra.

Vidare kommer inga kärnor att prestera dåligt då de kärnor som mångfaldigas i moderna x86-processorer (liksom annorstädes) från början är enkelkärnor och redan presterar bra som en sådan.

Långt ifrån alla problem låter sig parallelliseras enkelt eller alls, men det är inte riktigt samma sak som att vi behöver en snabb kärna snarare än flera. Flera kärnor inbjuder också till att lösa problem på en PC som den inte var påtänkt för innan.

Mjukvaruutvecklarna, som jag, har bara att gilla läget. Detta är den uppenbara framtiden under överskådlig tid. Och det är inte en sekund för tidigt. Ingenting är givetvis sagt om att varje enskild kärna inte fortfarande skulle kunna bli snabbare i precis samma takt som tidigare.

...

Varför säger folk saker som att just fyra kärnor borde vara tillräckligt ("för nu") eller att 64 kärnor är det minsta man kan begära?

Den enskilda processorn har ingalunda slutat att utvecklas, och den utvecklas snabbare än vi får flera kärnor. Men dagens datorer kan mycket väl ha nytta av fyra kärnor eller fler i den dagliga användningen. Troligen kommer vi se platåer i den närmsta utvecklingen, där antalet kärnor förblir konstant över en tid, medan varje kärna får bättre prestanda. Fyra är väl dagens nivå. Visst kommer vi, förr eller senare, se 64-kärniga persondatorer, men vi kan vänta oss flera stabila platåer som kan sträcka sig över flera år. Fyra kärnor (eller mindre) kommer säkert att bestå ett tag som "standard".

För några år sedan eller tio läste jag att "om 5 år kan vi prata med datorn". Inga musklickningar eller tangentbord skulle behövas, man skulle bara säga vad man ville ha gjort.

När jag nu ser mig omkring, ser jag inga sådana tillämpningar. Eller finns dom någonstans?

Skulle ett sådant program behöva alla 64 - 128 - 1024 kärnor?

Först när man bygger in intelligens i kompilatorer, att kompilatorn själv kan optimera kod i olika trådar utan att programmeraren behöver tänka på det kommer det bli vanligare med trådade program. Tills dess så kommer endast de program som passar väldigt bra för trådning eller enstaka program med mycket skickliga utvecklare.

Ett problem med utvecklare är att de enligt mig blir sämre och sämre. Utvecklingsmiljöer blir bara bättre och tar över arbete från utvecklaren vilket gör att utvecklaren inte behöver lära sig lika mycket, det finns mer och mer komponenter och tillgå vilket även där gör att utvecklaren slipper koda så mycket själv. Säkerligen blir utvecklaren produktiv ändå men om man jämför med förr när man i princip fick göra allt själv och utvecklingsmiljön var klart sämre än idag, då tvingades utvecklare och skärpa till sig mer.

Även om ett företag får tag i några stjärnor så är det ändå väldigt känsligt, dessa stjärnor producerar kod som det krävs avancerade kunskaper att ta över om stjärnan eller stjärnorna slutar. Så det måste finnas en del för att företag skall våga sig på mer avancerade lösningar.

Ett annat problem är att tal kan vara bland de sämre sätten att interagera med en dator. I alla fall sådana datorer vi är vana vid.

Jag tror att de där kärnorna han snackar om kommer att användas till grafik.

Tror det räcker med 1 kärna faktiskt. Windows Vista går ju att styra med rösten.
http://www.istartedsomething.com/20060808/vista-speech-recogn...

Intressant och välkänd artikel om ämnet (för mjukvarusidan av myntet):
http://www.gotw.ca/publications/concurrency-ddj.htm
(The Free Lunch Is Over)

Du tänker lite konstigt. 1, Du förutsätter att vi snackar spel. Dock handlar det om betydligt bredare områden än så. 2, Du förutsätter att man skall fortsätta tänka i gamla invanda tankebanor. Självklart är det detta som måste förändras för att man fullt ut skall kunna skala på fler proppar. Och ja, utvecklingen går absolut åt det hållet. Någon kommer knäcka nöten och vipps har vi fler kärnor än vi kan räkna till. Just på grund av att det är den mest vettiga lösningen på dagens prestandaproblem. Vi har redan hårdvaran för att lösa problemet, men utvecklarna är mil bakom. Det sattsas extrema mängder stålar på detta då det kommer att lösa upp många flaskhalsar som finns i dagsläget. Att tvinga hårdvarutillverkarna att göra mindre och snabbare kretsar fungerar ok, men vi ligger konstant på gränsen till vad som går, dvs, hämmar utvecklingen.

Mycket bra artikel! Nu kan inte programmerarna lata sig längre. Det finns dock exempel på bra kodning: alla Unreal-spel som gjorts. UT3 är från början gjort för att köras på multicores och kan använda så många trådar som det behövs. Spelutvecklare borde titta på dem och lära sig deras teknik (eller ja, koda objekt-orienterat alltså).

Klockfrekvensen har stannat sen länge vid 2-3GHz och kommer så förbli. Multicores är framtiden. Programmerare har bara att acceptera och gilla läget.

1. Nej jag förutsätter inte att vi snackar om spel. Jag gav olika exempel, ett straight-forward. Nog används det i spel men jag såg det mer som när man behöver multiplicera STORA matriser (och mycket), där man redan idag är tvungen att göra det för att kunna arbeta på ett beräkningskluster.

2. Jag beskrev hur spelutvecklare gjort idag. Jag menar inte att de måste följa samma spår för att utveckla framtida spel, men att det är svårt. Helt enkelt därför att man lätt lyckas dela upp ett spel i fyra krovkorniga områden att dela (uppifrån sett). Att dela upp spelet till 128 områden går nog inte, det finns inte så många distinkta komponenter (som är processorintensiva). Man måste göra parallellisering underifrån i varje problem. Men att knäcka nöten för hur man gör det effektivt just det svåra (str8forthakills mardröm alltså).

Vi vänder på det istället, tror du det är lättare att vinna mer prestanda / core än att lösa ovanstående på en 10 års period? Jag tror det är döfött att leva kvar i 80talet när det gäller mjuk utveckling och kräva att hårdvara, enbart, skall stå för prestandaökningen. Att fokusera på dom omöjligheter som redan finns är lika döfött, det behövs nytänk och jag är helt säker på att det kommer. Att vi tycker det är svårt i dagsläget är inget hinder utan enbart en grogrund för utveckling. En sak är säker, fokuserar vi inte på att lösa problemet kommer vi dras med långt dyrare problem.

Jag tror dock att folk underskattar hur svårt det är anpassa algoritmer till att effektivt utnyttja flera kärnor. Och det är inget nytt problem, även om behovet har ökat på senare år. Vissa problemtyper, till exempel matrisoperationer, går väldigt bra att parallellisera medan andra inte ens går i teorin.

Det är, precis som med bildtelefonen, så att folk och fä då och då säger "i framtiden", "om X år", "snart" ..."kan vi styra datorn med tal". Detta är dock en teknik som för den breda allmänheten hör hemma på "Island of Misfit Technologies", tillsammans med bildtelefonen, flygande bilar, bubbelminnet osv.

Saken är ju den att det finns, sedan något decennium, taligenkännande program rent kommerisiellt, till PC. Tekniken fungerar redan hyggligt tillförlitligt, den "hör" fel ungefär lika mycket som en människa, kanske lite disträ. Det omvända är ännu äldre, talsyntas. Problemet är bara att ingen vill ha skräpet idag. Men varför skulle någon vilja ha det i morgon? Mus och tangentbord är ett så oerhört mycket mer effektivt och stringent än att babbla med datorn.

Det finns miljoner tingestar som låter ballt och är fullt tekniskt möjliga nu, sedan länge, eller inom en snar framtid, men som ändå är genomkorkad och som ingen vill ha eller behöver.

Specialapplikationer för handikappade är givetvis en annan sak: här har man kanske inte kan välja bort en ineffektiv inmatningsmetod i datorn, eller behöver en bildtelefon för att kommunicera. Det betyder inte att just tekniken är något eftersträvansvärt. Snarare är den ett nödvändigt ont.

Jepp, typ. Och det är ju just ett nödvändigt ont, inte ett praktiskt sätt för alla att interagera med datorn.

Diktafon är väl en hygglig tillämpning, men det är ju just bara det: en tillämpning, inte ett generellt sätt att effektivt handhava en dator. Vidare är det ju rätt sällsynt med diktamen. De två vanligaste torde vara dels i rättssalen där någon måste kunna ta ansvar för att det blir rätt (även om datorn skulle vara lika bra som en människa så kommer man inte ifrån ansvarsfrågan). Det andra är läkare som ibland av okänd anledning vägrar befatta sig med datorteknik, och måste diktera.

Röstkommandon är däremot en usel idé. Inte ens där användningsområdet är uppenbart (på mobiltelefoner, t.ex., där man kan ringa upp en person baserat på det uttalade namnet) används det i någon högre utsträckning.

När det gäller mer generella kommandon är det än mer oanvändbart. Tänk efter: Vad är det jobbigaste/mest enerverande saker som finns för en datorkännare? Att lösa datorproblem över telefon. Likheten med "dikterade" kommandon är uppenbart. Vem vill göra en så komplicerad aktion som att t.ex. radera alla filer av just två olika filtyper i en katalog? (Detta är svårt och idiotiskt nog att göra med ett GUI). En kommandoprompt är den vettiga lösningen. Men att diktera den kommandoprompten (tänk på att kommandot varierar med aktuell katalog o.dyl) kräver en så omedelbar närvaro att det inte finns några ursäkter att inte använda det bra mycket effektivare tangentbordet.

Det är precis som Elgot säger: