Permalänk
Medlem

Apple Silicon vs x86

Är ju poppis och det verkar finnas en konsensus (på Swec) kring att ARM64 är överlägset. Är det alltid per watt man menar då?

Hittade dessa benchmarks på en sajt som drivs av en Applefanboy ultra. Snabbaste Apple Silicon benchmark var 15% långsammare än motsvarande x86.

Fusion 360 är det mest välrenommerade CAD-programmet som finns native på både windows och MacOS med respektive ISA.
https://portlandcnc.com/blog/2023/7/apple-silicon-f360#result...

Missar jag något eller är det fortfarande Intel som är kungen av mekanisk CAD? Titta inte på renderingsdelen, den är missvisande enligt benchmarkets skapare.

Många påstår ju att man kan se x86 dö ut inom en inte alltför avlägsen framtid, det kanske stämmer men jag vet inte hur alla ingenjörer som ritar mekanisk CAD skall gå med på det nedköpet.

För liten förklaring, normalt sett kräver inte mekanisk CAD särskilt mycket men vissa specialfunktioner kräver väldigt mycket geometriska beräkningar, exempelvis shell på en komplex solid. Dvs man säger att soliden skall gröpas ur och kvar skall endast finnas ett ytterskal, exempelvis om du behöver kapsla in exempelvis elektronik i en annan del. Man kan också göra utvändig shell och då blir det mer som exempelvis ett mobilskal. Detta är det enklaste exemplet jag kan komma på där det verkligen kan ta tid för beräkningarna eftersom de inte kan parallelliseras, Fusion 360 och Solidworks har en massa smarta funktioner som på liknande sätt måste räkna ut seriellt över ett helt objekt.

#VADHARJAGMISSAT?

Ingen skulle bli gladare än jag om man kunde motivera en Mac för mekanisk CAD/CAM. Batteridrift är inte en bonus, snarare tvärtom eftersom det är den delen i datorn som idag slits snabbast. Jag har svårt att tro att detta skulle vara det enda scenario där Apple-Silicon-optimerad mjukvara är underlägset X86. Trist med monolitiska trender generellt, först var det klockfrekvens, sedan kärnor, sedan logiska kärnor/trådar och nu prestanda per watt. Alla är bra på sitt sätt men när branschen rör sig helt parallellt pga ett enda benchmark så gråter jag lite. Personligen vill jag ha det bästa av alla världar (förutom parallellisering vilket gör sig bättre på GPU). X antal (säg fyra) vrålsnabba kärnor helt symmetrisk layout av all IO internt och fett med extern IO som inte äter CPU-cykler. Om jag behöver mer parallellt skeppar jag det till en server helst.

stavning
Permalänk
Datavetare

Tycker detta är ännu ett exempel på hur pass bra Geekbench 6 ändå är på att svara på frågan "hur snabb är denna CPU".

Varför? Jo, kolla deltesterna. Är viss varians även mellan Intel och AMD, men den är typiskt inom ±10 % i deltester på två CPU-modeller med ungefär samma totalpoäng. Skillnader under ~20 % lär i de absolut flesta fall vara irrelevanta.

Variansen mellan t.ex. Intel och Apple där totalpoängen är den samma är i deltesterna ±35 %. Så vad som är "bäst" kräver mer kontext.

Skrivet av Mordekai:

Är ju poppis och det verkar finnas en konsensus (på Swec) kring att ARM64 är överlägset. Är det alltid per watt man menar då?

Vet inte var du hittar någon konsensus, skulle hävda att det är långt ifrån någon konsensus på denna punk.

Vad man i.o.f.s. rätt objektivt kan säga är att just perf/W och även perf/cykel är långt bättre på high-end ARM64. Den senare är så pass mycket bättre (och inte bara på "Apple Silicon" utan även på Arm Cortex X4/X925 och Qualcomm Oryon) att det även leder till högre absolut prestanda i de flesta fall, men inte alla trots ~6 GHz peakfrekvens för x86 mot ~4 GHz peakfrekvens för dagens ARM64.

Sen finns inget som fysiskt hindrar att bygga en ARM64 som når 6 GHz. Den kommer ha väsentligt sämre perf/W mot dagens ARM64, men skulle få högre absolut prestanda. Det är ett visst motsatsförhållande mellan perf/cykel och en design som klockar väldigt högt, men det kan inte alls förklara skillnaden i perf/cykel mellan t.ex. M3/Oryon och Zen4/Raptor Cove (de förra har 40-50 % bättre perf/cykel).

Det jag gissar många inte riktigt har koll på är just att i många fall är idag en ARM64 CPU-modeller den som är snabbast i absolut termer. Det känns liksom orimligt att 15-30 W modeller (beroende på vad man tar med är den snabbaste ARM64 M4 i Ipad eller M3 Max om bara datorer räknas) kan, i absoluta termer, vara snabbare än Intel/AMDs desktop-monster som dra 200-300 W.

Skrivet av Mordekai:

Hittade dessa benchmarks på en sajt som drivs av en Applefanboy ultra. Snabbaste Apple Silicon benchmark var 15% långsammare än motsvarande x86.

Fusion 360 är det mest välrenommerade CAD-programmet som finns native på både windows och MacOS med respektive ISA.
https://portlandcnc.com/blog/2023/7/apple-silicon-f360#result...

Missar jag något eller är det fortfarande Intel som är kungen av mekanisk CAD? Titta inte på renderingsdelen, den är missvisande enligt benchmarkets skapare.

Ser väl rätt väntat ut, eller?

När man ställer ARM64 mot x86_64 skiljer det rätt mycket i relativ prestanda beroende på vad man testar. Tar vi GB6 som testar ett 20-tal olika fall är det just de som primärt jobbar med 3D-grafik med CPUn där x86_64 presterar bäst relativt ARM64, fördelen är i nivå med vad man ser här.

Finns nog flera förklaringar här, den viktigaste är nog att för de ARM64 CPUer som använder sig av ARMv8.x standarden finns bara tillgång till NEON som närmast kan liknas vid AVX2 som begränsas till 128 bitars databredd.

Nyheten i M4 och även i Cortex X4 (men inte Oryon som av allt att döma kör ARMv8.x) är att de använder sig av ARMv9 och får därmed tillgång till SVE2 (Scalable Vector Extensions v2) och SME (Scalable Matrix Extensions) som motsvarar AVX-512 och AMX hos x86.

3D-beräkningar som utförs i 64-bit precision får en hyfsat lyft att gå från 128-bitar till 256-bitar (512-bitar spelar rätt liten roll för just detta), så att x86_64 har tillgång till AVX2 är en fördel i just denna applikation över ARMv8.x.

