ARM tar upp kampen mot Intel med processorer för bärbara datorer

Permalänk
Medlem
Skrivet av pv2b:

Det går att köra i386-program på Windows 10 för ARM.

https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on-...

Dock inte amd64-program.

Begränsningarna är väldigt omfattande, det stannar inte vid AMD64. Det funkar med desktop-program som inte interagerar med windows eller systemet och inte behöver några APIs eller dylikt. Det är ganska få och tama program kvar som funkar då.

Permalänk
Medlem

Tungviktarna programvarumässigt behöver vara native AArch64. Det ser Microsoft till. (Jag är osäker på om det finns annat än Microsoftprodukter som körs av mer än 10% av användarna.)

Om Microsoft garanterar att plattformen kommer att stödjas framåt, kommer levande programvara att kompileras om för ARM.

Legacy-program kommer att emuleras under överskådlig framtid.

Permalänk
Datavetare
Skrivet av Aleshi:

De jämför med dualcores. Gissningsvis har de minst det dubbla antalet kärnor och anger flertrådad prestanda.
Sedan tycker jag det hela är fult. Risken är rätt stor att kunder köper datorerna i tron om att de kan köra vanliga datorprogram.

Microsoft är väl nöjda. Det är ett steg närmare att man klipper kompatibilitet med gamla öppna program och att alla övergår till deras mer låsningsbara ekosystem.

Just inlåsningarna var ett av dundermisstagen med Window RT (utöver att man designande det för 32-bitars ARM).

Det Windows 10 som kom i samband med Snapdragon 835 (som använder en minimalt modifierad Cortex A73) laptops är verkligen "riktiga" Windows, d.v.s. jag kan som 3:e-partsutvecklare använda alla Windows standard-APIer precis som på x86. Windows 10 för ARM är också 64-bit-only sett till OS-kärnan.

Man jämför enkeltråd-prestanda. Som nämns i artikeln designar inte ARM egna CPU-kretsar, hur många CPU-kärnor som i slutändan hamnar i kretsarna är upp till de som designar systemkretsar och använder ARMs Cortex A serien som IP-block för CPU.

Tittar man på Snapdragon 845, som använder sig av en minimalt modifierad Cortex A75, så drar den ju väldigt jämnt med J5005 (Goldmont+ Atom @ 2,8 GHz och Snapdragon 845 har maxboost på 2,8 GHz).

Det tekniskt intressanta här det finns nu massor med fall som visar att 64-bitars ARM kan matcha IPC hos en på pappret mer avancerad x86. Goldmont+ är en quad-issue out-of-order design, d.v.s den kan köra upp till 4 x86 instruktioner per cykel (den har Core2 IPC faktiskt).

ARM matchar den IPCn med en tripple-issue design och med färre transistorer. Sett till "back-end" är Goldmont+ och A75 hyfsat likvärdiga (Zen är faktiskt också quad-issue, men den har rätt ordentligt mycket fetare backend vilket den i praktiken bara riktigt kan utnyttja ihop med SMT, Skylake är en hybrid quad/penta-issue).

Ställer man istället samma Snapdragon 845 mot i5-7300U så är det faktiskt jämnt skägg för multitrådfallet. Det mot en telefon som kanske kan dra ~3 W under längre tid.

Var precis så ARM försökte angripa Intel initial: visst vi är långsammare per kärna men sett över alla kärnor är vi lika snabb och mer energieffektiv alt. snabbare. Det är dömt att misslyckas på enheter som ska köra interaktiva program, vilket Intel visade på laptops och Apple verkligen visade på mobiler/pekplattor.

Det är därför denna satsning är långt intressantare.

Microsoft har fattat att ett nedlåst Windows är värdelöst, nu erbjuder man "riktiga" Windows för ARM. Det finns emulering av 32-bitars x86, men det är en nödlösning och det hela står och faller med att alla viktiga program kommer finnas som 64-bitars ARM native (vilket nu är möjligt för allt som är open source då det är "riktiga" Windows).

ARM har fattat att man kan inte ta sig an laptops genom att stoppa in en mobilkrets i enheten. Visst den drar mindre ström, men i det läget är systemkretsen ett avrundningsfel jämfört med skärm och liknande. Man måste ta fram en krets med likvärdig eller bättre prestanda per kärna (det ger en teknisk fördel) och är helt OK att dra ~15 W för dagens ultratunna laptops är helt designade kring en CPU-del som drar någonstans där.

AnandTech har en riktigt bra artikeln om mikroarkitekturen hos Cortex A76. För den som är bekant med mikroarkitekturen hos Zen, speciellt back-end, noterar att det finns rätt mycket likheter. Får man ut nära Zens totala kapacitet (över två trådar med SMT) med en enda CPU-tråd finns det nog rätt många på Intel som kallsvettas.
Edit: refererar till heltalsoperationer och minnesoperationer, Cortex A76 kommer fortfarande ligga efter "big-core" x86 sett till flyttalskapacitet. Flyttal är dock rätt irrelevant för majoriteten av alla "vanliga" program.

