64 kärnor kan bli vanligt redan 2012

Sen att man måste kunna tala extremt tydligt när det gäller röstigenkänning är väl ett problem. Visst, mjukvaran blir bättre med tiden men samtidigt så kan den inte göra under. Särskilt inte med någon som mig som blivit beskriven som att jag pratar som "Farmer Fran" i Waterboy av vänner och min flickvän säger att jag pratar som Karl Johnsons karaktär "PC Bob Walker" i Hot Fuzz.

Ni som sett filmerna förstår att knappt om man fokuserar sig så hör man vad de säger.

Tror det kvittar hur bra AI och hur många kärnor AIt måste köras på för att fungera så kommer datorn att förstå vad jag säger. Att ens öppna ett program eller diktera något via datorn är en pain in the ass. Den skriver ju inte alls vad man säger. Eller så gör den det...

64 kärnor utan mjukvara som stödjer det kommer dock inte att vara någon större hit men folk bryr sig inte om de kan använda det ifall det är det "nya".
Quad processorer verkar bli 2008 års nya innegrej på datorer från elgigaten och PC-city.

Vad folk har nytta av och vad som är tufft är två olika saker.

Jag tror framtiden ligger inom kompilatorer som kan ta en del av arbetsbördan från programmeraren och dela upp programmet i de trådar som verkar möjliga. Då kan de gamla programmerarna sitta kvar i det gamla medans de nya lär sig den nya tekniken och vi alla tjänar på program som är flertrådade.

Mehhhh... Det finns ingen kompilator som kan göra det (förutom möjligen Scale till Trips-processorn, men det kommer ju aldrig till de nuvarande x86-processorerna ändå, och det handlar ju mer om single-threading på flera kärnor, vilket iofs inte är helt fel).

För att koda multitrådat måste man tänka om och programmera objekt-orienterat. Finns inga genvägar längre. Om man inte gör det kommer man inte kunna öka prestandan i sina program i framtiden, eftersom prestadan per kärna kommer att hållas någorlunda oförändrad i framtiden.

Iofs skulle man kunna använda sig av SIMD-liknande hårdvara (SSE, GPU, PPU, Cell, etc) som verkligen kan boosta prestandan men det funkar ju bara på vissa program.

Att programmera objektorienterat är väl inte nödvändigare än vanligt?

Nu är jag iofs bara programmerat på det "vanliga" sättet och har inte lärt mig objekt-orientering riktigt men som jag förstått så måste programmet vara programmerat på ett objekt-orienterat sätt för att kunna boosta prestandan med flera trådar och få det att köras på ett effektivt sätt.

Intel kommer att pusha hårt för detta med detta: "64kärnor kan bli vanligt redan 2012".

Anledningen är väl deras kommande satsning på RealTime raytracing.

Redan 2010 kommer det alternativ för entusiasterna och 2012 hoppas man det bli mer mainstream.

Jag personligen ser fram mot detta med Realtime raytracing.

Realtime raytracing vore inte helt fel. Blir en smärre revolution av spelgrafiken iaf.

Nä, det finns inte men vad hindrar det från att utvecklas?
Redan idag så gör kompilatorerna mycket av det arbete som programmerare förr fick göra för hand.

Med tanke på hur länge vi haft c++ nu så borde object-orienterad programmering blivit vanligare.
Alla program kan ju dock inte tjäna på att bli uppdelade.

Det svåra är att lyckas dela upp programet i separata delar som är minimalt beroende av varandra. Implementationen är av mindre betydelse. Och det räcker med att en liten del av programmet inte kan anpassas för att en stor del av prestandavinsten skall förloras. Amdahls lag ger följande kurva:

Precis, just därför vi behöver anpassa oss till muli-core's för att inte bli ståendes när utvecklingen når sin spets.

Vad syftar du på nu? Det är väl inte längre mellan innovationerna nu än förr? Att endast öka frekvenserna var väl höjden av innovationsbrist?

Javisst kan det verka vansinne! men om Intel menar allvar med RealTime- Raytracing så lär vi snart vara där.

