Intel Haswell-E får åtta kärnor i 3,0 GHz

Jo man jag söker en förklaring till varför AMD inte valde att ha 1 x (4*ALU + 4*AGU) med HT utan istället valde 2 * (2*ALU + 2*AGU). Det tidigare alternativet borde ju inte bara sparat transistorer, det borde gett samma flertrådsprestanda men mycket bättre enkeltrådsprestanda. Någon fördel måste det ju finnas med deras val.

AMD ansåg att SMT inte ger en deterministisk förbättring av prestanda. I sak har AMD helt rätt här, tittar man på Intels CPUer med HT så kan användning av HT ge allt från en liten minskning i prestanda (väldigt ovanligt idag) till nära nog en fördubbling av prestanda (en last som har extremt låg CPU-cache hit-rate skulle kunna få detta).

Hur mycket HT ger är väldigt svårt att förutse i genomsnitt verkar de ge ca 30% (om en tråd utför 100 arbete så utför utför båda 130 arbete). CMT verkar vara mycket mer stabil i detta, man får mellan 50-100%, men väldigt ofta ligger man på kring 65-70% vilket stämmer bra med att AMD hävdar runt 80% effektivitet med CMT (d.v.s prestanda per tråd är runt 80% av prestanda man har om bara en tråd per modul används).

Problemet med AMDs logik här är att visst är 70% > 30%, men problemet är att man har så mycket lägre enkeltrådprestanda så en ökning med 70% när båda CPU-trådarna används lyckas i de flesta fall ändå inte komma upp till den nivån som Intel får med en 30% ökning när båda HT används. Det riktigt stora hålet med logiken är att hög enkeltrådprestanda betyder att allt blir snabbt medan hög total prestanda över många kärnor är något som ytterst få skrivborsapplikationer kan dra nytta av. Även på serves finns många laster som kräver hög enkeltrådprestanda, men här finns i alla fall många fall som kan dra nytta av många CPU-kärnor.

Så lite intressant att så många är intresserad av en 8-kärnors Haswell-E. Undrar hur många som verkligen skulle ha någon nytta av en sådan CPU. Själv har jag svårt att se vad jag skulle göra där det skulle vara en fördel, men å andra sidan har jag tillgång till 2x 8-kärnors Xeons och även någon enstaka 4x 8-kärnors Xeon som jag kan använda som "workstation" på jobbet. Men då de typiskt har lägre frekvens än i7 2700/3770/4770 så är de flesta desktop-program långsammare på Xeon-maskinerna (som även har upp till 20M L2 cache) än på i7orna.

Har inte alltid med logik att göra vad folk vill köpa och hur mycket de kan utnyttja det.

Det tar det lång tid innan vissa saker slår igenom på PC-marknaden. Om nu AMD och snart också Intel börjar producera 8-kärninga CPU som så småningom kryper ner i prisklasserna och blir vanligare så kommer också utnyttjandegraden att öka. Det har vi sett många gånger tidigare, t.ex. 2 till 4 kärnor som standard i desktop-CPU eller övergång till 64-bit operativ.

I andra ändan finns också ett motstånd i form av "diminishing returns" där fler och fler blir nöjda längre tid, så utvecklingen på desktop-PC kommer nog plana av medans den fortsätter att öka på andra marknader som den mobila. Där finns det fortfarande en hel del att vinna i prestanda (nån gång i framtiden ska det väl gå att få Android mjukt!) och även minskad strömförbrukning.

Ta fram standarden för vad en riktig kärna är från något standardiserings organ! Jag tror iofs. inte ni kan det för inte ens virtual void kan det. ;)...

Visst kommer vissa program kunna dra nytta av många CPU-kärnor och andelen sådana program kommer öka i framtiden. Men när ett program har prestandaproblem kan man i stort sätt dela in flaskhalsen i två klasser: endera är flaskhalsen kapacitet, d.v.s. hur mycket arbete man kan utföra, eller så är flaskhalsen latens. d.v.s. hur fort man kan slutföra en specifik uppgift.

Så länge man kunde öka enkeltrådprestanda med bättre IPC och/eller högre klockfrekvens så förbättrades båda dessa parametrar hela tiden. Även när man gick från en till två CPU-kärnor så förbättrades båda sakerna, även om förbättringen på den senare enbart kom från att latensdrivna program nu kunde slippa dela CPU-kärnan med bakgrundsprocesser.