Goldmont+ och Zen är också på många sätt väldigt snarlik i mikroarkitektur (de är klart mer lika jämfört med Skylake), men Zen har konsekvent mer kapacitet i back-end så den presterar därför också bättre så länge som back-end (ALU-kapacitet) är en flaskhals. Cortex A75 (som i back-end är betydligt mer lik Goldmont+) -> Cortex A76 är därför lite som att gå från Goldmont+ -> Zen, kan nog vänta sig IPC lyft på ~25 %. Att låta kretsen drar mer ström gör det sedan möjligt att höja frekvensen ovanpå det.

Skrivet av Sveklockarn:

Just nu, ja. Apples stora långsiktiga utmaning är nog att inte revertera till samma styrelserumsföretag som det var i mitten av 90-talet och så sakteliga bli lika irrelevanta.

Givet storleken på pengahögen så kommer det ta ett tag...

Men poängen var mer att det är extremt svårt och därmed väldigt dyrt att designa en CPU med högre IPC än vad någon annan gjort. Är en helt annan sak att nå 80-90 % av en existerande design, då kan man nästan helt uteslutande använda kända trick. Att lägga sig först kräver en helt annan nivå på FoU. Därför inte alls speciellt förvånande att Apple är de enda som så här långt lyckats slagit Intel på fingrarna i IPC (räknat per CPU-tråd vilket är det svåraste fallet).

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

Jag sitter på en liten 13.3" laptop men med 4C/8T i7. Perfekt när man måste dra upp ett stort .NET SLN ute på resande fot. Tror det blir svårt göra power user grejer på en ARM tyvärr

Visa signatur
Permalänk
Datavetare
Skrivet av CyberVillain:

Jag sitter på en liten 13.3" laptop men med 4C/8T i7. Perfekt när man måste dra upp ett stort .NET SLN ute på resande fot. Tror det blir svårt göra power user grejer på en ARM tyvärr

Om du har en Dell XPS13 med i7-8550U så kör den CPUn i "cTDP UP", d.v.s. 25 W TDP. Ändå är det bara ~2x heltalsprestanda sett över alla kärnor (antar att det skalar eftersom du nämner 4C/8T) mot en telefon med Snapdragon 845 (som i.o.f.s. har 8C/8T men fortfarande en passivt kyld telefon). Problemet just nu är att man är chanslös i enkeltrådprestanda mot Intels laptop CPUer, DET måste man fixa.

Man tappar 10-30 % multicore prestanda (väldigt beroende på kyllösningen) om man har en modell med 15 W TDP (vilket är normalfallet för U-serie laptops).

Det som är spännande här är ju att ARM säger att man faktiskt ska designa något som drar nytta av det faktum att en laptop har rätt mycket högre TDP-utrymme jämfört med en mobil.

Den kritiska punkten för ditt användarfall blir: tänker Microsoft släppa VS som ARM64 native applikation? För mig är det ett icke-problem då jag föredrar VS Code som redan fungerar på ARM (och föredrar LLVM över MSVC, LLVM har haft ARM stöd för dag 1 och Apple lägger enorma resurser på ARM64 stödet då XCode använder LLVM).

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:

Om du har en Dell XPS13 med i7-8550U så kör den CPUn i "cTDP UP", d.v.s. 25 W TDP. Ändå är det bara ~2x heltalsprestanda sett över alla kärnor (antar att det skalar eftersom du nämner 4C/8T) mot en telefon med Snapdragon 845 (som i.o.f.s. har 8C/8T men fortfarande en passivt kyld telefon). Problemet just nu är att man är chanslös i enkeltrådprestanda mot Intels laptop CPUer, DET måste man fixa.

Man tappar 10-30 % multicore prestanda (väldigt beroende på kyllösningen) om man har en modell med 15 W TDP (vilket är normalfallet för U-serie laptops).

Det som är spännande här är ju att ARM säger att man faktiskt ska designa något som drar nytta av det faktum att en laptop har rätt mycket högre TDP-utrymme jämfört med en mobil.

Den kritiska punkten för ditt användarfall blir: tänker Microsoft släppa VS som ARM64 native applikation? För mig är det ett icke-problem då jag föredrar VS Code som redan fungerar på ARM (och föredrar LLVM över MSVC, LLVM har haft ARM stöd för dag 1 och Apple lägger enorma resurser på ARM64 stödet då XCode använder LLVM).

Funkar VS Code bra på arm? Och då menar jag på enterprise stora projekt. För att det ska gå jobba på VS krävs det 16 gig ram och minst en i7 med bra singel core perf och 8 trådar. Men då kör jag resharper och den är en känd perfomanc hogger. Sedan så ska man inte glömma att en bra disk gärna nvme är viktigt.

edit: Jag är förövrigt sjukt känslig när det gäller väntetid när jag jobbar

Visa signatur
Permalänk
Datavetare
Skrivet av CyberVillain:

