Playstation 5 kan bli en dyr historia

Permalänk
Datavetare
Skrivet av snajk:

Jag är verkligen ingen expert, men är det inte lite fel att jämföra CISC (x86) instruktioner mot RISC (ARM) instruktioner? IPC, instruktioner per cykel, borde inte vara ett så bra mått om instruktionerna inte är likvärdiga liksom?

Annars har ju ARM för- och nackdelar precis som övriga alternativ. En nackdel är väl att Qualcomm i princip har monopol på det som är tillgängligt på marknaden, Apple bygger bra ARM-SoC men de säljer inte dem, nVidia verkar inte lägga så mycket krut på sina chip och AMD har väl mer eller mindre dragit sig ur den marknaden också. Kvar är ju Mediatek, som ju är helt ok på mobilsidan, men jag vet inte om de har kompetensen att konkurrera med QC. Å andra sidan kan ju vem som helst tillverka ARM-SoC om de bara betalar licensavgifterna, men det är förstås en stor investering oavsett.

"IPC" är inte bokstavligen "instruktioner per cykel" då det precis som du påpekar är svårt att jämföra rakt av mellan två olika instruktionsuppsättningar. IPC är här: hur står sig relativ prestanda om båda körs samma program, kompilerad för respektive CPU, på samma frekvens och lika många kärnor. I det läget är Cortex A76 väldigt jämn med Zen2/Skylake i heltal medan Cortex A77 är ~25 % snabbare i heltal och ~15 % i flyttal. Så ~20 % i genomsnitt i benchmarks som SPEC och GB, vilket egentligen är en underskattning då heltalsprestanda är långt mer relevant i praktiken (det gäller även spel).

Inte ens Ice Lake (Sunny Cove) når Cortex A77 i heltal, Sunny Cove har också ~20 % högre IPC mot Skylake i SPEC och GB, men där är det lite större fördel i flyttal och lite mindre i heltal.

Vidare, de gamla sanningarna om CISC och RISC stämmer inte längre, de om att RISC ger större program fast potentiellt högre frekvenser. "Ingen" skriver längre program i assembler, CISC hade en fördel när det var sant då de mer avancerade instruktionerna är lättare för människor att jobba med. I x86_64 har man nu så många specialfall att genomsnittslängden på instruktionerna är i nivå med de 4 bytes som alla Aarch64 instruktioner är (testade mätta genomsnittlig instruktionslängd på ett par program på min x86_64 laptop, genomsnittslängd blev 3,99 och så finns program där resultatet blev >4,0).

Idag skrivs programmen i språk som kompileras till maskinkod och Aarch64 (samt även RISC-V) har en instruktionsuppsättning som specifikt är optimerad för kompilatorutvecklare. Så här hittar men en del (men långt i från allt) av förklaringen till den höga "IPCn" hos 64-bitars ARM (notera att till skillnad mot x86 är 64-bitars ARM en helt separat ISA från 32-bitars ARM, 32-bitars ARM har inte alls samma fördelar över x86).

Kort och gott: x86_64 har i dag egentligen bara nackdelarna från CISC kvar. Den traditionella "RISC:en" finns egentligen inte längre. Moderna "RISC:ar" som Aarch64 och RISC-V har faktiskt en hel del "komplexa" instruktioner. "komplexa" är relativt här, majoriteten av de komplexa x86 instruktionerna kommer aldrig användas av en modern kompilator men "RISC" har idag mul/div och ARM har rätt "komplexa" instruktioner för minnesoperationer för att vara en "RISC", detta då kompilatorer har nytta av sådant.

Enda relevanta distinktionen idag är om instruktionerna har en fast längd (något som förenklar avkodning enormt) samt om aritmetiska operationer kan enbart utföras mot register (gäller i princip alla "RISC") eller mot RAM (typiskt för "CISC"). Så en bättre klassificering är om ISA är en "load/store design" eller ej. x86 är det inte, medan ARM är det (så även MIPS, PowerPC och RISC-V).

Bara för att förstå hur stor fördelen är i area är när man slipper x86-oket: en Zen2 kärna (inklusive lokal cache, d.v.s. L1$/L2$) är ~3,,67 mm². En Cortex A76 kärna med 512 kB L2$ och faktiskt mer L1I$, 64 kB mot Zen2 32 kB tar ~1,22 mm² på samma TSMC process, d.v.s. 1/3 yta för samma IPC!

Cortex A77 tar ~1,43 mm² på TSMC 7 nm, så 2/5 yta för ~20 % högre IPC.