I dagens läge kan man få hysfad Realtime-Raytracing med 16 kärnor, vilket teoretiskt kan ske redan 2009 då moderkort/processorer för detta kommer att finnas på marknaden.

64 kärnor är nog det ännu lite hemliga Polarisprojektet?

Medan projekt Larrabee kommer att lanseras i slutet på 2008.

Industrin kan behöva 64 kärnor - och en skön renderingsstation blir det.

64 kärnor kan också behövas för att ge Nvida på tafsen med Intels egen
high end lösning för grafik.

Med 64 kärnor och Realtime Raytracing, lär vi få se spel med nära fotorealistiska renderingar.

Men jag håller med om att detta kan verka lite vansinne för många.

Googla: och läs in dig på RealTime Raytracing, så kan man klura ut varför Intel beter sig som de nu gör.

I vilket fall som helst är detta som Intel nu jobbar med rätt spännande.

Troligen blir det till en början en mix av renderingstekniker för speltillverkarna - men RealTime Raytracing är längre inte någon fantasi.

Intel har bl.a köpt "Havok" och "projekt Offset" och fler köp är nog att vänta?

Samtidigt anställer man fler och fler experter från spel och 3D industri.

Vad vill då Intel med dessa köp och anställningar? jag tror som flera andra, att Intel kommer att utveckla en egen "spelmotor" som man sedan ger bort till speltillverkarna för att pusha för att RealTime Raytracing ska slå.

Framtiden here we come!

Här finns en artikelserie om detta:

1.http://www.pcper.com/article.php?aid=334
2.http://www.pcper.com/article.php?aid=455
3.http://www.pcper.com/article.php?aid=506
4.http://www.pcper.com/article.php?aid=530

Läser man igenom detta och även det som Nvidia svarar på, så förstår man att de är lite skärrade, då en saker som Nvidia påstår är fel enligt många från Intel.

Hehe! vem ska man lita på?

Jag förstår inte varför realtime-raytracing skulle vara något som general-purpose processorer skulle utvecklas för specifikt.

Vad har objektorienterad programmering med det hela att göra? Finns gott om exempel på språk som inte är objektorienterade som har stöd för trådar och processer.