Funkar VS Code bra på arm? Och då menar jag på enterprise stora projekt. För att det ska gå jobba på VS krävs det 16 gig ram och minst en i7 med bra singel core perf och 8 trådar. Men då kör jag resharper och den är en känd perfomanc hogger. Sedan så ska man inte glömma att en bra disk gärna nvme är viktigt.

edit: Jag är förövrigt sjukt känslig när det gäller väntetid när jag jobbar

VS Code har redan ARM64 stöd, så ur det perspektivet fungerar det ju.

Däremot finns ju idag ingen klientriktad ARM krets som är kraftig nog att matcha Intels U-serie CPUer. Så idag är svaret: nej, det finns ingen tillräckligt kraftig ARM för ditt fall. Och givet att VS numera känns som sirap även på x86 (vilket inte är fallet för VS Code), så lär du knappast vilja köra på dagens Snapdragon 835 baserade laptops

Men är ju precis det ARM har som mål att ändra på med en satsning specifikt mot laptops.

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:

VS Code har redan ARM64 stöd, så ur det perspektivet fungerar det ju.

Däremot finns ju idag ingen klientriktad ARM krets som är kraftig nog att matcha Intels U-serie CPUer. Så idag är svaret: nej, det finns ingen tillräckligt kraftig ARM för ditt fall. Och givet att VS numera känns som sirap även på x86 (vilket inte är fallet för VS Code), så lär du knappast vilja köra på dagens Snapdragon 835 baserade laptops

Men är ju precis det ARM har som mål att ändra på med en satsning specifikt mot laptops.

äh, kör en 2700x 16 gig ram och nvme på jobbdatorn och resharper. Funkar galant även i vår fetingstora solution.
Har tom installerat en del resharper plugins som deras allocation visualizer.

Visa signatur
Permalänk
Avstängd
Skrivet av Yoshman:

64-bitars ARM är en helt ny ISA. De ARM processorer som stödjer både 32-bitars och 64-bitars kod implementerar i praktiken två separata ISA. Allt fler ARM processorer börjar droppa 32-bitars stödet, det gäller framförallt de mer avancerade modeller.

Det är sig intressant därför 32-bitars ARM designades på 80-talet och innehåller precis som x86 en rad beslut som var en bra idé när de introducerades men kan idag agera ankare och minska den potentiella enkeltrådprestanda som är möjlig att uppnå.

64-bitars ARM designades lanserades 2010 och är en väldigt "ren" ISA som bl.a. möjliggör högre s.k. ILP (Instruction Level Parallelism). Hög ILP ger hög "IPC" (instructions per clock), d.v.s. det gör det möjligt att skapa en design som kan få väldigt fin prestanda per kärna.

64-bitars ARM har också en perfekt match mot de primitiver som behövs för att kunna synkronisera data mellan CPU-kärnor, x86 är på denna punkt onödigt strikt -> synkronisering är dyrare än vad det optimalt skulle behöva vara.

Så anser ARM64 vara överlägsen x86-64.
Vad anser du om RISC-V? Är RISC-V bättre än ARM64, eller är båda så moderna att det inte är någon skillnad?
Vad anser du om POWER, SPARC och DEC Alpha?
Och hade Itanium potential, kunde de ha blivit något, eller var det bara dömt att misslyckas?
Eller var Itanium rätt väg att gå men något som tyvärr spårade ut?

Skrivet av Yoshman:

Med DynamIQ kan man ha en CPU med två väldigt feta och rätt strömtörstiga CPU-kärnor. OS-et ser till att lägga alla interaktiva applikationer där (OS schedulers klassificerar redan idag program som batch alt. interaktiva beroende på hur de uppför sig). Bakgrundsapplikationer och batch-körningar i bakgrunden kan man i stället lägga på 6 betydligt enklare och lite lägre klockade kärnor (en "modul" i Dynamic kan ha max 8 kärnor).

Är DynamIQ något du bara anser är fördelaktigt på processorer för mobiler, plattor och laptops, eller är det något som skulle vara fördelaktigt även på desktop, workstation och servrar?

Permalänk
Inaktiv
Skrivet av CyberVillain:

Funkar VS Code bra på arm? Och då menar jag på enterprise stora projekt. För att det ska gå jobba på VS krävs det 16 gig ram och minst en i7 med bra singel core perf och 8 trådar. Men då kör jag resharper och den är en känd perfomanc hogger. Sedan så ska man inte glömma att en bra disk gärna nvme är viktigt.

edit: Jag är förövrigt sjukt känslig när det gäller väntetid när jag jobbar

Jobba mot en terminalserver och saken är fixad. Visst lite svårt med hög IO, men samtidigt ett bra utvecklingsplattform kan man jobba lite mer professionellt med bygg/testservrar och dylikt som går i bakgrunden.
Sedan sämre IO emot ssdn så har man bättre bandbredd emot databaserna och annat som ens applikation använder. Såvida man nu inte har en släpbar workstation med sig överallt och jobbar på.

Jag tror som sagt på att marknaden för Arm-laptops som är riktigt ultratunna, billiga och som startar på ett ögonblick är stort. Ser man historisk så har priset på övriga hårdvara varit ett problem och dessa datorer har nästan kostat lika mycket som en x86. Men nu är fullhd på en 13" inget dyrt, en liten ssd + nödvändigt ram inte detsamma.