Men att gå till fler än två CPU-kärnor förbättrar inte ens i teorin latensen och väldigt många saker man gör på en "vanlig" dator är mer känsliga för latens än för total beräkningskapacitet. Det omvända gäller för serves, där är det oftare att kapacitet är flaskhals än latens vilket är anledningen till att antalet kärnor fortsätter att stiga i ganska snabb takt där, 2008 var det 4 kärnor idag är 2x 8-kärnor rätt standard och det finns Xeons med upp till 15 CPU-kärnor 30 trådar.

Min undrar är därför vad folk tror sig kunna använda 8 kärnor 16 trådar till i en dator som är tänkt för skrivbordsapplikationer. Som jag skrev ovan så är det antalet CPU-trådar som till stor del som sätter svårigheten för programmeraren, 4 kärnor med HT är därför ur den synvinkeln lika komplicerat som att programmera mot en FX-8xxx. Att utnyttja 8 kärnor / 16 trådar fullt ut är rejält mycket svårare än att hantera 8 CPU-trådar, med undantag för programmet som är "embarrassingly parallel" (här finns saker som bl.a. ray-tracing och partikelsimuleringar).

Tycker denna artikel hos XbitLabs är ganska talande. Haswell har runt 10-15% bättre IPC än Ivy Bridge i genomsnitt, i denna artikel kör man rätt många program som kan använda många CPU-trådar långt bättre än det genomsnittliga programmet för skrivbordet, trots det är prestandaskillnaden mellan i7-4770 (4 HSW kärnor med HT) och i7-4960X (6 IVB kärnor med HT) extremt liten.

Den lilla ökningen i IPC som HSW har mot IVB är många gånger tillräcklig för att 4770 till och med ska vara snabbare än 4960X, trots att den senare har 50% mer teoretisk prestanda, nästan dubbelt så stor L3 cache samt dubbelt så hög minnesbandbredd.

Mycket intressant, men prislappen landar väl på ca. 4000+ om man känner Intel rätt?

Det har inte alls med latens eller kapacitet att göra utan handlar mycket enkelt om att server-CPU hanterar flera krävande processer i olika trådar, vilket man inte gör på en desktop-CPU. Om man inte kör vissa typer av rätt specifika applikationer eller rena testprogram som Prime95.

I övrigt mycket ordbajsande för att inte ens fortsätta på det du citerade, hade varit bättre att inte citera överhuvudtaget.

Alltid kul att diskutera med experter på området, kan man ju lära sig något!

Men säger inte det du precis skriver att många CPU-kärnor inte tillför något på desktop för man kör typiskt inte massor med program samtidigt?

Det som gör att man kan använda många CPU-kärnor på servers är att man typiskt hanterar många samtida klienter/anrop, var för sig är dessa oberoende och man kan därför enkelt köra dessa på olika CPU-kärnor. Latensmässigt ligger kravet på dessa i millisekundskala, något som man lätt klarar på en modern CPU. Men de saker man gör på desktop ligger ofta på µs-skala, något som blir ineffektivt att sprida mellan CPU-kärnor.

Men nötter tillåts tydligen!

Ursäkta att jag kastade paj, det blev dåligt och inte min mening. Tänkte ge dig en gliring för att du skrev lite väl långa inlägg om något som kunde sammanfattas i ett stycke.

Men i alla fall, du började prata om att den största skillnaden mellan utnyttjande-grad av desktop-CPU och server-CPU beror på latenser och kapacitet vilket är väldigt svävande och inte alls i den största skillnaden.

Ingen fara, jag tar ytters sällan illa upp

Förstår däremot inte vad som är fel i att flaskhalsar i program verkligen kan delas upp i två klasser, latens-kritiska och "throughput"-kritiska.

När du jobbar interaktivt med systemet så vill du har omedelbar respons, d.v.s det enda du bryr dig om är låg latens. Detta skalar inte alls med CPU-kärnor utan skalar bara med enkeltrådprestanda.

När du har väldigt många individuella problem som helt eller nästan helt är oberoende av varandra, du vill beta av så många som möjligt per tidsenhet och det är OK om det tar ett par tiotals millisekunder per problem så har du ett problem som skalar extremt väl med CPU-kärnor (fast det skalar också med bättre enkeltrådprestanda).

Det jag säger är att desktop-program faller ofta i den första gruppen och servers i den andra (men det finns naturligtvis undantag), så desktop-system med massor med CPU-trådar är bara relevant för en extremt smal grupp och det kommer inte ändras under överskådlig tid, vi lär komma på helt andra sätt att skriva program i så fall och ingen vet ens i teorin hur det skulle se ut. Att kommunicera mellan CPU-kärnor är tyvärr extremt dyrt, relativt vad en CPU-kärna skulle kunna utföra på motsvarande tid.