Så det hade varit möjligt att få billigare tillverkning (mindre kretsyta), gett högre prestanda och dragit mindre ström om man valt en design från 2010 i stället för något med sina rötter i 1970-talet... Inser fördelarna med x86 på Windows, men i konsoler är det bara sorgligt att hålla fast vid stenåldersdesign

TL;DR på det hela då inlägget jag svarade på påstod att ingen förutom AMD har tekniken att bygga en konsol. Det stämmer inte, Nvidia har också tekniken, de har tekniken att bygga än bättre presterande krets till och med. Och det många nog missar är att det nog är på CPU-delen där Nvidia, p.g.a. att de inte kan välja x86, skulle ge störts fördel givet den teknik som finns på marknaden just nu.

Men nog sannolikt att Nvidia inte ens försökte utmana AMD om Sony/Micorsoft-konsolerna. Det är i.o.f.s. stora volymer, men bara titta på AMDs resultat när de primärt förlitade sig på intäkter från konsoler: det är brutalt långa marginaler. Att ta fram en konsolkrets är inte gratis ur FoU syfte, framförallt inte om det betyder att andra (potentiellt långt mer lönsamma saker) får stå tillbaka lite.

För AMDs del är det, ur icke-tekniska perspektiv, helt förståeligt att man väljer sin egen Zen2 design över ARM Cortex A77!

Visa signatur

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

Permalänk
Avstängd
Skrivet av Yoshman:

"IPC" är inte bokstavligen "instruktioner per cykel" då det precis som du påpekar är svårt att jämföra rakt av mellan två olika instruktionsuppsättningar. IPC är här: hur står sig relativ prestanda om båda körs samma frekvens, kompilerad för respektive CPU, på samma frekvens. I det läget är Cortex A76 väldigt jämn med Zen2/Skylake i heltal medan Cortex A77 är ~25 % snabbare i heltal och ~15 % i flyttal. Så ~20 % i genomsnitt i benchmarks som SPEC och GB, vilket egentligen är en underskattning då heltalsprestanda är långt mer relevant i praktiken (det gäller även spel).

Inte ens Ice Lake (Sunny Cove) når Cortex A77 i heltal, Sunny Cove har också ~20 % högre IPC mot Skylake i SPEC och GB, men där är det lite större fördel i flyttal och lite mindre i heltal.

Vidare, de gamla sanningarna om CISC och RISC stämmer inte längre, de om att RISC ger större program fast potentiellt högre frekvenser. "Ingen" skriver längre program i assembler, CISC hade en fördel när det var sant då de mer avancerade instruktionerna är lättare för människor att jobba med. I x86_64 har man nu så många specialfall att genomsnittslängden på instruktionerna är i nivå med de 4 bytes som alla Aarch64 instruktioner är (testade mätta genomsnittlig instruktionslängd på ett par program på min x86_64 laptop, genomsnittslängd blev 3,99 och så finns program där resultatet blev >4,0).

Idag skrivs programmen i språk som kompileras till maskinkod och Aarch64 (samt även RISC-V) har en instruktionsuppsättning som specifikt är optimerad för kompilatorutvecklare. Så här hittar men en del (men långt i från allt) av förklaringen till den höga "IPCn" hos 64-bitars ARM (notera att till skillnad mot x86 är 64-bitars ARM en helt separat ISA från 32-bitars ARM, 32-bitars ARM har inte alls samma fördelar över x86).

Kort och gott: x86_64 har i dag egentligen bara nackdelarna från CISC kvar. Den traditionella "RISC:en" finns egentligen inte längre. Moderna "RISC:ar" som Aarch64 och RISC-V har faktiskt en hel del "komplexa" instruktioner. Enda relevanta distinktionen idag är om instruktionerna har en fast längd (något som förenklar avkodning enormt) samt om aritmetiska operationer kan enbart utföras mot register (gäller i princip alla "RISC") eller mot RAM (typiskt för "CISC").

Bara för att förstå hur stor fördelen är i area är när man slipper x86-oket: en Zen2 kärna (inklusive lokal cache, d.v.s. L1$/L2$) är ~3,,67 mm². En Cortex A76 kärna med 512 kB L2$ och faktiskt mer L1I$, 64 kB mot Zen2 32 kB tar ~1,22 mm² på samma TSMC process, d.v.s. 1/3 yta för samma IPC!

Cortex A77 tar ~1,43 mm² på TSMC 7 nm, så 2/5 yta för ~20 % högre IPC.