Sedan passar dessa Arm datorer inte alla, vissa tar med deras laptop till en avskärmad bunker och jobbar och då behöver ha en släpbar workstation. Men generellt och för den stora skaran så tror jag mycket på ARM i deras laptops.

Permalänk
Avstängd

@anon159643: Har inte alltid internet, tex på flyget, men visst remota in är inte fel. Mins en sommar när jag fortfarande var anställd. Helt dött på kontoret, jag valde att ta med mig laptopen till landet och en liten 3G dongle. Självklart kom det in värsta supportärendet som krävde deploy. Det var så kass mottagning så jag fick gå upp på ett berg bakom huset för att få så pass bra hastighet att det gick jobba remote

Visa signatur
Permalänk
Medlem
Skrivet av lasseTM:

Det står ju single thread i grafen

Skrivet av Findecanor:

För prestandad jämfördes det per kärna, men för strömförbrukningen jämfördes hela chippet. Jag vill veta hur många kärnor ARM-chippet har och i vilken konfiguration. ARM-chip för t.ex. mobiltelefoner brukar ha både snabba och långsamma kärnor.
Sen tror jag inte att det finns någon ARM-kärna som stödjer flera trådar per kärna. ARM-system brukar istället ha fler kärnor.

Nja... Viktigt att läsa finstilta här:
"Single-core performence based on SPECINT2k6, Intel meadured, Arm Compute estimated"
"Graph not to scale".

Så... detta är vad det i ett visst program, "beräknas" de ska nå... vs vad Intel faktiskt uppmätt. Och vi har ingen aning om vad för skala vi pratar om. De kan ha flyttat runt detta precis som man gör i Photoshop.

Hade man haft konkret slam-dunk prestanda, hade man visat detta också. Detta är mer PR gänget som suttit en vecka extra på eftermiddagen och gjort något snyggt, som ändå är ramen av "lagligt".

Med det sagt, ja, visst har Arm bättrat sig, och ja.. om Intel dröjer till slutet på 2019 innan 10nm lanseras som de sagt, har även de en chans att komma ikapp lite.

Permalänk
Medlem
Skrivet av CyberVillain:

@Johan86c: Har inte alltid internet, tex på flyget, men visst remota in är inte fel. Mins en sommar när jag fortfarande var anställd. Helt dött på kontoret, jag valde att ta med mig laptopen till landet och en liten 3G dongle. Självklart kom det in värsta supportärendet som krävde deploy. Det var så kass mottagning så jag fick gå upp på ett berg bakom huset för att få så pass bra hastighet att det gick jobba remote

Så då är frågan... var det bättre att vara på berget och fixa problemet, eller på kontoret där naturligtvis, enligt murphys law, inget hade hänt... och du dött av uttråkning istället?

Permalänk
Inaktiv
Skrivet av CyberVillain:

@Johan86c: Har inte alltid internet, tex på flyget, men visst remota in är inte fel. Mins en sommar när jag fortfarande var anställd. Helt dött på kontoret, jag valde att ta med mig laptopen till landet och en liten 3G dongle. Självklart kom det in värsta supportärendet som krävde deploy. Det var så kass mottagning så jag fick gå upp på ett berg bakom huset för att få så pass bra hastighet att det gick jobba remote

Berättelser har vi alla. Jag åkte med ett tåg kass mottagning, en kund ringer in ett riktigt akut supportärende. Så jag fick hoppa av på första bästa station mitt i ödemarken och när jag bara kom ur tåget så fungerade det.
Sedan hur tusan tar jag mig härifrån var nästa problem? Där inget tåg gick inom flera timmar så jag fick beställa en taxi och skicka taxiräkningen till kund.

Nu var jag både inne på en utvecklingsterminalserver och skarp, om vi bortser från att jag behövde använda in på skarp server. Så om inte terminalservern hade funnits så hade det ändå varit kört, såvida jag inte hade haft en 50TB ssd i min laptop med all data på som ständigt synkroniseras emot det senaste. Datan jag behövde var inte 50TB, men man vet aldrig exakt vilken data man behöver.
Säkerhetsrisk att ha precis all data från alla kunder på sin laptop? Nä..

Så det är svårt att inte vara beroende av internet. Nå när jag pratar om Arm-laptops tänker jag på den stora skaran.
Där jag upplever att de flesta använder en webbläsare, ett ordbehandlingsprogram, en bildredigerare (nej inte Photoshop utan windows egna) och sist en filhanterare.
Det är typ det många gör med datorn och att köpa en komplett x86 med windows laptop för detta känns så fel. Visst deras stationära i hemmet kanske de vill göra annat som att spela tyngre spel, redigera filmer etc. Men riktigt billiga och supersnabba laptops tror jag skulle sälja. -Supersnabb på att starta och för det de gör vid datorn.

Permalänk
Datavetare
Skrivet av rektor:

