Apples ARM-datorer får USB 4 år 2022

Permalänk
Datavetare
Skrivet av kelthar:

All min kod som jag skriver i .Net kan jag köra lite vart jag vill. På en raspberry, windows server eller något annat. ARM eller X86.

Riktigt så enkelt är det tyvärr inte. "Vanliga" .Net är fortfarande bundet till Windows/x86, men antar att du refererar till dotnet core här.

Dotnet core för Windows stödjer inte Aarch64, utan man stödjer endast 32-bitars ARM och det endast för en extremt nedskalad version av Windows server.

Under Linux stödjer dotnet core 3.1 x86, x64, ARM och Aarch64. OK stöd, men långt ifrån att "köra på vad som helst" då man saknar stöd för MIPS, PowerPC etc.

Testade dotnet core på ett av mina Aarch64 Linux system genom att testa flera av benchmark game fallen. Fungerade sådär... Prestanda var ingen höjdare och just då .Net är så extremt associerat med x86/Windows var det flera exempel som fallerade då de förutsatte saker som bara är sant på x86. Det är långt mer ett .Net problem än ett Aarch64 problem då motsvarande problem inte alls finns om man kör Java, Rust eller C++.

Microsoft har även mer grundläggande problem med Aarch64 stödet. Det är ungefär ett halvår sedan Surface Pro X lanserades, ändå saknas fortfarande ett native MS Office (det trots att man redan har 32-bitars ARM stöd för MS Office), Windows 10 Pro saknar stöd Hyper V stöd på Aarch64 (men det är på gång, så om något år kanske det Windows har helt OK Aarch64 stöd).

WLS2 saknas just nu både för Aarch64 och x64, så det är ju inte ARM problem. Med HyperV och/eller WSL2 stöd kan faktiskt Surface Pro X bli någorlunda användbar, detta då man med dessa får ett vettig Linux stöd där native Aarch64 stödet är lysande!

x86 kommer leva väldigt länge, det just för att Windows (och även .Net) är så extremt bundet till x86. Möjligen blir just detta Windows fall, i "molnet" är Windows redan nu irrelevant. Windows är fortfarande totalt dominant som desktop OS och spel OS, det lär nog inte ändras i närtid... MacOS är dock i en långt bättre position att hantera en annan CPU-arkitektur, Linux är sedan länge redan där.

Skrivet av Mordekai:

Många gånger har det talats om detta steg, Intel försökte själva med IA64, hittills har det inte varit ekonomiskt hållbart. Är det denna gång det första gången lyckas?

IA64 fallerade inte p.g.a. av ekonomi, det fallerade av samma orsak som majoriteten av alla försökt till "utveckling" faller på: det visade sig vara en design som hade vissa fördelar, men på det stora hela övervägde nackdelarna.

Intel gjorde egentligen allt rätt med IA64. Man insåg redan på 1990-talet att x86 passerat sitt bäst-före-datum. Intel kikade på vad spjutspetsforskningen ansåg vara vägen framåt för CPU-design, vid den tidpunkt IA64 designades var detta VLIW/EPIC.

VLIW var bra på vissa saker, IA64 fungerade faktiskt riktigt bra för de flesta flyttalsintensiva applikationer. Tyvärr visade sig VLIW vara en riktigt usel idé för generella heltalsberäkningar, det är 90+% av alla program vi kör på skrivbordet. IA64 var en dålig design som generell CPU, så designen dog p.g.a. tekniska orsaker inte ekonomiska.

AMD hade ju framgångar med VLIW en tid, deras VLIW-baserade GPUer var mer effektiva jämfört samtida Nvidia. Men när trenden gick mot allt mer generella beräkningar havererade VLIW-tekniken även där.

Aarch64 och RISC-V är också resultat av att följa de senaste forskningsrönen. Intel blev rejält bränd av IA64 fadäsen och många verkar hålla med dem i tron om att det enda som spelar roll är mikroarkitektur, x86 ISA är inget problem. Det var i praktiken sant under lite mer än ett decennium, men allt pekar på att den riktning forskningen nu tagit och som anmanats av Aarch64 och RISC-V faktiskt har massor med fördelar. Det specifikt generell heltalsprestanda där Apples CPUer totalt demolerar high-end x86 i prestanda per CPU-cykel, så denna gång verkar man faktiskt hittat relevant fördelar (som x86 inte kan implementera utan att bryta bakåtkompatibilitet).

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:

Riktigt så enkelt är det tyvärr inte. "Vanliga" .Net är fortfarande bundet till Windows/x86, men antar att du refererar till dotnet core här.

>Gamla< .Net :), inte vanliga. Vi använder endast det ifall man skall använda något ramverk som inte hunnit portas till .Net core än. Som t.ex något CMS eller liknande. Vi bygger allting i .net core.