Så det hade varit möjligt att få billigare tillverkning (mindre kretsyta), gett högre prestanda och dragit mindre ström om man valt en design från 2010 i stället för något med sina rötter i 1970-talet... Inser fördelarna med x86 på Windows, men i konsoler är det bara sorgligt att hålla fast vid stenåldersdesign

TL;DR på det hela då inlägget jag svarade på påstod att ingen förutom AMD har tekniken att bygga en konsol. Det stämmer inte, Nvidia har också tekniken, de har tekniken att bygga än bättre presterande krets till och med. Och det många nog missar är att det nog är på CPU-delen där Nvidia, p.g.a. att de inte kan välja x86, skulle ge störts fördel givet den teknik som finns på marknaden just nu.

Men nog sannolikt att Nvidia inte ens försökte utmana AMD om Sony/Micorsoft-konsolerna. Det är i.o.f.s. stora volymer, men bara titta på AMDs resultat när de primärt förlitade sig på intäkter från konsoler: det är brutalt långa marginaler. Att ta fram en konsolkrets är inte gratis ur FoU syfte, framförallt inte om det betyder att andra (potentiellt långt mer lönsamma saker) får stå tillbaka lite.

För AMDs del är det, ur icke-tekniska perspektiv, helt förståeligt att man väljer sin egen Zen2 design över ARM Cortex A77!

Jo det låter förstås helt rätt, men samtidigt är ju inte ARM bättre i de applikationer man använder dem, mer än på strömförbrukning förstås. Switch är ju ett typexempel där prestandan inte är i närheten av PS4/XBone trots att den är mycket nyare. Å andra sidan har man kanske fokuserat mer på strömförbrukningen där, och som sagt så är ju inte Tegra direkt ny idag. Men ändå är det ju en plattform som bara har ARM, det finns ingen konstig overhead för att översätta instruktioner som i Windows for ARM eller liknande. Så varför är den så klen om nu ARM är förbi x86/x64 i prestanda?

Permalänk
Datavetare
Skrivet av snajk:

Jo det låter förstås helt rätt, men samtidigt är ju inte ARM bättre i de applikationer man använder dem, mer än på strömförbrukning förstås. Switch är ju ett typexempel där prestandan inte är i närheten av PS4/XBone trots att den är mycket nyare. Å andra sidan har man kanske fokuserat mer på strömförbrukningen där, och som sagt så är ju inte Tegra direkt ny idag. Men ändå är det ju en plattform som bara har ARM, det finns ingen konstig overhead för att översätta instruktioner som i Windows for ARM eller liknande. Så varför är den så klen om nu ARM är förbi x86/x64 i prestanda?

Switch är utrustad med Cortex A57 (och A53 för bakgrundsjobb). Cortex A57 kan ses som en förfinad variant av Jaguar, ställd mot den CPUn kan man även här se hur brutalt mycket effektivare Aarch64 är ställd mot x86_64 sett till perf/W och perf/transistor.

Fram till Cortex A75 gick det rätt mycket att vifta bort ARM som: de kan inte konkurrera mot "big-core" x86. Det var sant då man helt enkelt inte ens försökte ta sig in på de marknaderna. Sett till teoretisk kapacitet presterade ARM bra redan då, problemet var att teoretisk kapacitet låg inte alls i nivå med Zen/Core.

Den serie av ARM CPUer som inleddes av Cortex A76 är starten på fokus av nya marknader, man siktar numera in sig på bärbara datorer och servers (dess två segment har väldigt mycket gemensamt). Detta jobb påbörjades redan 2013, så Microsoft och Sony borde rimligen ha känt till det sedan länge.

Cortex A76 är på flera sätt rätt lik Zen/Zen2 sett till bredd och teoretisk kapacitet, det visade sig även i praktiken. Cortex A77 är på flera punkter en "bredare" design är "big-core" x86, något som även det syns i praktiken. Apples A12 är en brutalbred design (och gigantisk sett till area för att vara ARM, den är i nivå med Zen2), men den ligger också 70-80 % högre i IPC!!!

Var det jag skrev tidigare: förstår helt valet inför PS4/XBO, när dessa lanserades fanns helt enkelt inget vettigt alternativ alls för CPU till konsoler. Jaguar var det bästa val man kunde göra i det läget (eller minst dåliga egentliga, för de var för klent redan från start).

