Bärbara datorer med Intels nästa generation processorer dröjer till år 2019

Permalänk
Medlem
Skrivet av brize:

Du är medveten om att det är IPC som jämförs när man benchar samma svit vid en given frekvens (om vi bortser från övriga förbättringar gällande ram, bussar osv)?

Har du läst denna?
https://en.wikipedia.org/wiki/Instructions_per_cycle

Skrivet av brize:

Ditt inlägg ovan om 25% bättre ipc motsvarar ganska bra skillnaden vid 4.8ghz och genomsnittet 2-3% per år så du bevisar din egna poäng.

Då får du nog läsa en gång till.

Jag refererar till artikeln från SweC-startsidan häromdan där det konstateras att en Covfefe Lake har ca 25% högre IPC än en Sandy Bridge. Klockfrekvensen har ingenting med ökad IPC att göra, utan uttrycker hur mycket jobb som utförs under en klockcykel.

Mellan en sketen Conroe och en Covfefe Lake är det förstås ännu mer skillnad. x86-processorer med höga klockfrekvenser är liksom inget nytt.

Skrivet av brize:

@wovsers visar upp en fin grafik som säger samma sak fast vid 4ghz. Att mäta IPC mellan generationer är väldigt svårt men att köra en och samma bench i en svit är så nära sanningen man kan komma, så vad är det du vill bevisa med din sophögs-analogi?

Grafiken visar skillnaden i en benchmark, och om du kan läsa diagrammet rätt så är en Covfefe Lake ca 76% snabbare än en Conroe på ett benchmark. Nu består ju dock inte datoranvändning av att sitta och köra benchmarks 100% av tiden för lejonparten av alla datoranvändare. En Conroe är den brinnande sophögen i sammanhanget eftersom den är hopplöst och efterblivet långsam jämfört mot en Covfefe Lake till daglig användning, även om det säkert går att hitta enstaka benchmarksituationer där den fortfarande syns i grafen.

Permalänk
Medlem
Skrivet av Sveklockarn:

Väl medveten om vad IPC är, vad exakt är det du vill att jag ska läsa igen i artikeln? När du kör exakt samma beräkning vid exakt samma klock är det mängden instruktioner per cykel som (grovt) avgör resultatet, var någonstans säger wikipedia något annat? När du testar IPC mellan olika generationer som har olika förutsättningar så finns det inget bättre sätt att jämföra dem än just det, samma beräkning vid samma frekvens. Vet du något mer så får du gärna utbilda mig.

Skrivet av Sveklockarn:

Jag refererar till artikeln från SweC-startsidan häromdan där det konstateras att en Covfefe Lake har ca 25% högre IPC än en Sandy Bridge. Klockfrekvensen har ingenting med ökad IPC att göra, utan uttrycker hur mycket jobb som utförs under en klockcykel.

Exakt, därför är det viktigt att bencha vid samma klocka för att få en uppfattning om mängden instruktioner som kan exekveras. Vad är det du tror gör skillnaden när vi benchar vid samma klocka?

Skrivet av Sveklockarn:

Mellan en sketen Conroe och en Covfefe Lake är det förstås ännu mer skillnad. x86-processorer med höga klockfrekvenser är liksom inget nytt.
Grafiken visar skillnaden i en benchmark, och om du kan läsa diagrammet rätt så är en Covfefe Lake ca 76% snabbare än en Conroe på ett benchmark. Nu består ju dock inte datoranvändning av att sitta och köra benchmarks 100% av tiden för lejonparten av alla datoranvändare. En Conroe är den brinnande sophögen i sammanhanget eftersom den är hopplöst och efterblivet långsam jämfört mot en Covfefe Lake till daglig användning, även om det säkert går att hitta enstaka benchmarksituationer där den fortfarande syns i grafen.

Som sagt, bench vid samma klocka ger resultat som visar skillnaden i IPC för enkeltrådig prestanda. Jämför exempelvis P4 mot a64 där P4ans långa köer tvingade den att kasta mycket data, därför behovet av hög frekvens för att få bra prestanda. A64 hade å sin sida en kortare kö som gjorde att den kunde köra långt många fler instruktioner på kortare tid och därför inte led lika mycket när den behövde kasta data och tömma kön vilket gav högre prestanda vid lägre klock.

Visa signatur

Fyra ord före katastrofen: "Lugnt, vi har backuper".

Permalänk
Datavetare
Skrivet av wowsers:

Skulle nog säga nej (info nedan riktat till alla).

Här är IPC för enkeltrådad cinebench R15 vid "4GHz" på ganska många generationer av Intel och AMD processorer:
http://i.imgur.com/uuMOToE.jpg

Om man räknar linjärt hamnar Intels prestandaökningar (från conroe) på ungefär 6.8% per år, om man räknar relativt till prestandan från den tidigare generationen hamnar det på ungefär 5.6% per år.

(notera att jag räknar zen som 162 istället för 165 med frågetecken med hjälp av riktiga benchmarks och extrapolering)
För AMD får vi 7% linjär ökning av IPC per år eller 7.1% om man jämför med genomsnittlig ökning, men i verkligheten har det varit extremt lite ökning och sedan en enorm ökning, till skillnad från den mer jämna prestanda per år som Intel har haft.

Vad som är mest relevant är att detta mest är flyttal (tror SSE2?), så det säger ingenting om hur heltalsprestanda har ändrats.

Edit: Även om just flyttalsprestanda har ökat "mer" för AMD så har hastigheterna (och IPC relativt till AMD) varit högre för Intel.

Lysande inlägg, plus på den!

Cinebench använder SSE1, specifikt "scalar single" delen av SSE. För x86_64 ersätter "scalar single" i SSE och "scalar double" i SSE2 gamla x87 dyngan för skalära flyttal.

De flesta tänker nog på SIMD när de ser SSE, det är den andra delen av SSE "packed single/double", d.v.s. där man utför samma operation på flera separata data-element.

Angående det här med procenträkning, ser väl ändå ut så här