Skrivet av Yoshman:

Dotnet core för Windows stödjer inte Aarch64, utan man stödjer endast 32-bitars ARM och det endast för en extremt nedskalad version av Windows server.

Under Linux stödjer dotnet core 3.1 x86, x64, ARM och Aarch64. OK stöd, men långt ifrån att "köra på vad som helst" då man saknar stöd för MIPS, PowerPC etc.

Hela denna diskuttionen handlar om att programmera platformsoberoende och .Net är ett exempel. Det är ett väldigt nytt språk i jämförelse med t.ex C/C++. Där man har kunnat kompilera på flera plattformar länge. Att Microsoft har satt sin egen riktning för plattformsoberoende är den centrala punkten här och att utvecklare som inte skriver plattformsoberoende kod där de kan är slarviga och dåliga i min syn. Som du säger så har .net stöd för Aarch64, men inte i Windows på ARM.

"Vad som helst" är fel ordval av mig. Det är en för bred term. Det är för att jag endast sysslar med Windows och Linux. MIPS / PowerPC är för mig väldigt exotiskt, så det slipper jag ta hänsyn till. Är det vanligt för dig?

Skrivet av Yoshman:

Testade dotnet core på ett av mina Aarch64 Linux system genom att testa flera av benchmark game fallen. Fungerade sådär... Prestanda var ingen höjdare och just då .Net är så extremt associerat med x86/Windows var det flera exempel som fallerade då de förutsatte saker som bara är sant på x86. Det är långt mer ett .Net problem än ett Aarch64 problem då motsvarande problem inte alls finns om man kör Java, Rust eller C++.

Microsoft har även mer grundläggande problem med Aarch64 stödet. Det är ungefär ett halvår sedan Surface Pro X lanserades, ändå saknas fortfarande ett native MS Office (det trots att man redan har 32-bitars ARM stöd för MS Office), Windows 10 Pro saknar stöd Hyper V stöd på Aarch64 (men det är på gång, så om något år kanske det Windows har helt OK Aarch64 stöd).

WLS2 saknas just nu både för Aarch64 och x64, så det är ju inte ARM problem. Med HyperV och/eller WSL2 stöd kan faktiskt Surface Pro X bli någorlunda användbar, detta då man med dessa får ett vettig Linux stöd där native Aarch64 stödet är lysande!

Jepp, de har lagt sina hitintills investerade timmar där communityn verkar ha velat ha det mest och där det har gjort störst genomslagskraft. Plus lågt hängande frukter kanske. Det är definitivt en process i väldigt många steg. Jag hade inte velat rota igenom deras digra bibliotek av kod :).

Skrivet av Yoshman:

x86 kommer leva väldigt länge, det just för att Windows (och även .Net) är så extremt bundet till x86. Möjligen blir just detta Windows fall, i "molnet" är Windows redan nu irrelevant. Windows är fortfarande totalt dominant som desktop OS och spel OS, det lär nog inte ändras i närtid... MacOS är dock i en långt bättre position att hantera en annan CPU-arkitektur, Linux är sedan länge redan där.

Ja, Linux är helt dominerande i molnet! I like! Men vad är det nu tänker på när du säger att .Net är extremt bundet till x86? Tänker du på MSIL, CLR, JIT eller vad? Eller menar du gamla .net?

Visa signatur

Hur många datorer är för många?

Permalänk
Medlem
Skrivet av Det Otroliga Åbäket:

När jag skrev plattform menade jag Windows.

Du har helt rätt i att de under några år nu kämpat hårt för att bli mindre Windowsberoende, men bland oss som inte har lyxen att börja från scratch med en nyskriven produkt framtagen av framåtblickande arkitekter är inte sällan även de mest moderna produkterna skrivna i .Net Framework och behöver i Nådens år 2020 manuell handpåläggning för att stödja decenniegamla "moderniteter" som TLS 1.2. "Nya" .Net (det som hittills kallats Core) har stora fördelar vid portning, men är inte det vanligaste du hittar i existerande projekt. Det är ju typ nu det börjat uppnå vad man skulle kunna kalla feature parity med sin legacykusin. Och ärligt talat: Detta är garanterat en av förklaringarna till att Windows på ARM av många betraktats som hopplöst hittills: Inte ens Microsofts egna nyttoprogram har ju funnits i native-versioner utan har behövt emulera x86. Det har helt uppenbart inte varit en "enkel" fråga om att kompilera om efter att ha portat kompilatorn till den nya plattformen, om man säger så.

Där har ju Apple haft fördel av att redan från början ålägga utvecklare på deras plattformar betydligt striktare regler för att få vara med och leka. Legacyprogramvara på deras operativsystem slutar helt enkelt funka och kan inte längre säljas på plattformens officiella marknad om dess utvecklare ignorerat ett par års varningar i Xcode (assisterat av GUI-varningar till slutanvändare att detta kommer att ske)