Inför denna generation fanns alternativ. Zen2 kommer göra denna generation långt trevligare än förra. Men känns rätt trist att man inte kunde välja det tekniskt bästa alternativet, framförallt när det är tekniskt bättre på i princip varje punkt (åter igen, förstår det affärsmässiga beslutet från AMD och har ingen invändning mot det).

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:

Var det jag skrev tidigare: förstår helt valet inför PS4/XBO, när dessa lanserades fanns helt enkelt inget vettigt alternativ alls för CPU till konsoler. Jaguar var det bästa val man kunde göra i det läget (eller minst dåliga egentliga, för de var för klent redan från start).

Varför hade det vart sämre att använt piledriver likt Richland? 3(6)kärnor Piledriver på 35W (3Ghz turbo?) måste ju vara snabbare än det som hamnade i konsollerna?

Permalänk
Datavetare
Skrivet av sKRUVARN:

Varför hade det vart sämre att använt piledriver likt Richland? 3(6)kärnor Piledriver på 35W (3Ghz turbo?) måste ju vara snabbare än det som hamnade i konsollerna?

35 W tror jag var/är alldeles för mycket för CPU-delen, svårt annars att se varför Sony valde så låg frekvens som 1,6 GHz initial medan Microsoft (som hade klenare GPU och därmed kunde lägga mer strömbudget på CPU-delen) valde så låg frekvens som 1,75 GHz. Fanns redan vid lanseringen av konsolerna 4-kärniga Jaguar-system på 25 W som klockade >2,0 GHz och man borde insett direkt vilken gigantisk flaskhals CPU skulle bli.

Om ryktet 3,2 GHz för Zen2 i PS5 stämmer pekar det ju också på att strömbudget för CPU är kraftigt begränsad. Vilket gör valet att inte köra Cortex A77 än mer trist, vid <2 W per kärna vid 3,1 GHz kunde man t.ex. slänga in 4 st A55 kärnor (dessa är ~0,36 mm² på TSMC 7nm) för att driva OS/dashboard så spelen verkligen får 8C, för några CPU-trådar kommer dediceras till OS/systemet precis som tidigare.

Sedan kanske så att du överskattar IPC Piledriver alt. underskattar den i Jaguar. Jaguar hade, givet marknaden den riktades mot, faktiskt riktigt bra IPC. Jämför man t.ex. FX-4300 (3,8 GHz base / 4,0 boost, 2C/4T) mot Athlon 7350 (2,2 GHz base/boost, 4C/4T) har Jaguar inom felmarginalen samma IPC i enkeltrådprestanda (har gjort kontrollskott mot GB4 och GB5, men som jag kommer ihåg det stämmer det rätt väl rent generellt) och Jaguar har i fall när man matchar antal trådar ~10-15 % högre IPC.

Ovanpå det skulle man tappa två trådar (en modul) för OS/system, ingen bra idé att dela en fysisk kärna mellan spel och OS/system. Både Sony och Microsoft valde ju senare att endast reservera en Jaguar-kärna för systemet så spel kunde använda 7C, det hade inte varit lika självklart drag med en SMT CPU som Piledriver.

Problemet med Jaguar i en konsol laserad 2013 var egentligen för låg frekvens givet dess IPC. Hade man kunna köra 2,5-3 GHz hade det varit en riktigt bra generation (XBX nådde ju till slut 2,3 GHz vilket i vissa spel hjälper rejält). Initialt var två CPU-kärnor reserverade för OS/system, 6C/6T för spel var inte helt okänt redan 2013 då en bra spel-PC redan då hade 4C/8T (även om det i praktiken fungerade lika bra med 4C/4T i det läget).

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:

35 W tror jag var/är alldeles för mycket för CPU-delen, svårt annars att se varför Sony valde så låg frekvens som 1,6 GHz initial medan Microsoft (som hade klenare GPU och därmed kunde lägga mer strömbudget på CPU-delen) valde så låg frekvens som 1,75 GHz. Fanns redan vid lanseringen av konsolerna 4-kärniga Jaguar-system på 25 W som klockade >2,0 GHz och man borde insett direkt vilken gigantisk flaskhals CPU skulle bli.

Jo, visst är det så att nuvarande CPU-del ligger under 35W, men det mostätter ju inte att det hade kunnat vart rimligt att lagt mer krut där!