Men omvänt har ARM64 den största fördelen i kompilering, där är M3 runt 30-35 % snabbare än 7950X/14900K per kärna. Detta är en "ren" heltals-last som inte påverkas av något annat än hög frekvens, hög perf/cykel samt att färre instruktioner behövs. Det sista är något som historiskt varit till fördel för x86_64, ett typiskt x86_64 program har färre instruktioner än ett PowerPC eller MIPS program (RISC). Även här är ARM64 unik, det krävs typiskt färre ARM64 instruktioner än x86_64 instruktioner för att göra samma sak i heltal (flyttal är mycket mer 1:1 så där blir det viktigare att ha "optimal databredd" för problemet).

Skrivet av Mordekai:

Många påstår ju att man kan se x86 dö ut inom en inte alltför avlägsen framtid, det kanske stämmer men jag vet inte hur alla ingenjörer som ritar mekanisk CAD skall gå med på det nedköpet.

Alla som tror att x86 ska dö inom överskådlig framtid har nog lite dålig koll på hur det sett ut historisk. x86_64 var under väldigt lång tid både billigare och snabbare än SPARC och POWER maskiner som var det "enda seriösa för servers" när jag började jobba på 90-talet. Det fanns under många många år en marknad för dessa, POWER finns ju fortfarande kvar men det är otroligt nischat och därmed relativt dyrt.

Skrivet av Mordekai:

För liten förklaring, normalt sett kräver inte mekanisk CAD särskilt mycket men vissa specialfunktioner kräver väldigt mycket geometriska beräkningar, exempelvis shell på en komplex solid. Dvs man säger att soliden skall gröpas ur och kvar skall endast finnas ett ytterskal, exempelvis om du behöver kapsla in exempelvis elektronik i en annan del. Man kan också göra utvändig shell och då blir det mer som exempelvis ett mobilskal. Detta är det enklaste exemplet jag kan komma på där det verkligen kan ta tid för beräkningarna eftersom de inte kan parallelliseras, Fusion 360 och Solidworks har en massa smarta funktioner som på liknande sätt måste räkna ut seriellt över ett helt objekt.

Alla 3D beräkningar är till viss del data-parallella, så de kommer få bättre prestanda om man använder sig ett av bra bibliotek. Kör man med 32-bit float är 128-bitar optimal databredd (man behöver 96 till 128 bitar beroende på typ av koordinatsystem för att hantera 3 dimensioner med ett register) medan 64-bit float behöver 265-bitar (192 till 256 bitar beroende på koordinatsystem).

Sen är det fullt möjligt att problemet inte är uppgifts-parallellt, d.v.s. det kan bara effektiv använda en CPU-kärna. Det är typiskt fördel x86_64 då de har brutal maxfrekvens, men perf/cykel är i många fall så mycket högre att det ändå blir snabbare på ARM64. CAD verkar vara ett exempel på där x86_64 tokhöga frekvens i slutändan är viktigare, kompilering är ett fall där perf/cykel är så mycket högre hos ARM64 att den är snabbast.

Skrivet av Mordekai:

Att det finns rätt stor varians mellan olika fall. Men även i det som verkar vara "worst-case" kan man ändå se i den benchmark du presenterar här att perf/W är på en helt annan nivå även då för ARM64, det är nästa en tiopotens bättre.

Skrivet av Mordekai:

Ingen skulle bli gladare än jag om man kunde motivera en Mac för mekanisk CAD/CAM. Batteridrift är inte en bonus, snarare tvärtom eftersom det är den delen i datorn som idag slits snabbast. Jag har svårt att tro att detta skulle vara det enda scenario där Apple-Silicon-optimerad mjukvara är underlägset X86. Trist med monolitiska trender generellt, först var det klockfrekvens, sedan kärnor, sedan logiska kärnor/trådar och nu prestanda per watt. Alla är bra på sitt sätt men när branschen rör sig helt parallellt pga ett enda benchmark så gråter jag lite. Personligen vill jag ha det bästa av alla världar (förutom parallellisering vilket gör sig bättre på GPU). X antal (säg fyra) vrålsnabba kärnor helt symmetrisk layout av all IO internt och fett med extern IO som inte äter CPU-cykler. Om jag behöver mer parallellt skeppar jag det till en server helst.

Att perf/W är så viktigt är för att det är den mest kritiska egenskapen för de trender vi har.

Datacenter går mot allt fler CPU-kärnor. Hur bra perf/W + hur mycket kisel som behövs per kärna är begränsade faktorer. Hos AWS, Azure och Google Cloud får man som kund lägre priser för samma kapacitet om man kör på ARM64 instanser.

Bärbara har länge haft en trend mot kompakta enheter samtidigt som de i allt större grad ersätter stationära datorer på arbetsplatserna. Lång effekt är en förutsättning för formen, men man vill ändå ha hög prestanda för att klara krävande uppgifter. Perf/W är därför kritiskt.

Stationär desktop lär vara där x86_64 stannar längst. Här är fördelar minst med ARM64. Är möjligt att skapa väldigt högt klockade ARM64 baserade mikroarkitekturer, det kanske händer men lär hända sist då denna marknad totalt sett är den minsta och därmed ekonomiskt minst viktiga.

Visa signatur

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

Permalänk

x86 är gammal dritt. En gammal arkitektur skapad för vad Intel på 70talet ansåg var det bästa.
Det är självklart att denna arkitektur i all oändlighet inte kommer vara den mest optimala. Detta precis som ett hus byggt på 70tal med finrum, kall källare etc inte är det optimala emot vad folk idag vill ha.

Men med datorsystem så är hårdvara en del och mjukvara en annan. x86 har varit störst sedan 90talet, det är den som nästan alla har jobbat med sedan dess, även om Apple, Chromebook m.m har tagit marknad i slutet.
Men för arbetsdator så satsar tillverkare på samma mjukvara som de har haft hur länge som helst och deras kunder. Vissa otroligt populära mjukvaror som photoshop m.m portas fort.

Jag själv har nyss beställt en iPad Air 2024. Jag funderade på den vs pron och gjorde en snabb koll på vilken programvara ville jag köra på ipaden som nyttjade pron? Svaret var egentligen igen. (jo, jag vill köra photoshop, men ej betala för den)
Lite samma blir det med en macbook, köper man den bästa så är den kraftigt. Men vilka mjukvaror kan jag köra på den? Där man måste köra samma programvara som kund. Den blir väldigt begränsad och man har då datakraft för att fjärrstyra en annan dator med windows.