T: Total procentuell förändring y: antal år x: genomsnittlig årlig förändring T(x,y) = x^y löser man ut x blir det x = e(ln(T(x,y)/y)

Det betyder i så fall att om totala ökning från 2004 till 2017 (2017-2004=13 år) är

  • Intel: 177 / 52,27 = 3,39x => 10 % ökning per år

  • AMD: 165 / 72 = 2,29x => 6,6 % ökning per år

Eller om vi använder Sandy Bridge som bas, 2011 till 2017 (6 år)

  • Intel: 177 / 134,73 = 1,31x => 4,6 % ökning per år

  • AMD: 165 / 89 = 1,85x => 11 % ökning per år

"Tricket" är alltså att släppa en krets med värdelös IPC, sedan förbättrar man från det och blir kung?

I Intels fall är i så fall Atom nya kungen, ~50 % IPC ökning från Bonell/Saltwell till Silvermont/Airmont. Sedan ~30 % IPC ökning mellan Airmont till Goldmont och nu senaste ~15 % till från Goldmont till Goldmont Plus.

Fast enda som spelar roll är ju slutresultatet... Och slutresultatet är prestanda man faktiskt ser i applikationer. Där är IPC i isolation meningslöst, enda som betyder något är produkten frekvens * IPC och i varierande grad antal CPU-kärnor och kapacitet på SIMD-enheter. Dock beror effekten de två sista kraftigt på typ av problem man försöker lösa.

Är i.o.f.s. i någon mening imponerande att Goldmont Plus numera passerat Core2 i IPC (och faktiskt prestanda om man tittar jämför med tidiga C2Q som klockade ungefär som J5005).

Om nu Intel är så usla: varför har ingen förutom Apple nått lika hög IPC? Apple kan inte klocka sin design lika högt och det finns ett motsatsförhållande mellan hög IPC och kretsens maximala frekvens. Och varför har Apples IPC ökning tacklat av så mycket nu när de nått Intel nivå (64-bitars ARM är klart bättre designad jämfört med x86, men Apple lär ändå inte nå mer än 10-30 % högre IPC jämfört med Intel p.g.a. ISA, är i.o.f.s. rätt viktigt när inte kommer lägre i andra riktningar...)?

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

Fast enda som spelar roll är ju slutresultatet... Och slutresultatet är prestanda man faktiskt ser i applikationer. Där är IPC i isolation meningslöst, enda som betyder något är produkten frekvens * IPC och i varierande grad antal CPU-kärnor och kapacitet på SIMD-enheter. Dock beror effekten de två sista kraftigt på typ av problem man försöker lösa.

IPC över generationer är svårt men om man ska jämföra utveckling och förfining av en arkitektur är det ett intressant mått. Som jag skrev i exemplet ovan, P4 med netburst var som bekant designad för höga frekvenser med lägre IPC och vi såg hur det gick. Motsatsförhållandet som du nämner är problematiskt för alla designer och tillverkare och det är egentligen där som en av de stora utmaningarna ligger.

Visa signatur

Fyra ord före katastrofen: "Lugnt, vi har backuper".

Permalänk
Datavetare
Skrivet av brize:

IPC över generationer är svårt men om man ska jämföra utveckling och förfining av en arkitektur är det ett intressant mått. Som jag skrev i exemplet ovan, P4 med netburst var som bekant designad för höga frekvenser med lägre IPC och vi såg hur det gick. Motsatsförhållandet som du nämner är problematiskt för alla designer och tillverkare och det är egentligen där som en av de stora utmaningarna ligger.

Håller helt med där. IPC är vettig mellan generationer, dock måste man även väga in ökningar i frekvens där.

Kikar man på P4 så började ju IPC illa, blev ännu värre med Pretscott (längre pipeline för att nå högre frekvenser), men ändå var det ju hela tiden en uppgående trend för faktiskt prestanda.

Att jämföra IPC mellan radikalt olika mikroarkitekturer är nära nog ett hopplöst projekt. Beroende på typ av arbetslast kan man få allt från att Zen har högre IPC jämfört med Skylake till att Skylake har ungefär dubbel IPC... Här måste man alltid klart specificera vilken typ av applikation som avses.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

Håller helt med där. IPC är vettig mellan generationer, dock måste man även väga in ökningar i frekvens där.

Kikar man på P4 så började ju IPC illa, blev ännu värre med Pretscott (längre pipeline för att nå högre frekvenser), men ändå var det ju hela tiden en uppgående trend för faktiskt prestanda.

Att jämföra IPC mellan radikalt olika mikroarkitekturer är nära nog ett hopplöst projekt. Beroende på typ av arbetslast kan man få allt från att Zen har högre IPC jämfört med Skylake till att Skylake har ungefär dubbel IPC... Här måste man alltid klart specificera vilken typ av applikation som avses.

Ja, pipelinen skadade dem ordentligt med Prescott. Glömmer aldrig presentationen som AMD körde med a64 vs P4 där de visualiserade hur pipen fylldes och sen fick datan kasseras, när Intel hade fyllt sin pipe igen hade AMD redan kört sin två gånger. Däremot gjorde Intel ett fantastiskt fint jobb med att lära av sitt misstag sen med vidareutvecklingen av P3

Visst är det så, ska man få ett någorlunda vettigt resultat måste man ta många olika sviter som kör olika instruktioner och sen väga ihop resultaten, men även då får man som bäst en fingervisning. Klart intressant dock att en 2600k i 5ghz är någorlunda konkurrenskraftig med en 8700k som körs i 4ghz. Motsvarar 25% IPC ganska bra (i just det här exemplet).

Enkeltråd cinebench:
2600k 5ghz = ~176
8700K 4ghz = ~176,6

Visa signatur

Fyra ord före katastrofen: "Lugnt, vi har backuper".

Permalänk
Medlem

Y-serien verkar helt död, tittar man vad som kommer för nytt och vad som finns ute till försäljning så finns det nästan inget att välja på. Är det intresset som är lågt?

En fläktlös dator med hyfsad prestanda som dom flesta klarar sig på borde väl intressera folk?

Visa signatur

Chassi : BitFenix Prodigy Svart mITX Moderkort : Asus P8Z77-I DELUXE mITX CPU : Intel Core i7 3770K RAM : Crucial 16GB (2x8192MB) CL9 1600Mhz Ballistix Sport

Permalänk
Medlem

Jag tycker det är först nu de senaste månaderna som jag har sett 8000-serien på bred front så jag ser inte riktigt att detta är ett jätteproblem när AMD knappt syns till. Var är Thinkpads med Ryzen 7 Pro t.ex? Jag ser att E-serien är på gång med Ryzen men det dröjer nog ett par månader till innan de hittar ut i butik.

Visa signatur

CPU: Ryzen 5 1600 GPU: Asus GeForce GTX 1060 6GB DUAL Moderkort: MSI B350M Mortar
RAM: 16GB Corsair Vengeance DDR4 3200MHz PSU: Corsair RM750X
Laptop: ThinkPad T480s, Core i7 8550U, 16GB RAM Mobil: Samsung Galaxy S10

Permalänk
Medlem

Intel släppte ju i sommar sin 8:e generations processorer med kaby lake refresh, varför skulle det vara en nyhet att det dröjer till 2019 för nästa generation? Eller har jag förstått något fel?

Permalänk

åh nej jag som nyss köpt en i7 8750H!!! vad skall jag nu göra, min processor är ju skräp, skulle väntat ett år till!!!!

skämt å sido.

Där har hänt rätt mycket mellan SB och CL som Cinebench inte visar. Även om det är en del av prestandan man kan förvänta sig, så är det som någon annan sa att där finns så mycket annat bakom hur datorn presterar än bara IPC och den biten av SSE som CB15 använder.

Där finns så mycket mer man kan mäta om man vill ha en rättvis bild

Permalänk
Medlem

14nm får verkligen hänga med länge. Hur många generationer av 14nm blir det, 5 stycken? Innan var det två per tillverkningsteknik. Kanske det blir svårare och svårare och vi får ha 10nm i uppåt 10 år sen eller nått. 14nm kom väl med broadwell för 4 år sen. Kommer ta iaf ett år till innan 10nm verkar det som nu.

Skickades från m.sweclockers.com

Visa signatur

Asus B650 TUF, Ryzen 7600X, 32GB 6000mhz DDR5, Corsair RM1000X, Powercolor 6900XT Red Devil Ultimate, 360mm Corsair AIO, MSI Velox 100P Airflow. Kingston KC3000 M.2.

Permalänk
Skrivet av shogun-r:

Y-serien verkar helt död, tittar man vad som kommer för nytt och vad som finns ute till försäljning så finns det nästan inget att välja på. Är det intresset som är lågt?

En fläktlös dator med hyfsad prestanda som dom flesta klarar sig på borde väl intressera folk?

Amber Lake-Y är ju nästa iteration i den serien.
Jag är personligen oxå ett stort fan av fan-less. Vette fan när den släpps. Men jag hoppas den blir fan-tastisk!

Visa signatur

Dator: EEE901 N270/ 1GB / 20GB SSD ... Kraftigt nedbantat/tweakat Win7 x86 for speeeEED!
Facebook användare? Hatar tidslinjen? gå med i denna FB-grupp:
Undo Timeline ...med lite tur får h*lvetet ett slut!

Permalänk
Medlem
Skrivet av lastninja:

Jag är personligen oxå ett stort fan av fan-less. Vette fan när den släpps. Men jag hoppas den blir fan-tastisk!

*badum tish!*

Man blir fan less på att inte ha fläktar.

Permalänk
Skrivet av Sveklockarn:

*badum tish!*

Man blir fan less på att inte ha fläktar.

Din kommentar gjorde susen. Den gjorde att folk kommer tycka jag är blåst.
Jag kommer tappa alla mina största fans till dig - which means less fans for me!

Visa signatur

Dator: EEE901 N270/ 1GB / 20GB SSD ... Kraftigt nedbantat/tweakat Win7 x86 for speeeEED!
Facebook användare? Hatar tidslinjen? gå med i denna FB-grupp:
Undo Timeline ...med lite tur får h*lvetet ett slut!

Permalänk
Skrivet av Sveklockarn:

Och där hade vi all information som behövdes.

Det är inte för inte som man säger att det finns lögn, förbannad lögn och benchmarks. Man kan ju säga att kanoner inte ändrats sedan 1500-talet eftersom även dagens kanoner har ett eldrör, men det är ju inte speciellt meningsfullt att försöka argumentera utifrån det.

Att någon (?) dragit slutsatsen att en Coffee Lake är en trimmad Conroe känns som något som är svårt att bemöta på något meningsfullt sätt, men då kan man ju åtminstone dra slutsatsen att AMD måste vara ännu mer efterblivna som inte lyckas komma ikapp.

Det finns en artikel på hardforum där de göra massa benchmarks mellan en sandybridge och en modern cpu. På de 8 åren, så presterar den moderna cpun 30% bättre. Det är inte orimligt? Du förväntar dig väl inte 100% bättre fps på 8 år.

Om du räknar lite på det, så motsvarar 30% bättre snitt prestanda (cpu, fps, etc), en prestanda ökning som motsvarar 3.3% per år.

Sen är det missvisande att mäta IPC, eftersom IPC inte säger så mycket. För det första, en viss typ av programvara kommer inte att kunna parallelliseras hur bra som helst. Mao, man kan inte få ut mer IPC än vad taket säger. T.ex. serverlaster har en typisk IPC på 0.5-0.8. Då är det dumt att satsa på en hög IPC cpu när man ska köra serverprogram. Istället är det bättre att satsa på RAM bandbredd och annat. Intel är bra på cpu cache, men suger på RAM bandbredd. Det är ett av skälen till varför Intels cpuer suger som servrar. En SPARC med låg IPC utklassar Intel på serverlaster, trots att Xeon har hög IPC. Sen finns det folk som tror att en hög IPC cpu som Intel måste vara bättre än låg IPC SPARC på serverlaster, trots att benhcmarks visar att SPARC är mycket snabbare än Xeon.

Jag undrar vilken typisk IPC spel har? Om spel har, säg, typisk IPC på 3, så är det dumt att köpa en cpu med IPC med 6 eftersom det kommer inte bli snabbare än 3 i IPC. Den som är kunnig datalogi vet att vissa typer av problem inte går att parallellisera (de tillhör komplexitetsklassen P). Och då är det korkat att tro att högre IPC automatiskt ger mer prestanda. Prestandan du får ut beror på vad för arbetslast du ska köra, och inte hur hög IPC din cpu har. En arbetslast har en typisk IPC, och du får inte ut mer prestanda ju högre IPC en cpu har.

Det är bättre att mäta riktiga benchmarks, än IPC. Och snitt benchmarksen mellan 8 år för Sandybridge till någon modern Intel cpu, blir 30% totalt. Dvs, 3.3% per år. Enkel matematik. Det är inte alls konstigt. Så skit i allt prat om IPC, det är korkat. Det är okunnigt att tro att en högre IPC är bättre. Det är lika smart att köpa en bil med maxhastighet på 300km/h när alla gator har maxbegränsning på 100km/h. Då är det bättre att köpa en bil med snabbare acceleration. Och det är korkat att hävda att en 300km/h bil kör dig snabbare från A till B, än en 100km/h bil. Då är accelaationen viktigare. Samma med servercpuer - en hög IPC är inte viktig, då är RAM bandbredd viktigare.

Permalänk
Medlem

@MikaelSwahn: SPARC som är så bra att Oracle gav upp den förra året?

Benchmarks är tämligen ointressanta om de inte kan relateras till något man faktiskt gör på datorn. Således är t.ex. benchmarks i Cinebench i princip helt meningslösa för min del, annat än möjligtvis för att illustrera skillnader i beräkningskraft mellan olika CPUer. Det blir ju ändå närmast en ren kuriosa eftersom det inte är i närheten av vad jag gör med datorn.

Som tur är så utvecklas nya spel och mjukvaror såsom operativsystem för att dra nytta av ny hårdvara, så det är inte precis som att man som konsument behöver oroa sig för att programvaran inte är optimerad för att köras på den nya burken. Jag skulle tro att de flesta andra som köper en dator för privat bruk inte heller ligger sömnlösa över ”bortkastad prestanda”, utan man köper det man vill ha och har råd med.

En Covfefe Lake är dock fortfarande inte en uppklockad Conroe, för då hade de bl.a. haft samma IPC, vilket de bevisligen inte har. Ingen textvägg ändrar på det.

Permalänk
Skrivet av Sveklockarn:

@MikaelSwahn: SPARC som är så bra att Oracle gav upp den förra året?

SPARC har inte givits upp, den säljs än. SPARC har flera världsrekord, sist jag kollade (förra året) så var den typiskt 2-11x snabbare än den snabbaste x86 och snabbaste POWER9 cpun. SPARC servrar har dubblat prestandan varje generation, och när du gjort det i 6 generationer på 5 år, så får du världens snabbaste cpu. Vi pratar inte 3% snabbare, utan 100% snabbare. Varje gång. Då är det inte konstigt att SPARC är 11x snabbare än x86 på vissa arbetslaster (serverlaster).

Citat:

Benchmarks är tämligen ointressanta om de inte kan relateras till något man faktiskt gör på datorn. Således är t.ex. benchmarks i Cinebench i princip helt meningslösa för min del, annat än möjligtvis för att illustrera skillnader i beräkningskraft mellan olika CPUer. Det blir ju ändå närmast en ren kuriosa eftersom det inte är i närheten av vad jag gör med datorn.

Benchmarks är mer rättvisande än IPC som inte säger någonting egentligen.

Citat:

En Covfefe Lake är dock fortfarande inte en uppklockad Conroe, för då hade de bl.a. haft samma IPC, vilket de bevisligen inte har. Ingen textvägg ändrar på det.

Återigen, IPC säger inte så mycket. Om du hade haft kunskaper i datalogi så hade du vetat att vissa problem inte kan parallelliseras, och då spelar det ingen roll hur hög IPC en cpu har.

Hög IPC betyder inte att programkoden automatiskt skrivs om så den blir parallell, vissa typer av beräkningar är omöjliga att köra parallellt och då spelar det ingen roll hur hög IPC en cpu har. Om spel normalt har en IPC på 2, så spelar det ingen roll om en cpu har IPC på 6. Spelet kommer ändå inte bli snabbare än en IPC på 2.

Jag kan försöka förklara på ett annat sätt som du kanske förstår istället. Om ett spel har en enda tråd, så spelar det ingen roll om du använder en cpu med 32 kärnor eller en kärna - spelet blir inte snabbare för att du använder flera kärnor. Samma med IPC. En hög IPC innebär inte att programkoden skrivs om till att använda flera kärnor eller trådar eller nåt annat. Lär dig lite programmering så kanske du förstår parallellitet och hur svårt det är.

Permalänk
Medlem
Skrivet av MikaelSwahn:

Benchmarks är mer rättvisande än IPC som inte säger någonting egentligen.

När man jämför två arkitekturer som används i samma miljö så är IPC ett bättre mått än benchmarks för att se hur en CPU har utvecklats.

Skrivet av MikaelSwahn:

Hög IPC betyder inte att programkoden automatiskt skrivs om så den blir parallell, vissa typer av beräkningar är omöjliga att köra parallellt och då spelar det ingen roll hur hög IPC en cpu har. Om spel normalt har en IPC på 2, så spelar det ingen roll om en cpu har IPC på 6. Spelet kommer ändå inte bli snabbare än en IPC på 2.

Jag kan försöka förklara på ett annat sätt som du kanske förstår istället. Om ett spel har en enda tråd, så spelar det ingen roll om du använder en cpu med 32 kärnor eller en kärna - spelet blir inte snabbare för att du använder flera kärnor. Samma med IPC. En hög IPC innebär inte att programkoden skrivs om till att använda flera kärnor eller trådar eller nåt annat. Lär dig lite programmering så kanske du förstår parallellitet och hur svårt det är.

Du och jag har nog två helt olika synvinklar på det. Som jag skrev innan så behöver en konsument/privatperson inte fundera på hur mycket av CPU’ns beräkningskraft som ”ödslas bort” när man uppgraderar eftersom kostnadsskillnaden är några futtiga tusen mellan enklaste modellen och toppmodellen (under HEDT). Det klart att man i vissa situationer inte har nytta av all CPU-kapacitet, men jag känner ingen som resonerar så när de köper dator, utan när det är dags för nytt så köper man det snabbaste som finns att tillgå inom en viss budget. Vid en uppgradering får man ju dessutom nytt moderkort med nya styrkretsar och förbättrad I/O-kapacitet, som egentligen är viktigare än mycket annat.

T.o.m. min farsa som uteslutande kör Office/webbläsare insisterade på att han skulle ha en i7:a, vilket krävde en rejäl övertalning för att få honom att acceptera att han aldrig skulle märka skillnad mot en i3:a.

För någon som spelar så utvecklas dock spelen i hög takt mot att dra nytta av ny hårdvara, så där finns all anledning att säkra upp spelupplevelsen genom att köpa så snabba grejer man har råd med. Tiden springer snabbt ifrån gammal hårdvara i spelvärlden. En Conroe skulle antagligen inte få ut 60 FPS i Minecraft ens en gång, så det är skönt att man inte sitter med såna gamla museiföremål längre.

Permalänk
Datavetare
Skrivet av MikaelSwahn:

SPARC har inte givits upp, den säljs än. SPARC har flera världsrekord, sist jag kollade (förra året) så var den typiskt 2-11x snabbare än den snabbaste x86 och snabbaste POWER9 cpun. SPARC servrar har dubblat prestandan varje generation, och när du gjort det i 6 generationer på 5 år, så får du världens snabbaste cpu. Vi pratar inte 3% snabbare, utan 100% snabbare. Varje gång. Då är det inte konstigt att SPARC är 11x snabbare än x86 på vissa arbetslaster (serverlaster).

Märkligt att SPARC inte tar över världen då...

Jag menar, Cavium valsar in och skapar en Aarch64 (64-bitars ARM) krets som slår både AMD och Intel på fingrarna i hyfsat med HPC-laster. Det är modell som lanserades så sent som i våras men direkt plockades upp av Cray i deras top-of-the-line modell.

Även Microsoft kommer använda den CPU-modellen i Azure (Aarch64 stöds både i Windows server och numera även Windows 10 för desktop).

Varför väljer man inte SPARC? Kanske den CPUn blivit så snabb att det längre går att beskriva med ord, en form av offer för sin egen framgång då man inte längre kan göra PR för den

Men om nu (teoretisk maximal, mer om det nedan) IPC är totalt irrelevant för server, varför gick då Oracle från dual-issue (d.v.s. teoretisk IPC på två) i M7 till quad-issue (teoretisk maximal IPC på fyra) i M8?

Och om det överhuvudtaget funnits en relevant marknad för >8 sockets (vilket varit max för Intel sedan Westmere), varför gick Oracle från max 32 sockets med M6, till 16 till 16 med M7 och nu max 8 sockets med senaste M8?

Kanske ändå något som Intel gjort rätt när man plockat åt sig 99 % av servermarknaden (en andel som bara måste börja minska rätt snart, börjar komma upp vettiga alternativ)?

Skrivet av MikaelSwahn:

Benchmarks är mer rättvisande än IPC som inte säger någonting egentligen.

Återigen, IPC säger inte så mycket. Om du hade haft kunskaper i datalogi så hade du vetat att vissa problem inte kan parallelliseras, och då spelar det ingen roll hur hög IPC en cpu har.

Vilket är mest rättvisande: benchmarks eller att testa de program man faktiskt bryr sig om?
För väldigt många på SweC är det likhetstecken mellan spelprestanda och "prestanda". Så vitt jag sett pratar ingen här om teoretisk maximal IPC, man pratar om faktiskt applikation-prestanda (applikation ofta == spel, men inte alltid) vid en specifik CPU-frekvens som ett mått på IPC.

Det är ett helt relevant mått på IPC. Värdet är inte "IPC=1,97" utan det som normalt diskuteras är IPC i den specifika applikationen relativt någon annan CPU-modell. Fullt rimligt att göra en sådan jämförelse och det värde på "IPC" man får ut där är högst relevant.

Dock är det enda som i slutändan betyder något är faktiskt prestanda i applikationen. Med metoden ovan går det att skatta bara man vet frekvensen mätningen gjordes vid samt faktiskt frekvens. Man får i alla fall en övre gräns, andra saker som t.ex. GPU kan ju ta över som primär flaskhals.

Tar man teoretisk IPC är den inte ens konstant i en och samma CPU, beror på typ av arbetslast... Skylake kan maximalt utföra fem x86 per cykel om det finns absolut noll saker som hindar maximal IPC under ~40 cykler (storleken på ) och dessa instruktioner inte träffar micro-op cachen. Under kortare tid alt. om man träffar micro-op cachen är maximal IPC åtta (fast då handlar det om micro-ops, d.v.s interna instruktioner och är inte 1:1 mappning mellan x86 och micro-ops).

Zen är rätt snarlik, maximalt fyra x86 instruktioner under ~20 cykler, teoretiskt upp till tio interna instruktioner samma cykel (fast bara möjligt att "retire" åtta så i praktiken lär det vara omöjligt att nå över åtta, d.v.s. samma som Skylake).

Ingen verklig applikation är i närheten av detta, desktop-applikationer har normalt extremt hög cache-hit-rate och når IPC på ~2,0-2,5 på dessa CPUer.

Det är för skalära instruktioner... För t.ex. matrisberäkningar och signalbehandling där man använder SIMD når applikationer som t.ex. Matlab i praktiken en IPC på ~30(!) med AVX om man har riktigt stora matriser (sexton multiplikationer och sexton additioner per cykel, fast det är bara två x86 instruktioner av typen FMA...).

Skrivet av MikaelSwahn:

Hög IPC betyder inte att programkoden automatiskt skrivs om så den blir parallell, vissa typer av beräkningar är omöjliga att köra parallellt och då spelar det ingen roll hur hög IPC en cpu har. Om spel normalt har en IPC på 2, så spelar det ingen roll om en cpu har IPC på 6. Spelet kommer ändå inte bli snabbare än en IPC på 2.

Jag kan försöka förklara på ett annat sätt som du kanske förstår istället. Om ett spel har en enda tråd, så spelar det ingen roll om du använder en cpu med 32 kärnor eller en kärna - spelet blir inte snabbare för att du använder flera kärnor. Samma med IPC. En hög IPC innebär inte att programkoden skrivs om till att använda flera kärnor eller trådar eller nåt annat. Lär dig lite programmering så kanske du förstår parallellitet och hur svårt det är.

???

Grovt sett finns tre varianter av parallellism i en modern IPC

  • ILP: i praktiken är det enbart detta som avses i "IPC" diskussionerna, ILP (instruction level parallelism), är den form av parallellism som erhålls då moderna CPUer dynamisk analyserar instruktionsströmmen och plockar ut instruktioner som är sinsemellan oberoende och kör dessa samma cykel. Finns extremt lite en programmerare kan göra för att påverka ILP sedan CPUer fick "out-of-order" back-ends (alla Intel sedan PPro och alla AMD sedan K5)

  • data-parallellism: detta är vad SIMD och GPUer är superoptimerad för. Kan i någon mån idag automatiskt utföras av de bästa kompilatorerna, men kräver i praktiken att man explicit programmerare för det (något det innan C++17 inte fanns något standardiserat sätt utanför OpenCL och CUDA att göra). Som exemplet ovan visat, för rätt typ av applikationer (de med hög grad potentiell data-parallellism) kan man nå extrem IPC nivå med detta. Om det är något område som är grovt underutnyttjat idag är det detta, både SIMD (via t.ex. C++17) och GPGPU lär växa de kommande åren.

  • uppgiftsparallellism: detta är "multitrådning".

Sett nivå av finkornigheten som tillåts för att utnyttja dessa är det ILP > data-parallellism > uppgiftsparallellism.

ILP används hela tiden idag. Detta kommer använda ILP

f(x, y, z) = x^2 + y / z

då CPUn rätt enkelt ser att x^2 kan beräknas oberoende av y / z så detta kommer ske parallellt.

Data-parallellism kan också användas i rena matematiskt uttryck, är precis det man gör i matrisberäkningar. Men även detta kan använda data-parallellism

vector<T> aBunchOfTs = getABunchOfTs(); // flera fnToAppyToEachT() kan i C++17 anropas genom att nToApplyToEachT() // "vektoriseras" av kompilatorn genom att använda SSE/AVX/NEON instruktioner transform (begin(aBunchOfTs), end(aBunchOfTs), fnToApplyToEachT);

Även detta vektoriseras idag av clang och gcc

void foo(float *restrict r, const float *restrict a, const float *restrict b, size_t len) { for (size_t i = 0; i < len; i++) { r[i] = a[i] + b[i]; } }

då det är enkelt för kompilatorn att se att varje iteration är oberoende av alla andra iterationer.

I teorin är båda fallen ovan även möjliga att köra på flera CPU-kärnor, i praktiken blir det långsammare om man inte har tiotals miljoner element alt. gör extremt dyra beräkningar för varje element. Men är fullt möjligt att utnyttja dataparallellism redan vid något tiotals värden (men krävs lite mer för att se en praktiskt värde).

D.v.s. problemet med uppgiftsparallellism är att det bara ger något om man har relativt stora problem som sinsemellan är nära nog helt oberoende av varandra. Till skillnad från data-parallellism kan man göra helt olika saker i de parallella spåren, så mer generellt ur det perspektivet, men väsentligt högre kostnad för synkronisering.

Just kostnaden för synkronisering är vad som håller tillbaka detta på skrivbordet. Spel måste t.ex. få färdigt allt inom 10-15 millisekunder. Hantering av UI rent generellt ligger ju på ~10-20 millisekundersnivån så är väldigt svårt att effektivt nyttja många CPU-kärnor i interaktiva program.

Helt annorlunda på servers. Varje transaktion är normalt väldigt oberoende av alla andra transaktioner -> trivialt att använda många trådar. Rent tekniskt är dock detta inte ett parallellt program, det är många sekventiella/enkeltrådade program som körs parallellt. Låter som detaljer, men är en extremt viktig distinktion.

Att utveckla programvara för det senare fallet är relativt enkelt. Att skriva effektiva parallella program är nog det svåraste en programmerare kan ge sig på!

Vet inte riktigt vad allt detta har med att Intel skjuter fram sina laptop CPUer till 2019.

Inget jag hänger upp mig på personligen, gissar att min nästa laptop kommer köra ARM. Dels lär Apple gå över till sin egen ARM i MBP (enda CPU-designen så här långt som matchar och nog passerat Intels IPC, men inte IPC*frekvens). Dels har det läckt lite detaljer om att en Snapdragon 1000 som till skillnad från de ARM-baserade Win 10 laptops som släppts under våren där det sitter en mobil CPU är SN1000 designad specifikt för laptops. Viskas om prestanda motsvarande 2017 års Intel bärbara, fast med >20 timmars batteritid.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Skrivet av Sveklockarn:

När man jämför två arkitekturer som används i samma miljö så är IPC ett bättre mått än benchmarks för att se hur en CPU har utvecklats.
Du och jag har nog två helt olika synvinklar på det.

Eh, ja det har vi nog. Återigen, IPC är ett teoretiskt begrepp som inte säger mycket om hur bra cpun presterar i verkligheten. Då är benchmarks bättre för att se cpu prestanda. Om en cpu har IPC på 10 och presterar 20 FPS, och en annan har IPC på 3 men presterar 100 FPS, så väljer du den cpu med högst IPC? Det är lika smart som att välja den cpu med högst GHz - som inte heller säger något egentligen. Visst, du kanske väljer cpuer med högst IPC, eller högst GHz, eller snabbast L1 cache eller whatever - men bara för att en enda statistik utav alla 10000 som finns i cpu, ser bra ut på papperet så betyder det inte att hela cpun är snabb. Det är faktiskt dumt att tro att en cpu presterar bättre än en annan cpu, om en cpu har snabbare L1 cache, eller högre IPC eller GHz, whatever.

Du kanske borde omvärdera din världsbild och istället se till slutresultatet. Det viktiga är ju slutresultatet, inte ett temporärt resultat på vägen mot slutresultatet. Det alla andra här (förutom du) bryr sig om är många FPS de får ut. Det spelar ingen roll om en konstruktion använder en enda bra grej, eftersom man måste se till hela produkten, det är ju faktiskt en hel kedja. Det är ungefär som BTRFS - som använder... B-träd(?) och ZFS använder någon annan inte lika flexibel datastruktur. Så då är det dumt att välja BTRFS pga den använder en bättre datastruktur - eftersom BTRFS suger hårt och ZFS är stabilt och säkert. Men visst, du får fortsätta välja en konstruktion utifrån en enda liten siffra och strunta i alla andra siffror eller hur slutresultatet blev. I mina ögon är det inte begåvat att fokusera på ett mellanresultat. Vi har nog helt olika synvinklar, ja.

Permalänk
Medlem

@MikaelSwahn: Innan du försöker blanda bort korten så ska vi nog etablera att det var du som påstod att dagens Covfefe Lake-CPUer hade samma arkitektur som Conroe, det var där hela diskussionen startade.

Jag har försökt förklara varför det inte bara är fel, utan vore lika dumt som att döma ut Covfefe Lake för att x86 är från 70-talet. Alla fattar att det är iterationer av gammal teknik som utvecklas till nya snabbare grejer. Intel kommer inte sätta sig med ett vitt papper och göra en ny CPU från scratch utan att i så fall ha väldigt goda skäl till det.

Permalänk
Skrivet av Yoshman:

Märkligt att SPARC inte tar över världen då...

Så du tror att ifall en produkt inte tagit över världen så är den sämre? Windows har ju tagit över världen, så då betyder det att Windows är bättre designat än Linux? Eller hur?

Du har varit verksam inom IT länge, och resonerar så här? Nu råkar ju Linux ha väldigt dålig kodkvalitet och vara rejält bloatat och skala dåligt, men ändå.

Citat:

Jag menar, Cavium valsar in och skapar en Aarch64 (64-bitars ARM) krets som slår både AMD och Intel på fingrarna i hyfsat med HPC-laster.

Det är, som jag sagt tidigare många gånger till dig men jag kan dra det för dig återigen, skillnad på HPC (beräkningar) och business enterprise laster (databaser, SAP, ERP system, etc). HPC är enkelt att parallellisera och varje tråd kör sin lilla for loop ifred utan att behöva synka med andra trådar. Det är inte mycket synkronisering som sker, det som är viktigt är cpu cache för HPC. Business laster synkar hela tiden och det som är viktigt är RAM bandbredden. Detta vet du - eller, jag har förklarat detta för dig många gånger tidigare.

Så om en cpu är lämplig för HPC, så betyder det inte att cpun är bra för business laster. Och om man tittar på Caviums topologi så ser den riktigt dålig ut, typ som Token ring. Token ring var ett nätverk, där bara en dator i taget kunde prata och alla andra datorer i nätverket var tvungen att vänta på sin tur, så det var ineffektiv kommunikation. Se bild på Caviums kärnor:
https://images.anandtech.com/doci/12694/ThunderX2_ring.png
Här ser man att, alla kärnor inte är kopplade till varandra direkt. Om man ska gå från en kärna till en annan kärna långt bort, så får man gå från en kärna, till nästa kärna, till nästa kärna, etc i flera hopp. Detta är ineffektiv kommunikation. Och det skulle aldrig funka för business laster. Så det finns ett skäl till varför Cavium inte används utav stora databas servrar, SAP, etc. Så visst, Cavium presterar antagligen bra för enkelt parallelliserbara laster som HPC, men skulle suga på business laster.

Det är mycket du inte vet om stora business servrar. Du trodde ju t.ex. att Google använde stora 32-cpu scale up servrar och kände inte till att Google använder 100.000 tals små servrar i ett stort nätverk. Detta betyder att de kunskaper du har om desktops inte nödvändigtvis gäller för stora scale-up business servrar och det är alltså fel av dig att extrapolera. Du är alltså, kort sagt, ute och cyklar. Du vet inte, vilket bevisas av de felaktigheter du vräker ur dig.

Citat:

Varför väljer man inte SPARC? Kanske den CPUn blivit så snabb att det längre går att beskriva med ord, en form av offer för sin egen framgång då man inte längre kan göra PR för den

Jag har flera gånger visat dig benchmarks där SPARC var 2-11x snabbare än den snabbaste x86. Och ändå avvisade du benchmarksen därför att x86 har högre IPC så alltså är x86 en snabbare cpu - trots femtiotalet benchmarks som visade motsatsen där SPARC var 2-11x snabbare. Har du Aspbergers? Min kompis har det, och resonerar exakt som du. Han vägrar ge sig, trots att man visar hur många länkar och källor som helst. När han har bestämt sig, så funkar inga bevis alls. Helt omöjligt att resonera med. Om x86 har högre IPC än SPARC, så _måste_ x86 vara snabbare än SPARC - trots alla femtiotalet benchmarks som visar hur x86 blir totalt förödmjukad av SPARC. Klockrent Aspberger varning.

Citat:

Och om det överhuvudtaget funnits en relevant marknad för >8 sockets (vilket varit max för Intel sedan Westmere), varför gick Oracle från max 32 sockets med M6, till 16 till 16 med M7 och nu max 8 sockets med senaste M8?

Förrut fanns det en marknad för stora business servrar med 32 och även 64 sockets. Idag är dagens low end cpuer så pass bra att räcker ganska långt med 2 eller 4 cpuer - såna servrar hanterar stora laster idag. SPARC M6 skalade faktiskt till 96 cpuer, men det fanns ingen efterfrågan på såna enorma servrar. Detta betyder att low-end servrar är tillräckligt bra för att klara av det mesta idag. När det finns behov av stora servrar, som kräver rejält många cpuer, så är de få till antalet. Varför ska man utveckla stora 96-cpu servrar om marknaden är pytteliten? Idag är M8 med 8st cpuer tillräckligt bra för att motsvara en 16-socket M7. Och M7 var ju 2-11x snabbare än x86 förra året. Så man kommer långt med 8st M8 SPARC cpuer, M8 servrar kan hantera de största lasterna.

Citat:

Kanske ändå något som Intel gjort rätt när man plockat åt sig 99 % av servermarknaden (en andel som bara måste börja minska rätt snart, börjar komma upp vettiga alternativ)?

Försöker du säga att Intel måste ju ha de snabbaste cpuerna därför att de har 99% av low-end servermarknaden? Om du istället tittar på high-end servermarknaden så har Intel ungefärligen 0%. Alla SAP topp benchmarks tillhör SPARC. x86 kommer långt efter. Och eftersom Windows har 99% av hela IT marknaden, så är Windows bäst, eller hur? Menar du allvar?

Citat:

Så vitt jag sett pratar ingen här om teoretisk maximal IPC, man pratar om faktiskt applikation-prestanda (applikation ofta == spel, men inte alltid) vid en specifik CPU-frekvens som ett mått på IPC.

Va bra, då håller du med om att IPC inte säger så mycket om hur snabbt en cpu presterar i praktiken, eftersom vissa arbetslaster har en max IPC och då spelar det ingen roll att en cpu har tok-hög IPC. Va bra att vi är överens!

Så du har alltså ändrat dig från tidigare, då du envist hävdade att eftersom x86 har högre IPC än SPARC, så måste x86 vara snabbare - trots att jag visade benchmarks som bevisade motsatsen. Du sa i samma veva att eftersom SPARC även har ett sliding window för registren så kan inte SPARC vara snabbare än x86 eftersom sliding window är korkat. Nu råkar det vara så att detta korkade sliding window, gör SPARC ensamt(?) immun mot meltdown buggen. Så det kanske inte var så korkat ändå att slida och byta ut alla registren.

När man har Aspberger så är det lätt hänt att man hakar upp sig på detaljer och missar helheten. Om SPARC har någon detalj som är dålig, så betyder det inte att hela SPARC måste vara dålig. Jag har ju sagt att du måste titta på helheten. Hela kedjan måste hålla ihop. En bra eller dålig länk, gör inte hela kedjan.

Permalänk
Skrivet av Sveklockarn:

@MikaelSwahn: Innan du försöker blanda bort korten så ska vi nog etablera att det var du som påstod att dagens Covfefe Lake-CPUer hade samma arkitektur som Conroe, det var där hela diskussionen startade.

Jag försöker inte blanda bort korten. Dagens Intel cpuer är i stort sett samma gamla core duo som har rehashats lite grand. Och det är därför som Intel inte får mer än 3% prestanda förbättringar per år. Intels gamla arkitetkur har slagit i taket och måste göras om. Kom igen, Intel är inne på sin 8e generation! Och presterar 3% bättre varje år. Tror du att Intel INTE har slagit i taket??

Citat:

Jag har försökt förklara varför det inte bara är fel, utan vore lika dumt som att döma ut Covfefe Lake för att det x86 är från 70-talet. Alla fattar att det är iterationer av gammal teknik som utvecklas till nya snabbare grejer. Intel kommer inte sätta sig med ett vitt papper och göra en ny CPU från scratch utan att i så fall ha väldigt goda skäl till det.

Eh, du har kanske missat att Intel har samlat ihop folk för att designa en helt ny x86 arkitektur? Det var någon aritkel här på Swec om det. Även Intel håller med om att dagens arkitektur har slagit i taket. Annasr skulle de inte redisgna allt.

Permalänk

PS. Och om vi jämför Caviums usla topologi som skalar dåligt, mot en business server som SPARC, mot Intel, så ser vi också hur dåligt Intel skalar, pga deras dåliga topologi (kolla Intels nya 8-cpu topologi till höger):
https://www.servethehome.com/wp-content/uploads/2017/07/Intel...
Antag att man vill nå från cpun längst upp till vänster, ned till längst ned till höger. Då måste man gå via en cpu, dvs det blir ett hopp däremellan.

Jämför istället mot den gamla SPARC T5 cpun. Här är topologin för 8 cpuer, och alla är kopplade direkt till varandra:
https://regmedia.co.uk/2012/09/03/oracle_sparc_t5_coherency.j...
Det betyder att det går att nå alla cpuer direkt, utan att gå omvägen via andra cpuer. Alltså skalar SPARC bättre.

Här kan vi jämföra en 16-cpu x86 server mot SPARC. Det finns alltså ett skäl till varför x86 skalar dåligt; pga dålig topologi.
https://deinoscloud.files.wordpress.com/2012/10/bullions-bcs....
Att gå från den gula cpun till den röda cpun kräver 3 hopp! Det är uselt.

Titta på 32-cpu M6 SPARC servern. Att gå från vilken cpu till vilken som helst, tar maximalt två hopp.
https://2eof2j3oc7is20vt9q3g7tlo5xe-wpengine.netdna-ssl.com/w...

Och om vi tittar på 96-cpu SPARC M6 servern, så ser den ut så här:
https://images.techhive.com/images/idgnsImport/2013/08/id-204...

Vi ser alltså varför x86 skalar dåligt; det är ineffektiv kommunikation mellan cpuerna. SPARC (och antagligen POWER) har bättre topologi och skalar därför bättre.

Permalänk
Datavetare
Skrivet av MikaelSwahn:

Så du tror att ifall en produkt inte tagit över världen så är den sämre? Windows har ju tagit över världen, så då betyder det att Windows är bättre designat än Linux? Eller hur?

Du har varit verksam inom IT länge, och resonerar så här? Nu råkar ju Linux ha väldigt dålig kodkvalitet och vara rejält bloatat och skala dåligt, men ändå.

Det är, som jag sagt tidigare många gånger till dig men jag kan dra det för dig återigen, skillnad på HPC (beräkningar) och business enterprise laster (databaser, SAP, ERP system, etc). HPC är enkelt att parallellisera och varje tråd kör sin lilla for loop ifred utan att behöva synka med andra trådar. Det är inte mycket synkronisering som sker, det som är viktigt är cpu cache för HPC. Business laster synkar hela tiden och det som är viktigt är RAM bandbredden. Detta vet du - eller, jag har förklarat detta för dig många gånger tidigare.

Tja, en annan sak där ThunderX2 visat sig vara extremt konkurrenskraftig är just de lasterna där i alla fall tidigare SPARC-varianter stod sig väl om Intel. Enterprisefall med väldigt många samtida transaktion, fast där varje enskild transaktion inte gör något speciellt beräkningsmässigt tungt.

Att ThunderX2 råkar vara bra på många HPC laster handlar främst om att plattformen har väldigt hög bandbredd per CPU-socket och det finns relativt många HPC laster bandbredd är primär flaskhals. Om beräkningskraft är primär flaskhals är det bara Intel med AVX512 (numera både i Xeon och Xeon Phi), samt GPGPU som har något att komma med.

Skrivet av MikaelSwahn:

Så om en cpu är lämplig för HPC, så betyder det inte att cpun är bra för business laster. Och om man tittar på Caviums topologi så ser den riktigt dålig ut, typ som Token ring. Token ring var ett nätverk, där bara en dator i taget kunde prata och alla andra datorer i nätverket var tvungen att vänta på sin tur, så det var ineffektiv kommunikation. Se bild på Caviums kärnor:
https://images.anandtech.com/doci/12694/ThunderX2_ring.png
Här ser man att, alla kärnor inte är kopplade till varandra direkt. Om man ska gå från en kärna till en annan kärna långt bort, så får man gå från en kärna, till nästa kärna, till nästa kärna, etc i flera hopp. Detta är ineffektiv kommunikation. Och det skulle aldrig funka för business laster. Så det finns ett skäl till varför Cavium inte används utav stora databas servrar, SAP, etc. Så visst, Cavium presterar antagligen bra för enkelt parallelliserbara laster som HPC, men skulle suga på business laster.

Sist jag kollade var det 2018 och antalet datacenter blir bara fler. I datacenter kör man inte en relationsdatabas över femtielva CPU-socklar, faktum är att (till Oracles förtret) har folk till slut fattat att även om relationsdatabaser absolut har sina nischer användes de tidigare i långt fler fall än vad som var vettigt.

Mängden data som hanteras idag har sådan volym att det bara kan hanteras med metoder som relativt väl kan distribueras över många noder. Det betyder att datorkraften som kan dediceras till en specifik transaktion går i de flesta fall inte att skala speciellt mycket, men det är mindre viktigt när man koncentrerar kraften till enorma datacenter. Det som spelar roll då är hur många samtida transaktioner systemet hanterar, vilket är något både Intel, AMD och Cavium fokuserar på.

Av allt att döma lär SPARC M8 bli den sista SPARC som det kommer trätas om på forum.

"Tech industry observer Simon Phipps claims “~all” Solaris staff were laid off. His use of a tilde, and threads on anonymous message board The Layoff that mention small numbers of staff being retained, lead us to believe that a small Solaris team remains in place. Other comments mention hundreds of workers recently moved from dedicated Solaris teams to Oracle's Linux development efforts."

Vet inte exakt vad Fujitsu för mer på SPARC-sidan, men de är stora på HPC och där har man dumpat SPARC för Aarch64.

Skrivet av MikaelSwahn:

Det är mycket du inte vet om stora business servrar. Du trodde ju t.ex. att Google använde stora 32-cpu scale up servrar och kände inte till att Google använder 100.000 tals små servrar i ett stort nätverk. Detta betyder att de kunskaper du har om desktops inte nödvändigtvis gäller för stora scale-up business servrar och det är alltså fel av dig att extrapolera. Du är alltså, kort sagt, ute och cyklar. Du vet inte, vilket bevisas av de felaktigheter du vräker ur dig.

Vad jag har expertkunskap om (inklusive en rad patent) är teknik kring att utveckla parallella program samt utveckling av OS-kärnor för in byggda system.

Men hur ska jag någonsin kunnat ha hävdat att Google använder 32-CPUs "scale up" servers då jag är full medveten om att de fram till väldigt nyligen körde uteslutande med x86 där maxgränsen är 8 sockets/CPUer för Intel (är ju två för AMD, men var fler tidigare)? Google är, ihop med Nvidia, en av de mer aktiva medlemmarna i OpenPOWER, men så vitt jag vet har inte jättemycket icke-IBM-tillverkat kommit ut ur OpenPOWER ännu.

Du har inte blandat ihop koncepten här? Vad som är sant är att det finns x86 system, även hos Google, där man kör samma kernel-image över lågt mer än 8 CPU-sockets. Det är fullt möjligt m.h.a. Infiniband och sedan Skylake SP även möjligt m.h.a. Intels Omni Path Connect som finns på de modeller med ett "F" i namnet.

Skrivet av MikaelSwahn:

Jag har flera gånger visat dig benchmarks där SPARC var 2-11x snabbare än den snabbaste x86. Och ändå avvisade du benchmarksen därför att x86 har högre IPC så alltså är x86 en snabbare cpu - trots femtiotalet benchmarks som visade motsatsen där SPARC var 2-11x snabbare. Har du Aspbergers? Min kompis har det, och resonerar exakt som du. Han vägrar ge sig, trots att man visar hur många länkar och källor som helst. När han har bestämt sig, så funkar inga bevis alls. Helt omöjligt att resonera med. Om x86 har högre IPC än SPARC, så _måste_ x86 vara snabbare än SPARC - trots alla femtiotalet benchmarks som visar hur x86 blir totalt förödmjukad av SPARC. Klockrent Aspberger varning.

Avvisar inte de testerna. Hävdar bara att de är precis lika sanna som Nvidias VDs uttalanden om att deras GPUer får de snabbaste x86 CPUer att framstå som fickräknare. Det är helt sant, men bara för extremt specifika användarfall.

För det klar majoritet användarna på denna webbplats bryr sig om kan vare sig SPARC M8 eller Nvidias snabbaste GPU ersätta ens en laptopmodell av x86. Detta då saker vi kör på skrivbordet, d.v.s. sådan vi bryr oss om här, kan inte effektivt köras på mer än en handfull CPU-trådar.

Sett till prestanda per CPU-tråd är det fortfarande ingen som slår Intel på fingrarna. Men är själv övertygad om att det inte lägre handlar om någon Aarch64 tillverkare kommer ta över den ledartröja, utan bara när. Aarch64 är, tillsammans med RISC-V (som inte kommit speciellt långt än), de två bästa ISA som existerar just nu. Både x86 och SPARC har flera designmissar, båda använder t.ex. en onödigt strikt modell för minneskonsistens mellan CPU-kärnor (Total Store Order) vilket tar bort potentiella optimeringar för parallella program (vilket inte är vad man normalt kör på servers, där kör man typiskt många separata "program" parallellt där "program" är rätt löst, kan t.ex. vara en transaktion).

Att skriva parallella program är det finner intressant och det jag jobbat med under lång tid.

Skrivet av MikaelSwahn:

Förrut fanns det en marknad för stora business servrar med 32 och även 64 sockets. Idag är dagens low end cpuer så pass bra att räcker ganska långt med 2 eller 4 cpuer - såna servrar hanterar stora laster idag. SPARC M6 skalade faktiskt till 96 cpuer, men det fanns ingen efterfrågan på såna enorma servrar. Detta betyder att low-end servrar är tillräckligt bra för att klara av det mesta idag. När det finns behov av stora servrar, som kräver rejält många cpuer, så är de få till antalet. Varför ska man utveckla stora 96-cpu servrar om marknaden är pytteliten? Idag är M8 med 8st cpuer tillräckligt bra för att motsvara en 16-socket M7. Och M7 var ju 2-11x snabbare än x86 förra året. Så man kommer långt med 8st M8 SPARC cpuer, M8 servrar kan hantera de största lasterna.

Det är 2018, varje CPU har inte lägre 1-4 kärnor. De har långt fler kärnor än så (finns Aarch64 server-CPUer med upp till 48 kärnor, ThunderX2 har 32 kärnor och 128 trådar).

Finns nackdelar med många CPU-sockets, primärt hög latens mellan sockets och uppdelning av RAMi flera NUMA-noder. Därför finns allt mindre anledning för någon att bygga servers med väldigt många sockets (men finns fortfarande relevans inom vissa HPC-fall)

Skrivet av MikaelSwahn:

Försöker du säga att Intel måste ju ha de snabbaste cpuerna därför att de har 99% av low-end servermarknaden? Om du istället tittar på high-end servermarknaden så har Intel ungefärligen 0%. Alla SAP topp benchmarks tillhör SPARC. x86 kommer långt efter. Och eftersom Windows har 99% av hela IT marknaden, så är Windows bäst, eller hur? Menar du allvar?

Windows är inte i närheten av 99 % IT-marknaden. Till att börja med säljs det ungefär 10 ARM CPUer per såld x86, klart över hälften av dessa kommer köra någon variant av Linux.

Var ett par år sedan jag såg statistik för Azure, men Linux lär knappast har minskat under Nadella och det var ungefär 30 % Linux i Azure sist jag hörde något.

Är säkert så att alla topp SAP benchmarks tillhör SPARC. Men uppenbarligen står dessa för någon fraktion av den promille av servermarknaden som inte ockuperas av Intel (typ 99 %), AMD, Cavium (som ihop har det mesta av den kvarvarande 1 %), IBM (som säker har någon promille).

Skrivet av MikaelSwahn:

Va bra, då håller du med om att IPC inte säger så mycket om hur snabbt en cpu presterar i praktiken, eftersom vissa arbetslaster har en max IPC och då spelar det ingen roll att en cpu har tok-hög IPC. Va bra att vi är överens!

Exakt. Men för de laster vi bryr oss om här dominerar Intel och AMD, Apple och Qualcomm är närmast att blanda sig i den striden med sina respektive Aarch64 designer.

En sak håller jag inte med om. IPC är en egenskap på faktisk utfört jobb. Att säga att en cpu har tokhög IPC betyder att den faktiskt presterar tokbra. Peak-kapacitet i mikroarkitekturen != IPC, är fullt möjligt att mäta IPC i x86-instruktioner på i alla fall Intel (har inte testat på min AMD-dator och verktyget jag brukar använda är tillverkat av Intel och använder MSR, Model-Specific-Register, som precis som namnet antyder är specifika för en viss modell).

Skrivet av MikaelSwahn:

Så du har alltså ändrat dig från tidigare, då du envist hävdade att eftersom x86 har högre IPC än SPARC, så måste x86 vara snabbare - trots att jag visade benchmarks som bevisade motsatsen. Du sa i samma veva att eftersom SPARC även har ett sliding window för registren så kan inte SPARC vara snabbare än x86 eftersom sliding window är korkat. Nu råkar det vara så att detta korkade sliding window, gör SPARC ensamt(?) immun mot meltdown buggen. Så det kanske inte var så korkat ändå att slida och byta ut alla registren.

Nej, har aldrig hävdat att det inte finns nischer där SPARC är snabbare på. Men för det som spelar roll för skrivbordet och majoriteten av det som spelar roll i dagens datacenter är inte SPARC mycket att hänga i granen. Om den vore det skulle man ha mer än en omätbar andel av servermarknaden.

SPARC ISA är nästan ett lika stort vrak som x86, så jo det är fortfarande ett korkat beslut! Det är bara ett av flera orsaker varför SPARC snart är bara är ett minne blott.

Skrivet av MikaelSwahn:

När man har Aspberger så är det lätt hänt att man hakar upp sig på detaljer och missar helheten. Om SPARC har någon detalj som är dålig, så betyder det inte att hela SPARC måste vara dålig. Jag har ju sagt att du måste titta på helheten. Hela kedjan måste hålla ihop. En bra eller dålig länk, gör inte hela kedjan.

Aspergers finns sedan 2015 inte längre som diagnos, det heter numera ASD (Autism Spectrum Disorder)

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Datavetare

@MikaelSwahn: Kollade lite på vad Oracle listar för benchmarks för SPARC T8-1.

En av de första träffarna, ett "världsrekord"

SPECjbb2015: SPARC T8-1 World Record Single Chip Multi-JVM Result

Men hur är det med "scale-up" här? Tittar man i databasen för officiella resultat noterar man snabbt att resultatet i denna benchmark skalar i princip perfekt med ökande antal sockets. D.v.s detta är en typisk "scale-out" last. Varför skulle Oracle ens bemöda sig befatta sig med någon sådan oviktigt?

Men ändå, ett "världsrekord"! Så varför är folk så korkade att de köper x86-servers och inte T8-1 rack?

  • kanske för att ett T8-1 drar >1000 W medan Intel inte ens behöver mer än en 400 W PSU för deras Xeon Platinum 8180?

  • eller för att trots den till synes vansinniga prislappen på Xeon 8180 kostar bestyckat ett dual socket rack fortfarande mindre än ett T8-1 rack, drar mindre ström och i det läget presterar det även bättre i detta test

  • men om just detta fall är något man bryr sig om kanske man inte borde köpa Intel heller, detta då SPECjbb2015 är en av de saker där ThunderX2 presterar väldigt nära Xeon 8180 fast men en prislapp som är en fjärdedel

Jaja, men finns väl annat? Visst, finns en hel blog om detta.

Men vad är det man postar egentligen?

Apache Spark
Det behöver ju knappt multisocket-system med NUMA, skalar ju lysande även med kluster, så hur är SPARC T8 ens relevant då?[/li]

En orsak att SPARC T8 presterar väl i denna benchmark hänger ihop med att den har speciellt kisel för vissa väldigt vanliga operationer. Detta har egentligen inte något att göra med SPARC utan skulle kunna använda ihop med vilken CPU som helst. Har förstahandsinformation på att Microsoft accelererar vissa saker i Azure m.h.a. FPGA:er (som rent tekniskt sitter på PCIe).

I år kommer Xeons (Cascade Lake) med integrerad FPGA integrerade direkt i servern för just sådant. Skulle inte hävda att det på något sätt gör själva CPUn snabbare, men det gör självklart vissa specifika uppgifter snabbare (samt mer energieffektiva), DET är vad som räknas i slutändan.

Yahoo Cloud Serving Benchmark
Benchmarks för NoSQL, där en av huvudpoängerna är...att det går att skala lysande "horisontellt" då NoSQL nästan alltid betyder att man förlitar sig på BASE (Basically Available, Soft state, Eventual consistency) och inte ACID (Atomicity, Consistency, Isolation, Durability). Så vad är poängen med SPARC T8 där?

Självklart testar man bl.a. med krypterat filsystem mot en E5 2699v4 utan QuickAssist accelerator, något som kräver instickskort för <$1000 på Broadwell men är integrerat i alla utom det billigast chipset för Skylake SP. QuickAssist har stöd i de vanligaste kryptobiblioteken på Windows och Linux, så ingen extrakostnad tillkommer där.

Du hittade uppenbarligen en låg rad "bevis" för illa stället det är med x86 och Aarch64 lägret. Well, det enda som räknas i slutändan (något Larry Ellison vet bättre än de flesta) är om kunderna är nöjda med sina val och fortsätter ge dig pengar.

Behövs nog inte superdator för att hålla reda på totala omsättningen SPARC genererar numera.

Du skriver att "därför skalar x86 dåligt". Men i de flesta benchmarks som Oracle själva verka lista handlar det primärt om "scale out" och i det läget är i princip alla dina argument void. Finns självklart en viss nivå man måste kunna hålla för att hantera varje enskild transaktion, det var svettigt för CPUer för 15-20 år sedan men det är snart något mobilerna i de flesta fall fixar (ok, överdrift men high-desktop fixar de flesta fall).

Stora feta servers är idag lika relevant som big-block V8 från det stora landet i väster. Inget direkt ont om dessa, de är spännande historisk och har själv växt om med en farsa som är lika intresserade av 50-60 jänkare som jag är av datorer. Vår bruksbil var länge en Mustang HT 71:a med 5L V8, d.v.s. "lilla" V8:an.

Utvecklingen har dock gått vidare, bilbranschen går mot elbilar och datorvärlden har sedan länge marscherat in i datacenter eran. I datacenter gäller det att kunna hantera så många samtida transaktioner per rack, per Watt och per $. Det har uppenbarligen inte visa tillverkare insett och därför står man idag med irrelevanta designer.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer