Intel fyra år före konkurrenterna till trigate

Ja givetvis..... Sen har vi servermarknaden och där är Intel ännu mer dominerande.

Naj!

Om alla hade delat med sig av all forskning helt öppet så hade jag delvis kunnat instämma i det du säger.
Men så sockersöt är inte världen ;).
Men det finns direkta motsatser också. Jag vet inte om sarin-gas har gjort världen så mycket bättre så denna uppfinning är väl snarare dåligt för alla parter utom möjligtvis någon tillverkare som tjänat pengar på att sälja denna hemska nervgas.

Förstår ditt resonemang i övrigt, men ovanstående mening är out of balance.

GPU prestanda är en starkt begränsat på Intel med på grund av minnesbandbredd. Intel använder inte cachen heller, de hade traschat cachens data på nolltid om data lagrats i cpu-cachen då den är alldeles för liten.
Den enda lilla del som möjligen kan få en ytterst liten boost är punkterna cpu'n räknar ut och sedan skickar till grafikkortet. Men hela denna hantering är gjord med anpassning för high latency (kan inte namn, vet bara teknikerna). CPU'n packar punkterna och skickar dem i större block tillsammans med grafikinstruktioner. Texturer mm får grafikken hämta från arbetsminnet när det handlar om integrated graphics (GPU på processorn)

Kul att de fortsätter utveckla trots att de inte är speciellt pressade. Det där med konkurrens kanske inte är så himla viktigt som folk vill få det till?

Personligen tror jag inte att intel skulle slappna av speciellt mycket på själva utvecklingen om AMD konkade. Priserna skulle dock sannolikt gå upp. Anledningen till detta är för att intel fortfarande behöver ha folk som köper sina processorer. Om de inte utvecklar något nytt så är det ju inte speciellt stor skillnad på en ny processor och en som är 3-4 år gammal så varför skulle folk då uppgradera? Man skulle ha sin dator längre och intel skulle inte få in lika mycket cash.
Högst personlig uppfattning som jag är ganska säker att en stor del av läsarna inte delar

Roligt att folk säger de kör med fula knepp, knappat. Knappast varken eller mindre än något annat företag. Hade du ägt ett företag vist fan hade du försökt allt för att få mer omsättning.

Du kan ju fundera på varför AMD styckat av Global Fundries som ju skedde först 2009.... Och AMD64 kom med en full spec år tvåtusen jämnt. Första CPUn med den instruktionen var deras serverprocessor Opteron som kom redan 2003. Opteron som sen dess haft stor framgång i stora kluster tex.

SNB använder inte L3 cachen som den ENDA minnet, det används som ett scratch-pad minne, z-buffer, texture cache (inte rent texture minne) samt som kommunikationsmedium mellan GPU och CPU.

"Unlike AMD’s Fusion architecture or Ironlake, Sandy Bridge is intended to pass data between the CPU and GPU using the LLC. Since the GPU is weakly consistent, while x86 is strongly consistent, synchronization is needed to ensure safety when data is passed to the CPU. In contrast, the default coherency behavior of the ring and LLC is sufficient to guarantee correctness when the GPU receives data from the strongly consistent CPUs. Compared to accessing memory, on-die communication is vastly higher performance and more power efficient."

http://realworldtech.com/page.cfm?ArticleID=RWT080811195102&p=3

LLC = Last Level Cache, vilket är L3 cachen på SNB.

Du har helt rätt, om det var spel vi talade om. Anledningen till att spel är skrivna på detta sätt är just att det är extremt innefektivt för CPUn att läsa gfx-minne, så i spel gör man alla beräkningar som CPU måste göra först sedan skickas allt till grafikkortet via PCIe och man läser ALDRIG tillbaka information. En webbläsare != spel och den använder uppenbarligen grafik-kortet på ett annat sätt då HD 2000/3000 och GPUn i Llano (har inte testat med Llano själv, bara sett resultat från test andra kört) i väldigt fall presterar bättre än diskreta GPUer med eget RAM gör. NOTERA: jag sa aldrig något om hur stor skillnaden är, den är inte jättestor, men poängen är att ett diskret grafikkort, som totalt demolerar både HD3000 och Llano i ett spel kan mycket väl vara (något) långsammare på att accelerera en webbläsare.