Min gissning är att vi går emot att allt fler använder datorenheter. Kanske kommer surfplattor med tangentbord bli the shit den stora skaran. Det är lite svårt att gissa.
Men marknaden för x86 lär bli mindre, då kommer det in mindre pengar till utveckling och detta leder till att x86 blir dyrare. När vi kommer till skedet att i princip ingen privatperson för privatbruk köper x86 går spekulera om. Jag skulle vara väldigt förvånad om x86 är störst även om 40år. 20år skulle man också kunna tro, men det beror lite på konjektur etc övrigt. Alltså om folk fortsätter att slösa pengar på nya datorprylar hela tiden eller om det går trögare.

*edit*
Att macbook är så populärt på swelockers beror på användarna. Det var inte länge sedan endast spelprestanda i absolut lägsta upplösning med sämsta grafikinställlningarna var det intressant här. Där folk skrev att de bryr sig inte det minsta hur processorn fungerar i produktiva uppgifter. De skulle aldrig få för sig att låta datorn arbeta med något samtidigt som de spelade, detta behov var helt obegripligt och bara missvisande test att göra. Jag ser det komisk att det har förändras så snabbt, men det är positivt att inte allt kretsar kring spel längre.

Och Macbook har ju en enorm fördel med att de är så tysta, jag själv håller på att bygga ljudisolering väg för vissa dyra pclaptops. Jag skämtar ej, jag vill ej höra denna högfrekventa fläkt 10h om dygnet. Hade tillverkarna som förr satt in vettiga fläktar i laptopparna så hade jag sluppit göra detta. Det är skillnad på ljud och ljud, högfrekventa ljud som vissa av dagens laptop har kan vara riktigt störande.

Permalänk
Datavetare
Skrivet av lillaankan_i_dammen:

*edit*
Att macbook är så populärt på swelockers beror på användarna. Det var inte länge sedan endast spelprestanda i absolut lägsta upplösning med sämsta grafikinställlningarna var det intressant här. Där folk skrev att de bryr sig inte det minsta hur processorn fungerar i produktiva uppgifter. De skulle aldrig få för sig att låta datorn arbeta med något samtidigt som de spelade, detta behov var helt obegripligt och bara missvisande test att göra. Jag ser det komisk att det har förändras så snabbt, men det är positivt att inte allt kretsar kring spel längre.

Vet inte om jag skulle kalla MacBook "populär" på SweC. Detta är primärt en webbplats där en av de stora gemensamma nämnarna är spelintresse.

Sen är det lättare att "prata förbi" varandra idag än för 10-15 år sedan, saker har blivit mer hetrogena.

För 10-15 år sedan kunde jag som i första hand alltid prioriterat prestanda för programutveckling med fördel använda spelbenchmarks som proxy. Det som gav bra spelprestanda gav också bäst prestanda i "mitt" områden. Det stämmer rätt dåligt idag, 7800X3D som är toppvalet för spel är en bra bit från toppen för programutveckling, AI etc.

Det som gör 7800X3D till en väldigt bra spel-CPU, dess gigantiska LLC, ger märkligt nog nära noll utdelning i nästan alla andra CPU-krävande fall. Så spel har blivit ett väldigt udda-fall med avseende på CPU-krav!

Sen har också trenden i spel ändrats, undrar om vi någonsin varit så lite CPU-begränsade i spel som vi är idag? Blev rätt förvånad vilken icke-uppgradering grabbens dator gjorde när den gick från 5600X till 7800X3D. Har man "bara" ett 4070Ti och spelar i 2560x1440 skulle jag gissa att ingen skulle kunna avgöra vilken av dessa CPUer som används i typ 98 av 100 spel.

Är ju fortfarande så att det vi ser i 1280x720 med ett 4090 i form av CPU-skalning rimligen kommer vara bli relevant "i framtiden". Skillnaden är att för 10-15 år sedan var det normalt "nästa GPU-generation", nu är det nog mer "i alla fall om 2-3 GPU-generationer". Problemet är att dagens CPUer lär vara omsprunga flera gånger om 4-6 år från nu...

Det andra vi ser är ju antal CPU-kärnor. Rätt säker att både Intel och AMD idag medveten håller ned prestanda på deras 6-kärniga desktopmodeller, om man inte skulle göra det skulle det bli poänglöst för "gamers" att köpa dyrare modeller.

Sen har vi det vi ser med t.ex. CAD. För ett specifik område kan det fungera "sådär" med att använda något genomsnitt av tester. Är CAD det enda man optimerar för ska man naturligtvis titta på CAD-benchmarks, för det som också hänt på senare tid är att variansen inom specifika områden mellan CPU-modeller har ökat rätt mycket.

Och då är nog ändå CAD ett relativt "milt" fall, inom AI lär vi få se enorm varians mellan CPU-modeller. Finns ett par exempel redan nu (som även det går att se i GB6 deltester). Vissa typer av AI operationer kan vara nära dubbelt så snabba på Zen4 (som har AVX-512) mot Zen3 (som inte har AVX-512). Samma går att se hos M4 (som har SME) och M3 (som inte har SME).

AI är förövrigt det många på SweC skrek efter när modeller som Zen 1800X släpptes: här har vi något som "normalanvändaren" kan köra som, om man väljer alt. kör fall som lämpar sig bäst för CPU, skalar otroligt väl med CPU-kärnor givet tillräckligt stor/komplicerad modeller
Så om/när spel börjar använda ML som AI kanske även speldatorer med 16 kärnor blir relevant (nåja, är normal vid träning och inte vid inferens det tenderar skala väl, men ändå).

Här är inte CAD unikt. Även om det finns enstaka fall som skalar väl med CPU-kärnor är vi tyvärr fast med att det finns, och kommer finnas inom överskådlig tid, massor med fall där det viktigaste är absolut prestanda i single-core fallet.

ARM64 vs x86_64 lägger på ännu en dimension på variansskalning givet hur stor varians det är inom olika specifika fall. Så kommer bli allt svårare att välja "optimal" konfiguration framåt. Lär bli mycket dåliga förslag då det som är optimalt för mig mycket väl kan vara långt ifrån optimalt för dig. Något vi ser i CAD vs programming t.ex...

Positiva är att ISA aldrig varit så liten tröskel att ta sig över som idag. Apples övergång från x86_64 till ARM64 gick otroligt snabbt. Listan program som redan idag finns i ARM64 version är förvånansvärd stor redan innan första "riktigt" Windows-baserade ARM64 plattform ens nått marknaden.

Man måste rätt mycket göra "idiotiska saker" för att det ska krävs mer än en omkompilering, eller ingenting om man kör .NET, Java, Python, etc. för att gå från x86_64 till ARM64. Även när man håller på med C eller C++ är tröskeln långt mindre från x86_64 till ARM64 än t.ex. x86_64 till PowerPC eller MIPS.

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 Yoshman:

Positiva är att ISA aldrig varit så liten tröskel att ta sig över som idag. Apples övergång från x86_64 till ARM64 gick otroligt snabbt. Listan program som redan idag finns i ARM64 version är förvånansvärd stor redan innan första "riktigt" Windows-baserade ARM64 plattform ens nått marknaden.

Man måste rätt mycket göra "idiotiska saker" för att det ska krävs mer än en omkompilering, eller ingenting om man kör .NET, Java, Python, etc. för att gå från x86_64 till ARM64. Även när man håller på med C eller C++ är tröskeln långt mindre från x86_64 till ARM64 än t.ex. x86_64 till PowerPC eller MIPS.

Plattformsoberoende har ökat, främst av att man mer använder webbläsarlösningar där ingen mjukvara installeras direkt på klienterna.

För de som sysslar med väldigt små saker så är det enkelt att bara kompilera om. För andra så används funktioner i windows och övriga programvaror. Man har två val, kör windows virtuellt eller bygg om varenda windowsfunktion som används och mjukvara från andra tillverkare till det nya operativsystemet.
Jag ser det lite som det är superlätt att designa ett nytt lok med sårvidden1800mm om man bortser från att det måste fungera med annat som att kunna köra på våra svenska järnvägsspår.

Jag tycker inte alls detta beroende är bra, det gör utveckligen trög, men så är det med mycket. Hela stockholm och göteborgs innestad är ej designade för nutida behov.

Men många användare inom it har typ deras dator som en ren klient och surfar in på sidor och aldrig behöver fundera på serversidan problem.

Permalänk
Medlem

Ta en titt på youtube hur en 3 (nu) gammal m1 klarar world of warcraft. Det var on par med en normal pc med skapligt häftig gpu.
Den kan dessutom spela in det typ i 30fps i bakgrunden. Sedan tänker du på att de är uppe i m4 nu
Här är en med m1 pro ifall du inte orkar söka och så jämför du det med valfri x86 15000:- dator.
https://www.youtube.com/watch?v=RLPJQY6U_DU

Permalänk
Datavetare
Skrivet av lillaankan_i_dammen:

Plattformsoberoende har ökat, främst av att man mer använder webbläsarlösningar där ingen mjukvara installeras direkt på klienterna.

För de som sysslar med väldigt små saker så är det enkelt att bara kompilera om. För andra så används funktioner i windows och övriga programvaror. Man har två val, kör windows virtuellt eller bygg om varenda windowsfunktion och mjukvara från andra tillverkare att fungera på det andra operativsystemet.
Jag ser det lite som det är superlätt att designa ett nytt lok med sårvidden1800mm om man bortser från att det måste fungera med annat som att kunna köra på våra svenska järnvägsspår.

Att byta OS kan vara ett stort steg, framförallt om man startar från Windows som på många sätt skiljer sig mer från MacOS och Linux än vad MacOS och Linux skiljer sig från varandra.

Men i detta specifika fall var det just "enkelt" då Fusion 360 redan fanns till MacOS/x86_64. Att då fixa en MacOS/ARM64, vilket man gjort, är typiskt ett väldigt litet jobb.

Om två dagar finns kommer första "riktiga" ARM64 baserade Windows-plattformen ut på marknaden.

Dels har Microsoft gått ännu längre än Apple i deras "köra x86 program på ARM64 CPU" än Apple gjort med Rosett 2 då Windows 11 även stödjer en variant där man laddar in både ARM64 (typiskt själva huvudprogram) och x86_64 kod (t.ex. plugins som bara finns i binärformat) i samma adressrymd! Det gör ju att gamla program, som rimligen inte har några problem att köra på moderna CPUer, fungerar direkt.

Och dels verkar inte detta försök vara den halvmesyr alla tidigare försök att köra Windows på icke-x86 vara. Program som MS Office, Visual Studio, Photoshop, m.fl. finns redan som ARM64. .NET har gått från att "kan köra ARM64 med presterar sådär" till att i .NET 8 faktiskt utnyttja fördelarna i ARM64 så det finns prestandafördelar som kommer kvarstå till om/när Intel någonsin får till sin APX-utökning.

Givet att Fusion 360 redan finns till MacOS/ARM64 samt Windows/x86_64 måste det vara trivialt att erbjuda det till Windows/ARM64 också.

Är själv positivt överraskad hur bra ARM64 versionen av Windows 11 fungerar. Enda anledning att jag använder den (på en M3 Max Mac via Parallells) är just för ett fall som beror av Windows men inte på något sätt är fast med x86.

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:

Positiva är att ISA aldrig varit så liten tröskel att ta sig över som idag. Apples övergång från x86_64 till ARM64 gick otroligt snabbt. Listan program som redan idag finns i ARM64 version är förvånansvärd stor redan innan första "riktigt" Windows-baserade ARM64 plattform ens nått marknaden.

Apple hade redan gjort stora delar av det nödvändiga jobbet för att byta ISA, och hade skaffat sig hel del erfarenhet av att göra det.
Bytet från x86_64 till ARM64 är trots allt tredje gången de byter ISA för sina datorer.
68k -> PowerPC -> x86_64 -> ARM64

Från egen erfarenhet av att porta program mellan olika arkitekturer så är det den första portningen som är besvärligast, men efter hand så hittar man och eliminerar/isolerar all plattforms-specifik kod.

Permalänk
Medlem
Skrivet av Mordekai:

Många påstår ju att man kan se x86 dö ut inom en inte alltför avlägsen framtid, det kanske stämmer men jag vet inte hur alla ingenjörer som ritar mekanisk CAD skall gå med på det nedköpet.

Det stämmer inte, x86 dominerar fortfarande stort. Utvecklar du för molnet (vilket många gör) och kompilerar väljs nästan uteslutande x86 maskiner.
Det är bra med konkurrens men jag ser inte att att något kommer dö och orsaken till ARMs något mer effektiva processorer skulle snabbt kunna "fixas" om x86 lät bli att vara bakåtkompatibla från första versionerna.

Permalänk
Datavetare
Skrivet av Erik_T:

Apple hade redan gjort stora delar av det nödvändiga jobbet för att byta ISA, och hade skaffat sig hel del erfarenhet av att göra det.
Bytet från x86_64 till ARM64 är trots allt tredje gången de byter ISA för sina datorer.
68k -> PowerPC -> x86_64 -> ARM64

Från egen erfarenhet av att porta program mellan olika arkitekturer så är det den första portningen som är besvärligast, men efter hand så hittar man och eliminerar/isolerar all plattforms-specifik kod.