Nej, det har mycket att göra med kvalitéen på utvecklare tror jag. Vissa är tog en utbildning i programmering bara för "att det är ett bra jobb" och andra har programmerat sedan de var barn och älskar det från djupet av sitt hjärta.

(Och sen så har vi hipster/javascript-utvecklarna. Jävla kodturister. Inte just att de använder javascript, utan kodlivscyklen som har funnits i det spacet under de senaste 5 åren. Dependencyhell.)

Jag portade allt som gick till .net core för länge sedan. Gamla .net känns som det smutsiga barnet med snorkråkor på kinden och jag förstår verkligen inte varför man inte följer med i tiderna. Om man inte vill förändras och utvecklas konstant, i hög fart, så är det bra om man undviker utvecklaryrket. Men det är så överallt, vissa nöjer sig med mindre och tycker att det är good enough och så finns det sinnessjuka människor som mig som tycker att det är sjukt viktigt.

Jag tycker om att du kallar det för legacykusin. Det värmer mitt hjärta. När jag funderar på det så är det vettigt som Apple har gjort, att tvinga utvecklare att uppdatera sina mjukvaror. Hur ofta har man inte hört talas om någon maskin som kräver ett styrprogram som kör över en parallelport som endast går att köra i DOS? Sitter och skrattar lite för mig själv.

Skrivet av Det Otroliga Åbäket:

Att man kan köra SQL Server på Linux: Jo, Microsoft har ju sitt "reverse Wine" som i princip skapar en API-brygga mellan applikationens Windowsanrop och det som behöver hända för att rätt sak ska anropas i Linuxkärnan. Tyvärr är DBA:er i min erfarenhet ofta lite mer konservativa än att de smäller upp en produktionsdatabas på en sån lösning.

Det kommer kanske med tiden. En snabb googling (har inte grävt) visar t.o.m att SQL Server har bättre prestanda på Linux. Med en API-brygga. Det blev jag faktiskt överraskad över.

https://www.dbbest.com/blog/running-sql-server-on-linux/
https://www.fhtino.it/blog/showpost.aspx?id=6790c78accb84f9c9...

Den bryggan påminner mig om att skriva plattformsoberoende kod. Abstraktioner för t.ex IO / HW för att man anropar olika saker på olika system. Medans den vanliga logiken är samma sak.

Visa signatur

Hur många datorer är för många?

Permalänk
Skrivet av kelthar:

Nej, det har mycket att göra med kvalitéen på utvecklare tror jag. Vissa är tog en utbildning i programmering bara för "att det är ett bra jobb" och andra har programmerat sedan de var barn och älskar det från djupet av sitt hjärta.

Väldigt sant. Desto mer frustrerande när folk i ledande ställning inte greppar detta basala koncept och istället verkar tro att man kan få fram en unge på en månad genom att sätta nio kvinnor på problemet...

Skrivet av kelthar:

Jävla kodturister.

Det uttrycket tänker jag sno skamlöst. 😆

Skrivet av kelthar:

Den bryggan påminner mig om att skriva plattformsoberoende kod. Abstraktioner för t.ex IO / HW för att man anropar olika saker på olika system. Medans den vanliga logiken är samma sak.

Japp - får hoppas framtida produkter skrivs med det i åtanke. Det är som sagt större chans för det under Nadella och med Azure+O365 som stor inkomstkälla än det var under Gates och Ballmer med specifikt Office på Windows som huvudinkomstbringare.

Permalänk
Datavetare
Skrivet av kelthar:

>Gamla< .Net :), inte vanliga. Vi använder endast det ifall man skall använda något ramverk som inte hunnit portas till .Net core än. Som t.ex något CMS eller liknande. Vi bygger allting i .net core.

Taget! Kommer kalla (och hoppas det stämmer i praktiken) allt som inte är dotnet core för "gamla .Net", är inte speciellt relevant längre då jag i princip uteslutande kör Linux för tillfället.

Skrivet av kelthar:

Hela denna diskuttionen handlar om att programmera platformsoberoende och .Net är ett exempel. Det är ett väldigt nytt språk i jämförelse med t.ex C/C++. Där man har kunnat kompilera på flera plattformar länge. Att Microsoft har satt sin egen riktning för plattformsoberoende är den centrala punkten här och att utvecklare som inte skriver plattformsoberoende kod där de kan är slarviga och dåliga i min syn. Som du säger så har .net stöd för Aarch64, men inte i Windows på ARM.

