Skrivet av Sveklockarn:
Min google-fu fick fram en del grejer åtminstone, och verkar existera såväl NOS som kloner. På den sortens system är ju moderkort med passivt bakplan en fungerande lösning också, så att man kan ta över nödvändiga ISA-kort relativt enkelt utan att behöva emulera dem.
Den bollen kan man nog dela ut på lite olika sätt, då det var AMD som var upphovet till att förlänga livet på x86. Nu säger jag inte att just IA-64 var framtiden, men x86-64 var säkerligen dödsstöten för de flesta samtida satsningar på att byta ut x86 mot något bättre.
Väldigt få kunder kommer dessutom att bry sig om huruvida olika problem löses på ett elegant sätt.
Lars-Gunnar, 63, som köper in all IT-utrustning bryr sig inte om huruvida arkitekturen har den "ultimata minnesmodellen" eftersom Excel redan fungerar, typ.
Helt sant. Intel blev inte dominant för att de satt på den bästa tekniska lösningen för en CPU, det hände dels genom lyckosamt samarbete med Microsoft ihop med att de hade något som var "tillräckligt bra" till ett lägre pris än andra.
Varför har x86 så kapitalt fallerat i mobiler? Primärt därför någon annan kunde erbjuda något som var "tillräckligt bra" (well, i det läget även bättre trots att Intel gjorde rejäla försök när de fortfarande hade världens bästa kretstillverkning) och till en betydligt bättre pris (x86 baserade SoC:ar var dyrare/krångligare).
Är därför ingen självklarhet att x86 kommer tappa sin dominas på skrivbordet, den är fortfarande "tillräckligt bra".
Det trista blir när man ser Arm vs AMD tillverka CPUer på samma TSMC-process och den förra kan designa ARM64 baserade designer som använder ~1/3 av transistornbudget/area för att nå samma prestanda/MHz. För oss kunder betyder det främst att vi nu betalar onödigt mycket för "tillräckligt bra".
Skrivet av Sveklockarn:
I mitten av 90-talet förväntade sig väldigt många att CPUer som Sun SPARC/MIPS Rxxxxx/DEC Alpha var framtiden, såpass mycket att Intel köpte stora delar av DEC i slutet av 90-talet i samband med att Compaq och sedermera HP köpte upp Compaq/DEC. Det var vad jag kan minnas även en enorm hype kring StrongARM, men såväl Intels egna (i860/i960) RISC-CPUer som StrongARM misslyckades att komma någonstans.
Jag får mest känslan av att historien upprepar sig med att någon uppfinner något nytt och elegant som sedan faller för olika praktikaliteter.
Jo, det problemet kommer man ju inte ifrån, jag tvivlar mest på kompetensen att förstå såna saker i en värld när det mesta är såpass annorlunda inom datorvärlden. Sen är det ju då även alla gamla styrkort och liknande prylar där den ursprungliga tillverkaren upplösts för flera decennier sedan, där känns det ju spontant som en enklare lösning att ha ett system som är designat för att t.ex. ha en ISA-buss från början.
Svårt att säga att ingen lyckats. Det säljs numera fler Arm-baserade CPUer per år än vad det sålts x86-baserade CPUer någonsin. Majoriteten av volymen är i.o.f.s. mikrokontrollers, en annan marknad Intel försökt sig på med x86 (Quark) som visade hur pinsamt dålig x86 är om man verkligen går efter maximal effektivitet och enkelhet.
Mikrokontrollers använder 32-bit Arm och lär fortsätta göra det under överskådlig tid. Inte alls säkert att ARM64 är rätt val där, vilket visar en annan sak: är nästan omöjligt att göra en design som är bra på allt. Det som gör 32-bit Arm lysande att bygga superenkla CPUer är samma egenskaper som i praktiken gör det omöjligt att bygga högpresterande kretsar på den ISAn (i det läget finns långt fler problem i 32-bit Arm än vad x86_64 någonsin haft).
Tittar man på de ISA som skapats och dött har ingen tidigare varit bättre på varje relevant punkt jämfört med x86, det samtidigt som Intel under 20-25 år kunder luta sig mot att kompensera eventuella brister med att ha bättre kretstillverkning än någon annan.
MIPS: var enkel, men saknar 32-bit Arms fördelar med exceptionell kompakt kod och "trick" som ger bra prestanda i "in-order" designer. Jämfört med både 32-bit Arm och x86 hade MIPS problem med låg koddensitet. "Smarta" tricket med delay-slots var en bra idé när man kunde hålla sig till en 5-stegs pipeline, men blev ett rejält misstag när frekvenserna började dra iväg
SPARC: samma problem som MIPS + "S" (scalable) delen var ju en väldigt bra idé så länge man kör enkeltrådade program som typ kör "för evigt". Rätt dålig idé om man har väldigt många OS-trådar som ofta kontext-switchar (att bygga CPUer med hundratals CPU-trådar löste inte grundproblemet)...
IA64: I grunden hade Intel rätt filosofi här, man titta på vad forskningen sa och gick all-in på det. Problemet var att VLIW var väldigt på ropet under den tiden. Fungerar bra på vissa nischer (Itanium var riktigt stark på vissa matematiskt tunga uppgifter), men VLIW har visat sig vara helt fel väg att gå för "generell heltalsintesiv kod" (vilket är majoriteten av vad vi kör på desktop/servers)
PowerPC/POWER: denna var/är i genomsnitt en klart bättre design jämfört med x86. Innan ARM64 dominerade PowerPC vissa nischer inom inbyggda system där man behöver relativt hög prestanda och låga svarstider (32-bit Arm var för klen för detta). Även här har folk försökt med x86 (i jakt på lägre pris), men det har generellt fungerat rätt dåligt. Idag dominerar ARM64 detta.
PowerPC hade ändå kunnat bli något om någon likt Intel pushat det och Microsoft verkligen anammat det. Intel kunde skjuta ned den satsningen primärt med överlägsen kiseltillverkning + PowerPC är inte direkt bättre än x86_64 på heltalsberäkningar.
ARM64 och RISC-V har inte bara "perfekt minneskonsistensmodell", de är också designade utefter att "ingen längre skriver assembler". Finns andra ISA som haft "smarta instruktioner", men dessa har i praktiken krävt just att man skriver assembler för att få ut något. ARM64/RISC-V är optimerade för att en kompilator ska kunna göra optimal kod!
Man lär sig nya saker hela tiden. Skillnaden nu mot 80/90-talet är att x86 är äldre och har nu fler kända defekter. Har faktiskt svårt att komma på en enda sak där x86 är bättre än ARM64/RISC-V, dessa producerar med moderna kompilatorer kompaktare kod än x86 (vilket historiskt varit en klar fördel för x86 mot alla RISC:ar förutom 32-bit Arm).
Fast som du skriver: dagens datorer är redan "tillräckligt bra", så inget kommer ändras om framförallt inte Windows pushar något annat än x86. Och ovanpå det lär man få endera billigare alt. snabbare system om man byter, blir spännande att se Qualcomms CPU under 2024 (ARM64 designad helt för Windows).
Skrivet av Mordekai:
Som sagt, AutoCad är en skog av applikationer för respektive disciplin, att kärnan nu äntligen finns till ARM64 betyder i sig väldigt lite för de flesta rent professionellt. För studerande är det ju dock grymt då man absolut klarar sig utan de specifika anpassningarna. Gissar att Architecture blir först eller redan är klart. EAGLE är väl också sannolikt högt upp i kön.
Kollar på mitt konto, på Windows har jag 48 appar att installera, på Mac fyra. Av de fyra är bara två, AutoCad och AutoCad LT kompilerade för ARM64. De två övriga är webbaserade. Av de 48 på Wintel är ju en del webbaserat också.
Mac och ARM är inte på långa väger ett bra val för ingenjörer eller tillverkande industri, det handlar inte om något år är min poäng. Alla dessa CAD/CAM-programvaror har add-ins som är mer eller mindre nödvändiga för respektive disciplin eller bransch. Vissa använder VBA, andra använder .Net för integrering, det finns python-bryggor/wrappers men de är ofta just .Net-applikationer.
Datorer för programmerare och IT-generellt har lite betydelse för stora delar av samhället, IT-branschen och dessa navelskådare är just orsaken till skolplattformar och andra kul IT-konsultprojekt av programmerare som inte förstår att verktyg skall fungera, inte för att en programmera skall få ribba över en ny processorarkitektur.
Arkitekturell CAD och som både Revit och Archicad har startats av arkitekter med programmeringskunskap, till skillnad från AutoCad exempelvis. Nästan alla vettiga add-ins startar med ett ingenjörsbehov, inte ett programmeringsspråksval.
Det sista är ju en punkt jag nämnt flera gånger ovan: historiskt har just portning varit en svår punkt. Framförallt kod skrivet i C eller C++ (båda är dominerade i alla programvara som har några år på nacken) kommer med väldigt nära 100 % sannolikhet inte fungera med en enkel omkompilering på MIPS, PowerPC, SPARC eller 32-bit Arm om man tidigare bara kört på x86/x86_64.
Förutsatt att man inte skrivit saker i assembler är däremot sannolikheten att det fungerar på RISC-V och ARM64 mycket hög, nära 100 % om programmen är enkeltrådade. Lite mindre om de är multitrådade, men då handlar det om saker som är buggar även på x86 men de i praktiken händer rätt sällan p.g.a. x86 minneskonsistensmodell.
Skillnaden med "moderna språk" är att det faktiskt med stor sannolikhet även fungerar rakt av på alla typer av CPUer.
Så om/när Windows för brett stöd för något annan än x86_64 lär det gå väldigt fort att porta all relevant programvara. I alla fall så länge det handlar om ISA som tar samma approach som ARM64/RISC-V.