Håller med om att första portningen är den mest utmanande.

Men tröskeln har minskat jämfört med tidigare. Har gjort rätt många projekt i C som hade stöd för x86, Arm, MIPS, PowerPC, SH4 och SPARC. Bara ett enda av de värsta hålen för att stödja alla dessa finns kvar för att gå x86_64 <-> ARM64: minneskonsistensmodellen.

Men även om man av någon anledning skulle vilka stödja big-endian MIPS och x86_64 finns ju en annan anledning till varför tröskeln är långt mindre idag: allt mer skrivs i andra språk än C där man lärt sig av misstaget just kring portabilitet. Kompilerande språk som Go och Rust ser till att nästan ingen av fallen "råkar" fungera på x86 även om det är "undefinied behavior" i C/C++ samt "det fungerar på x86 men är en dålig idé av prestandaskäl, fast kraschar tyvärr på MIPS/SPARC/PowerPC" passerar kompilatorn.

Vidare skrivs allt mer i plattformar som .NET, JVM, Python, Node/JS etc där problemet överhuvudtaget inte finns om man inte verkligen gör korkade saker för att få det bundet till x86. Möjligen undantag gamla .NET framework, där var det kanske lite väl lätt att använda x86-specifika saker, men ett icke-problem i dagens .NET Core.

Testade gratisversionen av Autodesk Fusion 360. Givet att det ser ut lite som något från 90-talet kan jag tänka mig att detta har rätt mycket legacy i sig. Men hindrade uppenbarligen dem inte ändå från att fixa en MacOS/ARM64 version som tydligen fungerar riktigt bra om man ska tro det som sägs i videon.

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 Erik_T:

Apple hade redan gjort stora delar av det nödvändiga jobbet för att byta ISA, och hade skaffat sig hel del erfarenhet av att göra det.

Apple har ett stort problem i att utvecklare inte kan lita på dem. Deras miljö är så sluten och kontrollerad. Och de har missbrukat förtroendet.
Läget kommer bli bättre om fler släpper maskiner med ARM och självklart har bättre utvecklingsmiljöer och flexibla kompilatorer underlättat.

Permalänk
Datavetare
Skrivet av klk:

Det stämmer inte, x86 dominerar fortfarande stort. Utvecklar du för molnet (vilket många gör) och kompilerar väljs nästan uteslutande x86 maskiner.
Det är bra med konkurrens men jag ser inte att att något kommer dö och orsaken till ARMs något mer effektiva processorer skulle snabbt kunna "fixas" om x86 lät bli att vara bakåtkompatibla från första versionerna.

Det stämmer inte. Problemen i x86 är mer fundamental än så, man behöver i praktiken bryta kompatibilitet med dagens 64-bit design för att nå ARM64.

Intel kommer göra ett försök att inom ramen för x86 komma så nära ARM64 som möjligt via deras APX.

Men går att säga redan nu att man kommer inte nå ända fram. "Risken" är väl att man mycket väl kan nå "tillräckligt nära". Säger risk för då fortsätter vi med en sämre teknik än vad som redan finns på marknaden.

Problemet med APX är att det i sig ger ingenting i form av prestanda. För att utnyttja det måste man kompilera om programmen så de utnyttjar APX, fast då får man ett program som inte fungerar på någon av dagens x86_64 CPUer. I det läget: varför inte bara gå till ARM64 om man ändå måste kompilera om?

Fördelen med APX är att det kan införas gradvis då CPU-modeller som stödjer detta kommer kunna köra dagens x86_64 binärer utan emulering. Fast om binäröversättning fungerar bra, har man då vunnit något?

Framförallt givet att det har visat sig vara en barriär för Arm CPUer som haft stöd både för 32-bit Arm och ARM64 (som är två helt separata ISA, ARM64 är inte en utökning av 32-bit Arm). Hos Arm, Apple och nu Qualcomm har man sett ett klart lyft i perf/cykel hos den första modell där man helt släppt 32-bit stödet. Detta då det finns designbeslut i 32-bit Arm (och dessa finns även hos x86_64) som gör det svårt att designa en extremt "bred" mikroarkitektur med bra effektivitet.

I.e. för att få full utväxling på APX kanske man likt ARM64 behöver släppa stödet för den "gamla" ISAn. Problemet med APX är att den inte är en total reset av ISA likt ARM64 helt utan bagage, utan man klämmer i praktiken in ett nytt ISA i samma "namespace" som dagens x86_64 upptar. En nackdel Intel nämner är att genomsnittlig längd på APX instruktioner kommer bli >4 bytes (fast man tror det går på ett ut totalt sett då, likt ARM64, APX ger samma program på färre instruktioner. ARM64 gör detta dock med 4 bytes per instruktion så fördel mot APX)...

Vidare tror jag användningen av ARM64 i "molnet" är större än många tror. Om man använder Java, .NET, Python, Go, Rust, Node/JS etc i det man kör: vad är problemet att byta till ARM64?

Man får mer för pengarna om man väljer ARM64, kostar "upp till 40 % mindre" (exakt siffra beror på det specifika fallet) att få samma råkraft på en ARM64 instans hos AWS mot att få det på x86_64.

Hittade denna från 2021, redan då var 14 % av alla EC2 instanser ARM64 baserade och ca 50 % av de som vid tidpunkten adderades var ARM64 baserad (vilket i.o.f.s. låter högre än jag väntat mig, men folk är kanske bättre på att jämföra två siffror än man tror...).

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 Erik_T:

Apple hade redan gjort stora delar av det nödvändiga jobbet för att byta ISA, och hade skaffat sig hel del erfarenhet av att göra det.
Bytet från x86_64 till ARM64 är trots allt tredje gången de byter ISA för sina datorer.
68k -> PowerPC -> x86_64 -> ARM64

Från egen erfarenhet av att porta program mellan olika arkitekturer så är det den första portningen som är besvärligast, men efter hand så hittar man och eliminerar/isolerar all plattforms-specifik kod.

Undra vad som hade hänt med Apples kunder om de inte framförallt hade bestått av slutanvändare på klientsidan, som ofta jobba med superpopulära grafiska och liknande program etc?

Jag ser det lite som användare kan vid olika generationer av spelkonsoler hoppa mellan Sony, Microsoft, Nintendos spelkonsoler utan större problem. Arkitekturen i konsolerna kan skilja sig helt och hållet det går för användarna fint utan problem.