Så anser ARM64 vara överlägsen x86-64.
Vad anser du om RISC-V? Är RISC-V bättre än ARM64, eller är båda så moderna att det inte är någon skillnad?
Vad anser du om POWER, SPARC och DEC Alpha?
Och hade Itanium potential, kunde de ha blivit något, eller var det bara dömt att misslyckas?
Eller var Itanium rätt väg att gå men något som tyvärr spårade ut?

Är DynamIQ något du bara anser är fördelaktigt på processorer för mobiler, plattor och laptops, eller är det något som skulle vara fördelaktigt även på desktop, workstation och servrar?

Skulle inte kalla det överlägset, de flesta av tillkortakommandena i x86 kan lösas genom att slänga fler transistorer och mer ström på problemet. Däremot verkar vi snabbt närma oss vägens ände på "Moores lag", kommer man till läget att man måste hushålla med de transistorer som finns så kommer det börja bli en större fördel med bättre ISA.

Men sett till detaljer så har ARM64 (Aarch64) en högre potential att t.ex. skala med CPU-kärnor och ge hög IPC. Det handlar dock inte om heltalsfaktorer, det handlar kanske om 10-30 %. Men skulle någon säga nej till 20 % högre IPC över Skylake?

Om jag fick önska något i CPU-världen är det att RISC-V kommer ta världsherraväldet inom kort. Men det lär knappast hända, dock har bl.a. Nvidia (kontroll CPU i alla deras GPUer) och Western Digital (diskkontroller) börjat använda RISC-V.

Så vad är bra med RISC-V? Det är helt öppen och fri ISA specifikation som har samma tekniska fördelar som 64-bitars ARM (som är allt annat än öppen, Aarch64 kontrolleras med järnhand av ett enda företag).

POWER: efter ARM64 och RISC-V den bäst designade ISAn. Får se om det kommer något gått ur OpenPOWER. Vilket är rätt imponerande givet hur länge sen det var IBM designade POWER, de visste vad de gjorde!

SPARC är i praktiken död.

DEC Alpha är på alla tänkbara sätt död och skulle inte vara en speciellt bra ISA idag då flaskhalsarna har flytta på sig så man löser fel problem där (vilket även gäller SPARC).

Itanium var dömt att misslyckas. Fast det gick inte att veta på förhand då i praktiken krävdes ett genuint försök där man lade mycket resurser på att utveckla kompilatorer och CPU-arkitekturen. Det misslyckades då flaskhalsarna man primärt siktade dels flyttade på sig en del p.g.a. utvecklingen men också p.g.a. att man underskattade värdet av statisk kodanalys kontra dynamisk analys.

Itanium var ju tänkt att spara transistorer på att låta kompilatorn göra massiv mängd statisk analys och därifrån skulle man få hög IPC. Tanken vad god då man slipper göra mycket av analysen i runtime (kostar massor med transistorer och ström), men det fallerar på att dynamisk analys har mer information i form av hur data som hanteras råkar vara befattat för stunden. Nu har ju all spekulation man för i dynamisk analys gett oss Spectre/Meltdown problem, men dessa kommer kunna lösas och de optimeringar man kan göra dynamisk blir allt mer kritiskt ju mer CPU-kärnorna blir beroende av cache då RAM har för hög latens och låg bandbredd (bandbredd går i.o.f.s. att fixa med fler minneskanaler, latens går inte att fixa).

Skulle säga att DynamIQ har bara har ett större värde så långe som TDP är en stor flaskhals. Så det är främst relevant för bärbara enheter. Vi ser ju inte alls samma delta mellan maxfrekvens och "all-core" frekvens på desktop CPUer, trots att mainstream nu har 6-8 kärnor. Backar man ett par år såg vi däremot att E-seren i många fall var en sämre desktop CPU för den stora massan just då man fick skära lite väl mycket i enkeltrådprestanda, det har man nu kommit runt (ryktet säger ju att i9-9700K/9900K ska hålla 4,7 GHz all-core-turbo, får se om det stämmer).

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

Så då är frågan... var det bättre att vara på berget och fixa problemet, eller på kontoret där naturligtvis, enligt murphys law, inget hade hänt... och du dött av uttråkning istället?

hehe, garanterat bättre på berget. Det var ju roligt att få skiten fungera. En annan gång hissade jag upp mobilen i flaggstången med hotspot enabled. så kunde jag köra wifi från laptopen Men nu är det bra 4G+ motagning i området så måste installerats ny mast eller så

Visa signatur
Permalänk
Datavetare
Skrivet av CyberVillain:

@Johan86c: Har inte alltid internet, tex på flyget, men visst remota in är inte fel. Mins en sommar när jag fortfarande var anställd. Helt dött på kontoret, jag valde att ta med mig laptopen till landet och en liten 3G dongle. Självklart kom det in värsta supportärendet som krävde deploy. Det var så kass mottagning så jag fick gå upp på ett berg bakom huset för att få så pass bra hastighet att det gick jobba remote

Så dra in fiber på landet, problem löst