För att ta ett exempel (och lobba lite för mitt nya favoritspråk ), Erlang (http://en.wikipedia.org/wiki/Erlang_programming_language). Erlang är ett 20 år gammalt språk utvecklat av Ericsson med parallellism, distribuerbarhet och feltolerans som grundstenar, ursprungligen för användning i telefonväxlar. Vill du skapa 10 000 eller 100 000 processer? Inga problem. Finns benchmarks för upp till så många som 20 miljoner processer. Märk väl att det handlar om processer och inte trådar. Processer delar inte data med varandra, vilket gör att man slipper en hel del klassiska synkroniseringsproblem. Inget tjafs med semaforer eller dylikt. Data kan istället skickas vid behov genom "message passing" processerna emellan. Vill du distribuera program över flera noder (över ett nätverk exempelvis)? Inga problem. Det funkar lika enkelt som om processen hade körts lokalt. Det finns även stöd för extremt häftiga grejer som hot-swap av kod (lite slarvigt uttryckt: uppdatera en exekverande process med ny kod on-the-go)

Inte jag heller egentligen. Men samtidigt så kanske man kan göra paralleller till "special-purpose" SIMD-instruktioner, t.ex. MMX eller SSE. Möjligt är ju att raytracing, som ju är ett optiskt problem, kan användas mer generellt för att t.ex. analysera signalpropagering?

DwarfForge: Erlang är onekligen ett coolt språk. Som jag velat läsa om/lära mig under lång tid. Vet du några bra nybörjarsidor/böcker om Erlang? Jag antar, eftersom språkparadigmet är så speciellt, att även en professionell programmerare behöver nybörjarhjälp?

Det är inte svårt att skriva program som har flera trådar, inte ens i c++ (som för övrigt är ett bra språk). Det svåra är att formulera den uppgift som skall lösas så att belastningen fördelas över dessa på ett bra sätt. Trådarna skall inte heller blockera varandra i alltför hög grad.

Det är naturligtvis inte svårt att tråda i sig, men det går bara under vissa förutsättningar: Problemet måste innehålla parallellitet och mycket sådan. Minsta lilla synkroniseringsbehov eller seriellism straffar sig hård enligt Amdahls lag, se Elgots tidigare inlägg.

Intressant sätt att försvara en vandringssägen. Så länge som inga bevis finnes, är det sant att Mr Gates sa så. Men bevis på motsatsen godtas ej.

Själv är jag inte benägen att tro att Gates skulle ha sagt något sådant, det trodde jag inte ens innan jag läste dementin.

Så, "egna historier" åt sidan, du får nog ta fram en icke-anekdotisk referens.

...och tro mig, det finns bättre argument mot Microsoft än ad hominem...

Och det är ju inte fy skam. Tänk, seti@home på 63 kärnor och operativsystem + övrigt på den sista.

Jag kan rekommendera http://erlang.org/starting.html som utgångpunkt.
I bokväg har jag för egen del funderat på att införskaffa Programming Erlang av Joe Armstrong (en av Erlangs skapare), ISBN 978-1-9343560-0-5. Finns till salu för 164:- på adlibris enligt prisjakt.nu

Eftersom Erlang är ett funktionellt språk underlättar det naturligtvis om du har kunskaper i andra funktionella språk.

För övrigt kan man inte prata om Erlang utan att nämna klassikern Erlang the Movie, http://video.google.com/videoplay?docid=-5830318882717959520

Den recenserades på slashdot i höstas, om du inte redan har sett det:
http://books.slashdot.org/article.pl?sid=07/09/05/1410213

Raytracing redan 2015 kanske ? Och photon mapping 2020-2025

Precis. Skeppsdatorn i Star Trek Voyager som de snackar på och ger order, typ höja värmen i rummet, slå på lyset och replikera en oxstek. Det är röstkommandon bra till. Men att styra en dator man sitter framför är inte särskilt effektivt. Ibland när jag är riktigt lat använder jag vistas inbyggda som fungerar rätt hyggligt ändå.

Jag tror du missförstår mig, jag är inte en av dem som buar för att det kommer flera kärnor, jag gillar det.

AMD Phenoms minneskontroller fungerar väl så att den kan arbeta enskilt för olika kärnor (2x single channel som inte är dual channel alltså). Det kanske blir mer så i framtiden? Nehalem ska ju ha tripple channel, det kanske går att koppla isär den.
Då borde alltså olika kärnor att helt samtidigt läsa/skriva till minnet om jag är med rätt?

Och varje tråd behöver ju inte arbeta på samma data. Ett eget local store för data den arbetar på.
Och det är mjukvaruproblem också. Man får försöka utveckla algoritmer som är mer lock-free, wait-free.

För övrigt roligt med ray tracing. Våran ray tracer i ett projekt levererade sin första bild idag, lite bugg med heltals absolutbelopp istället för flytals absolut men sen fungerade den perfekt.
Senare under optimeringsfasen så borde man ge sig på att parallellisera den till flera trådar. Men den är ännu inte direkt lämplig för realtime hehe.

Japp, det där med 2x64-bit single-channel (unganged mode) ger en rätt fin boost i multitrådade program. Riktigt trevligt gjort av AMD. Iofs har ju GPU:n liknande access till minnet, typ 8x32-bit (256-bit) som på R580.

Men det går också att göra flera läs- eller skrivningar samtidigt till samma minneskanal - om bank interleaving är aktiverat förstås. Dock funkar det bara om minnet har flera minnesbanker. En enkelsidig minnessticka är alltså en minnesbank. Jag märkte faktiskt en stor boost själv (i minnesbandbredd åtminstone) när jag bytte från enkelsidiga minnen till dubbelsidiga minnen. Kan ju vara nåt att ha i åtanke.