På datorsidan finns det mjukvaror, vissa är köpta andra är utvecklade internt eller betalat någon för att göra. De skulle bli extrema kostnader att hålla på och koda om hela tiden.
Hur har Appleanvändarna löst detta? Jo de kör väldigt lite av denna mjukvara som tillverkas i små volymer men som är dyra. Där t.ex. den enda person som utvecklade och supportade mjukvaran kan vara avliden sedan 10år tillbaka, det kostar då en hel del att sätta in en konsult för 1500kr/h och gå igenom koden, förstå sig på allt vad den gör och sedan porta lösningen.
Vid många program så hjälper det hur duktig ren programmerare man är, man behöver även domänkunskap inom det mjukvaran är till för. Och dessa program i små volymer är ofta otroligt dåligt dokumenterade.

*edit*
Jag tror att x86 kommer dö ut en dag, precis som det mesta gamla en dag ersätts. Det jag hela tiden har trott, är att det finns vissa typer av användare som lättare kan hoppa hur som helst. Vi börjar gå emot ett skede att väldigt många kan göra allt de vill på en iPad om de så ville. Detta kan som sagt leda till att x86 halkar efter och bli dyr, då kommer saker sakta byta plattform.

Jag ser lite deja vu när jag handlar verktyg. Där det är verktyg för den stora skaran som är billigt, resten blir så fruktansvärt dyrt. Så även om ens behov av verktyg är utanför den stora skaran, så kan man fundera om man ändå ska köpa verktyg för dessa?
På svenska: Den lilla bilverkstaden kanske kan handla lite verktyg på biltema istället för andra dyrare butiker som swedol.

Permalänk
Medlem
Skrivet av Yoshman:

Vidare tror jag användningen av ARM64 i "molnet" är större än många tror. Om man använder Java, .NET, Python, Go, Rust, Node/JS etc i det man kör: vad är problemet att byta till ARM64?

Man får mer för pengarna om man väljer ARM64, kostar "upp till 40 % mindre" (exakt siffra beror på det specifika fallet) att få samma råkraft på en ARM64 instans hos AWS mot att få det på x86_64.
https://images.anandtech.com/doci/16640/Neoverse_Intro_10.png
Hittade denna från 2021, redan då var 14 % av alla EC2 instanser ARM64 baserade och ca 50 % av de som vid tidpunkten adderades var ARM64 baserad (vilket i.o.f.s. låter högre än jag väntat mig, men folk är kanske bättre på att jämföra två siffror än man tror...).

Absolut, det är för väldigt många mest en fråga om "varför ska jag betala mer för x86?", för ofta finns ingen egentlig uppsida.

Gäller ju även väldigt mycket native-prylar (tänker t.ex. då alla gamla C/C++-baserade projekt) som inte är "custom" men är en del av infrastrukturen.
Det allra mesta i det s.k. molnet snurrar ju på Linux, och "alla" tjänster som normalt figurerar i "Linuxvärlden" funkar ju på ARM64, oavsett vilket språk de är skrivna i. Om det nu är ett Mysql eller vad det nu må vara som behövs.

Visa signatur

Desktop: Ryzen 5800X3D || MSI X570S Edge Max Wifi || Sapphire Pulse RX 7900 XTX || Gskill Trident Z 3600 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Medlem
Skrivet av Yoshman:

Vidare tror jag användningen av ARM64 i "molnet" är större än många tror. Om man använder Java, .NET, Python, Go, Rust, Node/JS etc i det man kör: vad är problemet att byta till ARM64?

Det tror inte jag och utvecklar man enbart för Java, .NET, Python eller något annat är det sällan man har krav på prestanda. Skickligheten bland dessa programmerare är också begränsad. Det mesta bygger ändå på kod skriven i C++, även de språk du räknar upp förlitar sig på kod skriven i C/C++.

Jag har svårt att tro att de som utvecklat kod och börjat de senaste 5 åren inte tänkt på att kompilera för olika miljöer, att kompilera om är inget större problem och då får man också maximal prestanda (vilket kan skilja en hel del).

Om inte annat sitter utvecklare på olika maskiner, det är apple, linux och windows och jag vet knappt ett enda företag där man måste välja ett visst operativ. Skall en sådan miljö fungera måste de också ha mjukvara så kan köras på de olika operativen.

Apple duger fortfarande bara för ganska vanliga konfigurationer. Skall du gå bara lite utanför det vanliga blir det problem.
Det tar ett tag innan molnet (företag som erbjuder cloudlösningar) har uppdaterat sina valbara miljöer. Bara för att det kommer ny version av ett så vanligt operativ som Ubuntu kan det dröja innan versionen fungerar för Amazon (som är störst).

Permalänk
Medlem
Skrivet av lillaankan_i_dammen:

Där t.ex. den enda person som utvecklade och supportade mjukvaran kan vara avliden sedan 10år tillbaka, det kostar då en hel del att sätta in en konsult för 1500kr/h och gå igenom koden, förstå sig på allt vad den gör och sedan porta lösningen

Du beskrev just z/OS och Mainframe, beskriver väl rätt väl var x86 hör hemma om ett par år, den stora massan har gått vidare till roligare saker, men några få (visserligen verksamhetskritiska) saker håller krampaktigt tag i plattformen.

Skönt, då kan de som tillber x86 räkna med anställningstrygghet fram till pension, medan vi övriga gör roligare saker!

Visa signatur

Amd o Apple

Permalänk
Medlem
Skrivet av Yoshman:

Det stämmer inte. Problemen i x86 är mer fundamental än så, man behöver i praktiken bryta kompatibilitet med dagens 64-bit design för att nå ARM64.

Intel kommer göra ett försök att inom ramen för x86 komma så nära ARM64 som möjligt via deras APX.

Men går att säga redan nu att man kommer inte nå ända fram. "Risken" är väl att man mycket väl kan nå "tillräckligt nära". Säger risk för då fortsätter vi med en sämre teknik än vad som redan finns på marknaden.

Problemet med APX är att det i sig ger ingenting i form av prestanda. För att utnyttja det måste man kompilera om programmen så de utnyttjar APX, fast då får man ett program som inte fungerar på någon av dagens x86_64 CPUer. I det läget: varför inte bara gå till ARM64 om man ändå måste kompilera om?

Fördelen med APX är att det kan införas gradvis då CPU-modeller som stödjer detta kommer kunna köra dagens x86_64 binärer utan emulering. Fast om binäröversättning fungerar bra, har man då vunnit något?

Framförallt givet att det har visat sig vara en barriär för Arm CPUer som haft stöd både för 32-bit Arm och ARM64 (som är två helt separata ISA, ARM64 är inte en utökning av 32-bit Arm). Hos Arm, Apple och nu Qualcomm har man sett ett klart lyft i perf/cykel hos den första modell där man helt släppt 32-bit stödet. Detta då det finns designbeslut i 32-bit Arm (och dessa finns även hos x86_64) som gör det svårt att designa en extremt "bred" mikroarkitektur med bra effektivitet.