C#/.Net är inte precis ett "väldigt nytt" språk längre, det är trots allt 20 år gammalt. Ta t.ex. Go och Rust, som båda med fog kan kallas "ya språk", har redan stöd för långt fler CPU-arkitekturer. Folk kör ju Rust ända ned på 8-bitars mikrokontrollers (AVR), även om man det man har där självklart har en del kompromisser när det kommer till standardbiblioteket!

Skrivet av kelthar:

"Vad som helst" är fel ordval av mig. Det är en för bred term. Det är för att jag endast sysslar med Windows och Linux. MIPS / PowerPC är för mig väldigt exotiskt, så det slipper jag ta hänsyn till. Är det vanligt för dig?

MIPS är inte längre vanligt. PowerPC är på dekis, men det finns kvar en del då det var tidigare den dominerande CPU-arkitekturen i många realtidskritiska designer. ARM är på väg att ta över allt här, möjligen kan Kina rädda oss från total ARM dominans då RISC-V verkar ha ett väldigt stort intresse där (de vill ju inte sitta i knä på USA, så antar man kan tacka Trump för att RISC-V tagit fart...).

Skrivet av kelthar:

Jepp, de har lagt sina hitintills investerade timmar där communityn verkar ha velat ha det mest och där det har gjort störst genomslagskraft. Plus lågt hängande frukter kanske. Det är definitivt en process i väldigt många steg. Jag hade inte velat rota igenom deras digra bibliotek av kod :).

Ja, Linux är helt dominerande i molnet! I like! Men vad är det nu tänker på när du säger att .Net är extremt bundet till x86? Tänker du på MSIL, CLR, JIT eller vad? Eller menar du gamla .net?

De som designar dotnet core hos Microsoft vet definitivt vad de håller på med. Och just därför är det så tydlige att dotnet tyvärr blivit bundet till x86 då allt för många verkar idka copy-and-paste från stackoverflow...

Följande kod är i sig förhoppningsvis inte längre vanlig tack vare Lazy<T> och liknande, men det belyser klasser av buggar man identifierat i allt för många kodbaser för att kunna ignoreras. Så en av prestandafördelarna hos ARM (just detta fungerar lika även på t.ex. MIPS och PowerPC) leder här i stället till en prestandanackdel då dotnet-gänget i praktiken gjort en workaround likt Meltdown/Spectre, fast med värre prestandapåverkan

class LazyExample { private BoxedInt _boxedInt; int GetInt() { BoxedInt b = _boxedInt; // Read 1 if (b == null) { lock(this) { if (_boxedInt == null) { b = new BoxedInt(); b._value = 42; // Write 1 _boxedInt = b; // Write 2 } } } int value = b._value; // Read 2 return value; } }

Exemplet är inte ens korrekt på x86 enligt specifikationen, men det kommer tyvärr "fungera" i praktiken. Så på x86 kommer GetInt() alltid returnera 42, på ARM/Aarch64 skulle det kunna bli exakt vad som helst om inte dotnet-gänget applicerat sin workaround.

Den är att tvinga alla stores till statiska variabler (nog inget stort problem i praktiken) samt variabler som håller referenser i heap-allokerat minne (inte bra för t.ex. collections...) att föregås av en s.k. full fence (DMB instruktion, den är inte billig).

Andra exempel är att atomära variabler i C# implicit också är en "full fence". Det är alltid så på x86 (vilket för atomära variabler onödigt dyra där) medan det inte är sant på någon annan RISC än möjligen SPARC.

Just benchmark game är ju ett specialfall då folk slår knut på sig där för att göra den snabbaste tänkbara lösningen i sitt favoritspråk. Det har resulterat i att vissa C# lösningar använder sig av System.Runtime.Intrinsics.X86 (SSE/AVX). I sig inte dåligt om det inte vore för att man valde rätt sent att lägga till detta (tror det var 2017). Det är efter att Rust lanserats och där hade man till stor del lyckats lösa hur man på generell nivå bör designa saker så att kompilator (inte människor, människor är i genomsnitt idag rätt usla på att optimera för moderna CPUer då dessa har prestandaegenskaper som är allt annat är logiska för vår hjärna) kan välja SIMD optimeringar där det lämpligt.

Ställer man Rust lösningarna mot C# i dessa fall är den förra typiskt 2-5 gånger snabbare trots att C# använder sig av explicit SSE/AVX optimering, detta då kompilatorn gör motsvarande optimeringar för Rust vilket då även fungerar på Aarch64 (SIMD där kallas NEON).

Så att dotnet är så utbrett för backend-utveckling för Windows är bara en i raden av orsaker varför Windows är en allt sämre idé på serversidan/molnet. Det som Microsoft alltid gjort så rätt med dotnet är hur väl det fungerar med IDE:er, dotnet core + VS Code fungerar inte bara lysande på Windows, det gör det även på MacOS och Linux!

Visa signatur

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