Sett till kapacitet mot internet gäller det för mig: landet > hemma > kontoret. Så får nog undvika kontoret när det behövs fet internetkapacitet

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:

Så dra in fiber på landet, problem löst

Sett till kapacitet mot internet gäller det för mig: landet > hemma > kontoret. Så får nog undvika kontoret när det behövs fet internetkapacitet

Faktum är att vi fick det förra året. Dock inte ansluten. Borde finnas någon lev där man kan få det typ under sommarmånaderna bara

Visa signatur
Permalänk
Medlem
Skrivet av Yoshman:

Så dra in fiber på landet, problem löst

Påminner mig om en "allvarlig sak" (som han sa det iaf) som IT teknikern på min gamla gymnasieskola sa när vi klagade på att hela skolan delade på en 64-kbit ISDN.

"Om ni bara vill gräva fram till stadsnätet så ser jag till att lägga dit en ordentlig kabel..."

Gissar på att han var lite trött på att få den kommentaren och inte kunde göra något åt det själv.
Detta var dock en tid då inte alla hade datorn hemma heller, så skolans dator/internet access var faktiskt viktig.

Permalänk
Avstängd
Skrivet av Yoshman:

Om jag fick önska något i CPU-världen är det att RISC-V kommer ta världsherraväldet inom kort. Men det lär knappast hända, dock har bl.a. Nvidia (kontroll CPU i alla deras GPUer) och Western Digital (diskkontroller) börjat använda RISC-V.

Anser du RISC-V vara en bättre arkitektur än AArch64?

Tror du på CISC, RISC, VLIW eller EPIC?

Varför har vi inte sett flera asynkrona CPUer än AMULET?

Permalänk
Datavetare
Skrivet av rektor:

Anser du RISC-V vara en bättre arkitektur än AArch64?

Tror du på CISC, RISC, VLIW eller EPIC?

Varför har vi inte sett flera asynkrona CPUer än AMULET?

Jag anser nog att RISC-V är en marginellt bättre arkitektur jämfört med Aarch64. De är extremt snarlik, enda relevanta skillnaden jag kan se är att RISC-V har "komprimering" av instruktioner vilket ger högre effektivt cache-utnyttjade mot en lite mer komplicerad front-end.

ARM hade det för 32-bitars ARM, men valde att skippa stödet för Aarch64. Så jag kan ha fel, är definitivt ingen CPU-designer (är mitt jobb som RTOS/embedded-programmerare kräver väldigt god förståelse för mikroarkitektur, så är mer ett nödvändigt ont som jag råkar tycka är rätt intressant).

CISC/RISC är en hyfsat irrelevant distinktion idag. Skulle i stället göra klassificeringen ren load/store arkitektur (d.v.s. beräkningar kan bara ske mot register, aldrig direkt mot minne) eller ej. Där är jag övertygad om att rena load/store arkitekturer är bättre då alla CPU-designer jag känner till som gjorts på senare tid använde det.

De rena RISC:arna hade ju fixerad storlek på instruktionerna och saknade rätt normala saker som mul/div operationer. Med en sådan definition blir ju varken RISC-V (instruktioner kan vara 2 eller 4 byte) eller Aarch64 (ARM har alltid haft väldigt CISC-lika funktioner för minnesoperationer samt stöd för rätt avancerade instruktioner) en RISC. Båda är rena load/store arkitekturer medan x86 inte är det.

VLIW och EPIC verkar bara fungera bra inom rätt smala nischer. I det läget är det väldigt energieffektivt. Men verkar inte vara rätt teknik för en CPU som ska vara väldigt bred och generell.

En asynkron CPU-design lär ge rätt höga latensen då man lär behöva ha köer mellan olika delar för att hantera det faktum att det inte finns en central klockpuls som allt är synkroniserat mot (åter igen, kan ha missförstått exakt vad grejen med asynrona CPUer är men så har jag uppfattat det hela).

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:

Så vad är bra med RISC-V? Det är helt öppen och fri ISA specifikation som har samma tekniska fördelar som 64-bitars ARM (som är allt annat än öppen, Aarch64 kontrolleras med järnhand av ett enda företag).

Uhm, det där är inte riktigt sant, beroende på hur man ser på saken.
ARM erbjuder arkitekturlicenser, som tillåter inte bara att man implementerar Aarch64 som man vill, utan man kan också göra tillägg osv.
Alla de stora (Apple, Qualcomm, Samsung, Broadcom, nVidia ...) har en sådan licens.

Deras designer måste naturligtvis kunna köra Aarch64 kod, någon jävla ordning måste det vara med en ISA! Och ja, det är ARM (i praktiken i samråd, men ändå) som spikar den. Men när väl det baskravet är uppfyllt är det fritt fram.

Förhoppningsvis kommer mobilindustrin helt överge tidigare versioner, så att de slipper ta hänsyn till gammalt bagage i nya implementationer, ett steg som är mycket svårare och kanske i praktiken omöjligt för x86 processorer. Apple, som kontrollerar hela stacken och är starka nog att kräva att mjukvaruutvecklare stödjer Aarch64 för att kunna sälja sin programvara, har en stor fördel framåt. Knepigare för Google och Android. Och som sagt, nästan omöjligt för x86 marknaden.