I.e. för att få full utväxling på APX kanske man likt ARM64 behöver släppa stödet för den "gamla" ISAn. Problemet med APX är att den inte är en total reset av ISA likt ARM64 helt utan bagage, utan man klämmer i praktiken in ett nytt ISA i samma "namespace" som dagens x86_64 upptar. En nackdel Intel nämner är att genomsnittlig längd på APX instruktioner kommer bli >4 bytes (fast man tror det går på ett ut totalt sett då, likt ARM64, APX ger samma program på färre instruktioner. ARM64 gör detta dock med 4 bytes per instruktion så fördel mot APX)...

Vidare tror jag användningen av ARM64 i "molnet" är större än många tror. Om man använder Java, .NET, Python, Go, Rust, Node/JS etc i det man kör: vad är problemet att byta till ARM64?

Man får mer för pengarna om man väljer ARM64, kostar "upp till 40 % mindre" (exakt siffra beror på det specifika fallet) att få samma råkraft på en ARM64 instans hos AWS mot att få det på x86_64.
https://images.anandtech.com/doci/16640/Neoverse_Intro_10.png
Hittade denna från 2021, redan då var 14 % av alla EC2 instanser ARM64 baserade och ca 50 % av de som vid tidpunkten adderades var ARM64 baserad (vilket i.o.f.s. låter högre än jag väntat mig, men folk är kanske bättre på att jämföra två siffror än man tror...).

Fast hur är Apples/arm prestanda när man börjar täppa till alla säkerhetshål?
Typ denna
https://www.tomsguide.com/computing/macbooks/unpatchable-vuln...

Gissar fler kommer ju mer användningen ökar.

Visa signatur

Intel i5 12600k OC 5.2GHz | Arctic Freezer II 240 | MSI Pro Z690 A | 2x 16Gb Corsair LPX 3200MHz | Asus Tuf 4070 Ti | Corsair Rm850x V3 | 2x 1Tb Samsung 980 m2 | 7x Noctua A14x25

Permalänk
Datavetare
Skrivet av klk:

Det tror inte jag och utvecklar man enbart för Java, .NET, Python eller något annat är det sällan man har krav på prestanda. Skickligheten bland dessa programmerare är också begränsad. Det mesta bygger ändå på kod skriven i C++, även de språk du räknar upp förlitar sig på kod skriven i C/C++.

Jag har svårt att tro att de som utvecklat kod och börjat de senaste 5 åren inte tänkt på att kompilera för olika miljöer, att kompilera om är inget större problem och då får man också maximal prestanda (vilket kan skilja en hel del).

Är helt med på att väldigt mycket, för att inte säga det mesta, som skrivs i Java och C# nog inte skrivs med compute-prestanda som top-prio. Blir liksom meningslöst om man blandar in en RDB som ändå blir som att köra med ankaret nere.

Det tog typ 20 år, men idag är kod som kör i moderna JVM:er och .NET miljöer prestandamässigt väldigt nära C++ om man prioriterar prestanda när man utvecklar.

Sen är jag fullt medveten om "Det mesta bygger ändå på kod skriven i C++, även de språk du räknar upp förlitar sig på kod skriven i C/C++.". Man vinner inget på att köra PyTorch och TensorFlow som C++ program, det går lika fort i Python fast är långt enklare att använda. Detta då de prestandakritiska delarna körs av samma C++ bibliotek oavsett.

Men alla dessa C/C++ saker finns ju redan för ARM64, så de presterar ingen tröskel. Eventuell tröskel finns i "din" kod och den skrivs i allt större utsträckning i andra språk än C++.

Skrivet av klk:

Om inte annat sitter utvecklare på olika maskiner, det är apple, linux och windows och jag vet knappt ett enda företag där man måste välja ett visst operativ. Skall en sådan miljö fungera måste de också ha mjukvara så kan köras på de olika operativen.

Apple duger fortfarande bara för ganska vanliga konfigurationer. Skall du gå bara lite utanför det vanliga blir det problem.
Det tar ett tag innan molnet (företag som erbjuder cloudlösningar) har uppdaterat sina valbara miljöer. Bara för att det kommer ny version av ett så vanligt operativ som Ubuntu kan det dröja innan versionen fungerar för Amazon (som är störst).

Vad är problemet att sitta med Apple, så har kan min desktop se ut. Har ofta behov av att köra på MacOS, Windows och Linux

Klicka för mer information
Visa mer

Allt detta körs på samma M3 Max dator

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:

Är helt med på att väldigt mycket, för att inte säga det mesta, som skrivs i Java och C# nog inte skrivs med compute-prestanda som top-prio. Blir liksom meningslöst om man blandar in en RDB som ändå blir som att köra med ankaret nere.

Det tog typ 20 år, men idag är kod som kör i moderna JVM:er och .NET miljöer prestandamässigt väldigt nära C++ om man prioriterar prestanda när man utvecklar.

Där jag jobbar kan vi i princip använda hur mycket hårdvara som helst, möjligen är det något udda men vi simulerar kemiska reaktioner med superdatorer. Ofta kör vi flera noder där varje nod kan vara 96 kärnor. Men skalningen till fler kärnor blir sämre och sämre. Att gå från en nod på 48 kärnor till 96 blir inte dubbelt så bra. Tror inte Amazon erbjuder mer per nod eller om det var att priset då vart onödigt dyrt.
Datorer kan då stå och jobba i flera dagar.

Det prestandakritiska är ordentligt optimerat. Inget annat än C++ duger då (finns annan specialkod skriven av forskare och där kan det variera en del, kvaliteten på den typen av kod är lite si och så). Skulle vi hitta något annat som ger bättre prestanda hade vi valt det omedelbums. Det stora problemet med nya/andra språk är att de försöker "trolla bort minneshantering", programmerare skall inte behöva tänka på minnet. Sett till prestanda blir det då genast problem. Det går kanske att skriva specialkod men eftersom andra språk har så mycket hinder för att begränsa utvecklares frihet, då blir det jobbigt.
Vi praktiserar något som idag kallas för Data orienterad design. Vanligt i spel eller där det behövs snabbhet.

Vad jag tolkar så är ändå kompilatorer så bra idag att de klarar att optimera med AVX och motsvarande på ARM, behövs inte skriva maskinkod.

En fördel med ARM är att varje extra kärna är billigare. Men det är fortfarande problem i och med att det är svårt att skala. Parallellisera arbeten effektivt till 8 kärnor är inte lätt men det går, parallellisera till mer och det blir svårare och svårare.
Låt säga att de har en dator med 1000 ARM kärnor, det måste också till mjukvara så kan nyttja dessa effektivt.