Absolut kanske jag överskattar piledriver här, just därför jag frågade . Men kan det också vara så att jaguar designen inte gillar frekvenser över 2Ghz? Inte mycket produkter släppta med höga frekvenser, för om jaguar nu har högre IPC och är relativt effektiv, varför skalade dom inte upp den till latop-segmentet, utan fortsatte med Piledriver där? Så om det nu är så att det inte var vettigt att trycka upp frekvenserna med jaguar, hade man inte kunnat använda piledriver med en högre strömbudget för ett bättre resultat? Det hade såklart ökat kostnaderna, vilket antagligen är vart skon klämde, men hade det verkligen tekniskt vart ett så mycket sämre val?

Permalänk
Medlem
Skrivet av Nioreh83:

PS4 kostade 400 dollar vid launch. Runt 4000kr i Sverige tror jag det blev på den tiden.

Skickades från m.sweclockers.com

Skrivet av Xinpei:

Njae. Snarare 4300 - 4500 beroende på butik.

Jag blev lite nyfiken så kollade upp vad jag faktiskt betalade för min PS4 som jag fick från Komplett samma dag som konsolen släpptes och jag betalade 3890kr inkl moms för mitt exemplar plus 39kr i frakt enligt min orderhistorik på komplett.se. Men det är ju möjligt att den var lite dyrare i fysiska butiker än på nätet.

Jag förhandsbokade även min konsol i juni 2013 (dvs ca 5 månader innan produkten släpptes) så det finns ju även en chans att priset ändrades mellan juni och själva släppet i november.

Permalänk
Medlem

@Yoshman, tack för informationen och förklaringarna. Det är just dessa saker jag ville förstå.

Det blir oavsett arkitektur spännande att se vad dessa nya konsoler kommer göra för spelutvecklingen, de senaste åren har den nuvarande generationen satt ramarna för det som är tekniskt möjligt.

Skickades från m.sweclockers.com

Permalänk
Medlem

Jag gav 4490kr för min PS4 vid release ifrån cdon :/

skrev fel pris..
Visa signatur

I5 9600k@stock / Cooler Master Evo 212 / Gigabyte Z390 Gaming X / Corsair Vengeance LPX 16GB DDR4 3000MHz / MSI RTX2070 Gaming Z / EVGA 550 BQ / Asus VG27BQ 27" 165Hz

Ryzen 5 5600x@stock / Asus Rog Strix X570-E Gaming / Corsair Vengeance RGB Pro 16GB 3600MHz CL18 / MSI RTX3070 Suprim X / BeQuiet Pure Power 11 600W / Asus VG278Q 27" 144Hz

Permalänk
Medlem
Skrivet av Esseboy:

Play station brukar ju vara lockelse produkter, dvs dom säljer dom billigt för att locka kunder, sen snor dom dina stålar med kringutrustningen. Därför brukar de flesta butiker gå back på att sälja dom.

Det är möjligt att butiker väljer att sälja till underpris, men riktpriset kan inte ligga en tusenlapp eller mer under grossistpris.

För att komma ner i angivet riktpris får Sony (inledningsvis) inte debitera mer än halva tillverkningskostnaden i första ledet, och sedan hoppas på att sälja så mycket att tillverkningskostnaden relativt snabbt sjunker under försäljningspriset.

Permalänk
Medlem
Skrivet av Mordekai:

Seriöst är det ju värt det om du skaffar en till dig själv också kan ni lira igenom hela Halo MCC 4-player co-op.

Det är det nya, skaffa inte ungar till ett fotbollslag men till ett e-sport-team.

Haha 💪🏻👍🏻

Skickades från m.sweclockers.com

Permalänk
Medlem

10-15 lax för ett grafikkort, inga konstigheter!
6000 för en hel konsol inklusive ett OS som supportas i 5-10 år -> dyrt...

Hmmm.

Min våta dröm vore en PCMR speccad konsol, hade lätt pröjsat 15k.

Permalänk
Medlem
Skrivet av Dredd:

3 ungar med varsin Xbox och varsin TV? Nya tider minsan.

Tänker lite samma sak. Sen undrar folk varför ungar är bortskämda och inte har koll på någon ekonomi. (Nu vet jag förstås ingenting om denna användares ungar utan jag tänker rent generellt).

”Det var bättre förr”

Skrivet av BasseBaba:

10-15 lax för ett grafikkort, inga konstigheter!
6000 för en hel konsol inklusive ett OS som supportas i 5-10 år -> dyrt...

Hmmm.

Min våta dröm vore en PCMR speccad konsol, hade lätt pröjsat 15k.

Jag skulle tro att den del av befolkningen som köper grafikkort för över tio tusen inte är samma del av befolkningen som klagar på att en konsol kostar fem tusen.