Permalänk
Medlem
Skrivet av anon159643:

Framtiden är webbläsardatorer och tunna klienter.

Arm är en väldigt bra grund att bygga såna datorer på som varesig är dyra eller strömtörstiga.

Så jag ser fram emot dem. Windows på en laptop känns för väldigt många som ett överdrivet operativsystem för vad de gör. Jag tänker såklart på chromebook, men även små installationer av linux dist.

Nu när snart 5G är på gång så ser jag detta som mer självklart.

Skickades från m.sweclockers.com

Kör Windows i S-mode så har du samma sak.

Ser själv fram emot ARM på bärbara. Tror detta kan bli grymt intressant!

Visa signatur

macOS: MacBook Air 13" [M1/16/256GB], MacBook Pro 16" [M2/32/512GB], iOS: iPad Mini [128GB/LTE], iPad Pro 12,9" [M1/512GB/LTE], iPhone SE3 [128GB], Apple Watch Series 6 44mm [LTE], W10: Surface Book 3 15" [Core i7/GTX1660Ti/32/512GB], LG 77" OLED C2 [OLED77C25LB]
The purpose of morality is to teach you, not to suffer and die, but to enjoy yourself and live. --Ayn Rand
Skriv under ett upprop för en grönare energipolitik: https://energiupproret.se/

Permalänk
Medlem
Skrivet av Aleshi:

De jämför med dualcores. Gissningsvis har de minst det dubbla antalet kärnor och anger flertrådad prestanda.
Sedan tycker jag det hela är fult. Risken är rätt stor att kunder köper datorerna i tron om att de kan köra vanliga datorprogram.

Microsoft är väl nöjda. Det är ett steg närmare att man klipper kompatibilitet med gamla öppna program och att alla övergår till deras mer låsningsbara ekosystem.

?

Du menar till skillnad från iOS, macOS, Chrome OS, Android, Sony PS, Xbox och Nintendo?

Visa signatur

macOS: MacBook Air 13" [M1/16/256GB], MacBook Pro 16" [M2/32/512GB], iOS: iPad Mini [128GB/LTE], iPad Pro 12,9" [M1/512GB/LTE], iPhone SE3 [128GB], Apple Watch Series 6 44mm [LTE], W10: Surface Book 3 15" [Core i7/GTX1660Ti/32/512GB], LG 77" OLED C2 [OLED77C25LB]
The purpose of morality is to teach you, not to suffer and die, but to enjoy yourself and live. --Ayn Rand
Skriv under ett upprop för en grönare energipolitik: https://energiupproret.se/

Permalänk
Datavetare
Skrivet av EntropyQ3:

Uhm, det där är inte riktigt sant, beroende på hur man ser på saken.
ARM erbjuder arkitekturlicenser, som tillåter inte bara att man implementerar Aarch64 som man vill, utan man kan också göra tillägg osv.
Alla de stora (Apple, Qualcomm, Samsung, Broadcom, nVidia ...) har en sådan licens.

Deras designer måste naturligtvis kunna köra Aarch64 kod, någon jävla ordning måste det vara med en ISA! Och ja, det är ARM (i praktiken i samråd, men ändå) som spikar den. Men när väl det baskravet är uppfyllt är det fritt fram.

Förhoppningsvis kommer mobilindustrin helt överge tidigare versioner, så att de slipper ta hänsyn till gammalt bagage i nya implementationer, ett steg som är mycket svårare och kanske i praktiken omöjligt för x86 processorer. Apple, som kontrollerar hela stacken och är starka nog att kräva att mjukvaruutvecklare stödjer Aarch64 för att kunna sälja sin programvara, har en stor fördel framåt. Knepigare för Google och Android. Och som sagt, nästan omöjligt för x86 marknaden.

Är helt med på att de företag du listar har den dyrare formen av ARM-licens som tillåter dem designa sin egen mikroarkitektur medan de flesta kina-tillverkare använder sig av den billigare ARM-licensen där man köper mikroarkitekturen från ARM (Cortex A serien för mobiler och liknande).

Men det ARM kontrollerar med järnhand är ju ISA, man får självklart implementera sin mikroarkitektur hur man vill om man har en sådan licens.

Kan i alla fall inte hitta att t.ex. Apples A11 skulle ha några instruktioner utöver de som beskrivs i ARMv8-A. Har också lite svårt att se hur någon skulle kunna stoppa in egna instruktioner då ARM styr alla instruktioners binära format. Lägger man in något själv finns ju en hyfsat stor risk att det kommer kollidera med framtida ARM-specificerade instruktioner.

Blir ju än märkligare på Android-sidan eftersom eventuella sådana utökningar skulle kräva en CPU-specifik kompilator. Vad jag vet har inte Qualcomm, Samsung och Nvidia någon egen ARM-kompilator (och Apple har också en standardkompilatorn då de kör med LLVM/clang, fast de har ett eget spår som de upstreamar ibland).