GPUer kan inte sköta den typen av funktionalitet vi eftersträvar men det kanske kommer. Är inte uppdaterad på det senaste.

Permalänk
Datavetare
Skrivet av klk:

Där jag jobbar kan vi i princip använda hur mycket hårdvara som helst, möjligen är det något udda men vi simulerar kemiska reaktioner med superdatorer.

Spännande! Vilken algoritm används?
Frågar då jag har en civ.ing i kemiteknik från KTH och gjorde examensarbete i kvantkemiska simuleringar för att bestämma effekt av molekyler som inhibitorer i protein. Detta är länge sedan nu, men krävdes med dåtidens datorer väldigt mycket beräkningskraft (använde Hartree Fock) och skrev av prestandaskäl programmet i C++.

Men då var C++ bara näst snabbaste språk, Fortran var (och är nog än) snabbare för just detta (finns optimeringar just kring matrisberäkningar som går att optimera mer med Fortran än C++, går att runda med extensioner till C/C++). Men kunde inte Fortran då och kan det inte idag heller

Skrivet av klk:

Ofta kör vi flera noder där varje nod kan vara 96 kärnor. Men skalningen till fler kärnor blir sämre och sämre. Att gå från en nod på 48 kärnor till 96 blir inte dubbelt så bra. Tror inte Amazon erbjuder mer per nod eller om det var att priset då vart onödigt dyrt.
Datorer kan då stå och jobba i flera dagar.

Ett problem med CAD verkar ju vara dålig skalning. Har man "halvbra" skalning med kärnor finns ännu en anledning att köra ARM64, den minneskonsistensmodell som används där är mer effekt jämfört med den i x86 när kärnor behöver synkronisera med varandra (vilket i princip alltid är orsaken till att saker inte skalar perfekt).

Skrivet av klk:

Det prestandakritiska är ordentligt optimerat. Inget annat än C++ duger då (finns annan specialkod skriven av forskare och där kan det variera en del, kvaliteten på den typen av kod är lite si och så). Skulle vi hitta något annat som ger bättre prestanda hade vi valt det omedelbums. Det stora problemet med nya/andra språk är att de försöker "trolla bort minneshantering", programmerare skall inte behöva tänka på minnet. Sett till prestanda blir det då genast problem. Det går kanske att skriva specialkod men eftersom andra språk har så mycket hinder för att begränsa utvecklares frihet, då blir det jobbigt.
Vi praktiserar något som idag kallas för Data orienterad design. Vanligt i spel eller där det behövs snabbhet.

Nu fattar jag att detta har en lång historik. Men om man kan starta från scratch finns fall där Rust ger bättre prestanda än C++, av samma orsak som Fortran gjorde det på 90-talet: definitionen av C/C++ förhindrar vissa typer av kompilatoroptimeringar och i vissa fall finns inte motsvarande begränsning i Rust p.g.a. hur man valt att definiera saker där.

Skrivet av klk:

Vad jag tolkar så är ändå kompilatorer så bra idag att de klarar att optimera med AVX och motsvarande på ARM, behövs inte skriva maskinkod.

Att skriva SIMD i maskinkod har aldrig fungerat speciellt bra utanför relativt enkla fall. Det är nog allt för stort steg i hur man måste resonera kring logik för optimal SIMD utnyttjande kontra hur vi människor normalt tänker kring problem.

Är detta fall Nvidia så elegant knäckte med CUDA. Intel har gjort en liknande sak för CPUer med deras ISPC (som även kan generera Arm NEON kod). I båda fallen används ju en dialekt av C++ med lite extra extensioner som gör det möjligt att beskriva vad en SIMD-lane ska utföra och kompilatorn kan sen generera väldigt effektiv SIMD kod för vald output (t.ex. SSE4, 128-bitars AVX, 256-bitars AVX, 128/256/512 bitars AVX-512 etc).

Så om inte GPGPU fungerar (som om det fungerar lär vara långt snabbare) bör ni kika på ISPC!

Skrivet av klk:

En fördel med ARM är att varje extra kärna är billigare. Men det är fortfarande problem i och med att det är svårt att skala. Parallellisera arbeten effektivt till 8 kärnor är inte lätt men det går, parallellisera till mer och det blir svårare och svårare.
Låt säga att de har en dator med 1000 ARM kärnor, det måste också till mjukvara så kan nyttja dessa effektivt.

GPUer kan inte sköta den typen av funktionalitet vi eftersträvar men det kanske kommer. Är inte uppdaterad på det senaste.

AWS verkar maxa på 64-kärnor för "bare-metal" instanser just nu. Azure verkar ha samma maxgräns (men ser att Microsoft hävdar "upp till 50 % bättre perf/$ för deras ARM64 instanser").

Sen är det väldigt viktigt att ha med sig här, framförallt om man gör "tunga beräkningar" över alla kärnor. En 64 vCPU instans med x86_64 är i praktiken 32 kärnor / 64 trådar. En 64 vCPU instans med ARM64 är alltid 64 kärnor / 64 trådar vilket för beräkningstunga fall nästan alltid betyder märkbart bättre beräkningsprestanda per vCPU om alla lastas!

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 Mordekai:

Du har nog främst missat att du snöat in på en nisch. Att enstaka programvarutillverkare optimerar för den största plattformen och ignorerar småplattformar är ju normalt, det är anledningen till att vi kör windows och inte OS/2, x86 och inte Alpha etc.

Skulle ARM bli den största plattformen kommer även CAD-mjukvara bli bäst på ARM till slut. Vi har inte sett några exempel på ett läge där det finns två stora plattformar under någon längre tid.

Tack vare ett defacto-monopol har Intel i praktiken kunnat pytsa ut så mycket eller så lite prestanda och förbättringar de ville för att mjölka kunderna maximalt. AMD's små utmaningar har emellanåt knuffat elefanten lite framåt men på det stora hela rätt långsamt.

Apple visade med M1 hur illa ställt det faktiskt var!

Hur många timmar har människor spenderat framför en skrikande fläkt för att skydda Intels marginaler? Hur många ton kol har eldats för att driva kilowatt-monster som matchas av laptops som drivs via USB-C bara för att Intel ville släppa same-same och spara pengar?

Bristen på konkurrens och teknikutveckling är ett faktiskt problem i både stort och smått, därför är det så kul att det nu äntligen händer något!

Men allt det sagt så är det ju några år sedan M1 nu. Det återstår förstås att se om Qualcomms processorer är tillräckligt mycket bättre än ex. Lunar Lake för att det skall trigga någon nämnvärd förändring.