Det finns även en rad saker som man i teorin kan använda GPGPU optimeringar för, men i praktiken är det en dålig idé just därför man måste alterna mellan att köra beräkningen på CPU och GPU. Även här har integrerade designer en fördel då de kan kommunicera väldigt fort sinsemellan, mycket fortare än en CPU+diskret GPU med eget RAM. Nu kan inte SNB användas i OpenCL, men i Llano och Brazos har man sett dessa fördelar och Ivy Bridge kommer ha stöd för OpenCL + betydligt snabbare CPU<->GPU kommunikation jämfört med Llano och Brazos tack vare att både CPU och GPU kan använda L3 cache.

Det är nog få sidor på nätet som pressar grafkkortet än så länge. Om du mäter prestanda på en sida så mäter du förmodligen annat som javascriptprestanda, bearbetning av html mm. Har sett enstaka demosidor som har massor av objekt som rör sig, då börjar det kanske bli lite mer jobb men normala sidor är löjligt enkla och bearbeta.

Om du skall räkna ut 5 tal är det rätt puckat och använda GPU'n, det gör processorn utmärkt. Skall du räkna ut tusentals tal blir det bättre.
Har för mig att nästa version av radeon kommer ha en hel del nyheter för bättre programmerbarhet, nVidia kör hårt på det spåret med

Angående cache: Minne kommer alltid först från arbetsminne. Cache blir bara användbart när minne används en gång till och cachen är tillräckligt stor för att mellanlagra vad som redan använts.

Mycket möjligt, men det ändrar inte det faktum att på de sidor vi nu har som i alla fall till viss del är GPU accelererade så är de SNABBARE på system med integrerad GPU. JS och HTML hanteringen borde rimligtvis vara precis lika snabb oavsett GPU, så att det är snabbare på system med integrerade GPUer borde ju rimligtvis betyda att de, av någon anledning, trots allt är bättre på att accelererar denna typ av last. Jämför man separat GPU+eget RAM med en integrerad GPU så är det enda de är bättre på rent sifferexercismässigt två saker: 1. CPUn har lägre latens mot det RAM som GPUn använder (båda använder ju "vanligt RAM"), CPUn har högre bandbredd mot det RAM som GPUn använder.

Det har var ett praktexempel på hur man använder en straw man i sin argumentationsteknik. Det var INTE det jag skrev. Tänk i stället att du jobbar på ett indata som består av ett par miljoner tal, första transformationen är något som bäst utförs av CPUn, nästa transformation är något en GPU kan utföra effektivt. Om det var slut här så fungerar det bra både med integrerad och separat GPU. Men tänk om man måste göra flera steg och nästa steg utförs mycket mer effektivt av CPUn... Detta är mycket vanligt i praktiken, en GPU är relativt inneffektiv (jämfört en CPU) på beräkningar som innefattar hopp. Dagens GPUer är extremt ineffektiva på beräkningar där transformen av data kräver väldigt olika lång tid på olika datapunkter, vad som händer i praktiken är att tiden för beräkningen i alla parallella pipor i GPUn kommer ta lika lång tid som den LÄNGSTA beräkningen. En CPU har absolut inte det problemet.

Hade du läst artikeln jag länkade hade du inte skrivit detta. L3 cachen på SNB kan användas till en rad olika saker, det är t.ex. möjligt och till och med lämpligt att alla vertexes skrivs hit och konsumeras av GPUn därifrån. Denna data kan mycket väl skapas av CPUn och aldrig legat i RAM. I fallet webbläsare då kan CPUn har gjort en del av HTML rendreringen och vill nu göra "accelerated composting" med GPUn. Även i detta fall kan data mycket väl helt eller delvis ligga i L3 cache redan, som GPUn direkt kan läsa ifrån.

Det är väll snarare det som är grejen.
Den som uppfann hjulet hade inte en stor armé advokater i ryggen som tvingade alla andra att betala en licensavgift till honom om de ens blev godkända som att tillverka hjul.
osv osv osv.

Nej, det är inte självklart.
Att vi har massor med lagar och regler som reglerar det hela gör det snarare till motsatsen av självklart, vad det nu är.

En liten snabb historielektion kanske kan vara till hjälp?
http://www.kkv.se/t/Page____709.aspx

Har du fler frågor så tycker jag du kan vända dig till google eller kanske läsa en kurs eller nått.