Självklart innehåller systemkretsar massor med funktioner i kisel som är specifikt för just den systemkretsen. Men det är ju minnesmappade I/O-enheter, d.v.s. det är att likställa med hur en PC kommunicerar med GPU, nätverkskort etc.

Även här är det ju så att RISC-V helt styr vilka instruktioner som finns och hur deras binärrepresentation ser ut. Så måste det ju vara för att kompilatortillverkare och liknande ska kunna utföra sitt jobb på ett vettigt sätt.

RISC-V har däremot avsatt ett utrymme för egna utökningar. De kan självklart kollidera med andras utökningar, men det kommer inte kollidera med framtida RISC-V instruktioner. Råder lite delade mening om sådant är bra eller ej, risken är att sådana saker fragmenterar plattformen då ett givet program kanske inte kan köras på många implementationer.

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 de företag du listar har den dyrare formen av ARM-licens som tillåter dem designa sin egen mikroarkitektur medan de flesta kina-tillverkare använder sig av den billigare ARM-licensen där man köper mikroarkitekturen från ARM (Cortex A serien för mobiler och liknande).

Men det ARM kontrollerar med järnhand är ju ISA, man får självklart implementera sin mikroarkitektur hur man vill om man har en sådan licens.

Kan i alla fall inte hitta att t.ex. Apples A11 skulle ha några instruktioner utöver de som beskrivs i ARMv8-A. Har också lite svårt att se hur någon skulle kunna stoppa in egna instruktioner då ARM styr alla instruktioners binära format. Lägger man in något själv finns ju en hyfsat stor risk att det kommer kollidera med framtida ARM-specificerade instruktioner.

Blir ju än märkligare på Android-sidan eftersom eventuella sådana utökningar skulle kräva en CPU-specifik kompilator. Vad jag vet har inte Qualcomm, Samsung och Nvidia någon egen ARM-kompilator (och Apple har också en standardkompilatorn då de kör med LLVM/clang, fast de har ett eget spår som de upstreamar ibland).

Självklart innehåller systemkretsar massor med funktioner i kisel som är specifikt för just den systemkretsen. Men det är ju minnesmappade I/O-enheter, d.v.s. det är att likställa med hur en PC kommunicerar med GPU, nätverkskort etc.

Även här är det ju så att RISC-V helt styr vilka instruktioner som finns och hur deras binärrepresentation ser ut. Så måste det ju vara för att kompilatortillverkare och liknande ska kunna utföra sitt jobb på ett vettigt sätt.

RISC-V har däremot avsatt ett utrymme för egna utökningar. De kan självklart kollidera med andras utökningar, men det kommer inte kollidera med framtida RISC-V instruktioner. Råder lite delade mening om sådant är bra eller ej, risken är att sådana saker fragmenterar plattformen då ett givet program kanske inte kan köras på många implementationer.

Det är tveklöst vettigare att, om möjligt, implementera ny funktionalitet som något distinkt från CPU:ns egen instruktionsuppsättning framför allt av kompatibilitetsskäl. Det är vad vi har sett med video/grafik/audio/nätverk/inference engines/bildbehandling/whatever. Funktionaliteten accessas sedan via systemanrop. Det kan ju tänkas finnas instruktioner som av latensskäl kanske finns anledning att bädda in i instruktionsuppsättningen så som man gjorde med t.ex. AES-NI i x86 (bland annat). En tillverkare som Apple, och kanske bara de, kan göra som de vill.

Angående fragmentering så används RISC-V och ARM på en massa olika ställen, och om hypotetiskt Broadcom designar en krets som skall användas i routrar kanske det inte är hela världen om den har ett par specialinstruktioner, kretsarna kommer ju aldrig att stoppas in i androidmobiler t.ex. och den kritiska firmwaren i produkterna kan produceras med en given kompilatorversion.

Skillnaden mellan ARM och RISC-V ligger väl egentligen mest i licensieringen av ARMs ISA. Där ARM drar in pengar och framför allt lägger ner en massa arbete är ju att konstruera de färdiga kretslösningar för givna litografiska processer som sedan licensieras av de tillverkare som inte vill/kan lägga ner resurser på att försöka producera något bättre än vad ARM redan erbjuder.

Ideologiskt är RISC-V trevligt och börjar få lite spridning, men skillnaderna är i praktiken kanske inte så stora. Om man kan designa sina egna kretsar erbjuder ARM stor frihet, och om man inte kan det serverar de färdiga lösningar. Det är inte konstigt att de dominerar. RISC-V är värt att hålla ögonen på, i synnerhet kanske för IOT, där man vill kunna stoppa in en superbillig liten krets i en brödrost, och där cutting edge litografi inte är så nödvändigt. Och, när jag tänker närmare på saken, i sensorer som nu börjar ha egen logik för att processa de stora datamängder de fångar upp direkt, för att sedan skicka behandlade data vidare, vilket reducerar både belastning på mottagande processor, och minskar kostnaderna för datatrafik.