Processorvärldens Linux växer internationellt

Permalänk
Melding Plague

Processorvärldens Linux växer internationellt

RISC-V är processorvärldens motsvarighet till öppen källkod och växer sig allt mer populär som en del i moderna processorkretsar.

Läs hela artikeln här

Visa signatur

Observera att samma trivselregler gäller i kommentarstrådarna som i övriga forumet och att brott mot dessa kan leda till avstängning. Kontakta redaktionen om du vill uppmärksamma fel i artikeln eller framföra andra synpunkter.

Permalänk
Medlem

Förvirrande rubrik även om jag förstår vad som menas. Öppen/fri arkitektur kanske?

Jag hoppas det ska komma friare alternativ tids nog. Vill äga min hårdvara, inte bara min mjukvara. Hade varit roligt att verkligen få bygga en annorlunda dator, det känns som allt är x86 och ARM just nu.

Visa signatur

Arch | 1440p 165Hz IPS | 7800X3D | 1080ti | 64GB@6GHz | SN850 2TB

Permalänk
Medlem

@sniglom: Det är en öppen, fri arkitektur utan några patentproblem. Vem som helst kan implementera designer, utan att behöva betala några som helst licenskostnader.

Det finns en hel rad RISCV-processorer nu, som blivit bättre och mer kraftfullare, både som mikrokontrollers och annat.

Sipeed bland annat påstår att de är en generation från att nå generisk arm-prestanda. Spännande!

Finns också en hel rad FPGA-kärnor för RISCV, som folk kört innan, och linux finns portat till det. Finns även brädor med PCIE som visats upp, där de kört lite spel på, via linuxkärnan och amd's linuxdrivrutiner som är open source.

Permalänk
Permalänk
Medlem
Skrivet av sniglom:

Förvirrande rubrik även om jag förstår vad som menas. Öppen/fri arkitektur kanske?

Jag hoppas det ska komma friare alternativ tids nog. Vill äga min hårdvara, inte bara min mjukvara. Hade varit roligt att verkligen få bygga en annorlunda dator, det känns som allt är x86 och ARM just nu.

RISC-V har bara en öppen instruktionsuppsättning (ISA). Arkitektur och implementation står andra företag för, dessa kan vara öppna eller stängda.

Permalänk
Inaktiv
Permalänk
Medlem

Hoppas detta lyckas! Idag känns allt osäkert. I varje inteldator snurrar ett minix-system som inte kan kontrolleras av andra än invigda!
Antag att det blir världskrig. Hur många datasystem kommer att fungera då?

Skickades från m.sweclockers.com

Permalänk
Medlem

Skulle vilja se något raspberry/orange/banana-pie kort till liknande pris med en risc-v processor

Skickades från m.sweclockers.com

Visa signatur

Du behöver inte vaccinera dina barn, bara dom du vill behålla.

Permalänk
Medlem

Dum fråga, uttalas RISC-V som V eller som 5?

Visa signatur

3900X, RX 6700 XT, 32gb RGB RAM.

Permalänk
Medlem
Skrivet av brainlessbob:

Dum fråga, uttalas RISC-V som V eller som 5?

Uttalas risk-five!

Skickades från m.sweclockers.com

Permalänk
Lyxfällan 🎮

@brainlessbob: Romerska siffror uttalas med ytterst få undantag med dess motsvarande siffra i det arabiska siffersystemet. Final Fantasy XII uttalas Final Fantasy Tolv, RISC-V som RISC-FEM, osv. Precis som @Irre skriver!

Visa signatur

"We're with the press, hired geeks!"
Raoul Duke, Fear n' Loathing in Las Vegas

Permalänk
Medlem
Skrivet av loevet:

@brainlessbob: Romerska siffror uttalas med ytterst få undantag med dess motsvarande siffra i det arabiska siffersystemet. Final Fantasy XII uttalas Final Fantasy Tolv, RISC-V som RISC-FEM, osv. Precis som @Irre skriver!

Fast hur ska man veta att det är en romersk siffra i detta fall? Säger man X-COM eller TEN-COM?

Bra fråga hur som! Jag har också sagt RISC-V (och inte five).

Permalänk
Lyxfällan 🎮

@sKRUVARN: Ja det krävs ett mått av insikt i per fall-basis Eftersom RISC är en etablerad instruktionsuppsättning kan V tolkas som versionsnumrering, och därmed uttalas Five (även om RISC inte fått versionsnummer fram till RISC-V).

X-COM är ju en förkortning av Extraterrestrial Combat, så där är X inte en siffra eller versionsnummer. Men som sagt, det krävs en viss kontextuell insikt för att veta

Visa signatur

"We're with the press, hired geeks!"
Raoul Duke, Fear n' Loathing in Las Vegas

Permalänk
Medlem

@loevet: Jag vet, jag var bara osäker om det var ett 'V' eller en romersk femma. Final Fantasy är rätt så uppenbart att det är vilket nummer i serien det är.

RISC är vad jag vet en klass av processor arkitektur som blandannat innefattar ARM & MIPS. Vad jag vet så finns det inga välkända arkitekturer som heter RISC II, RISC III osv. Då är det inte lika uppenbart.

Visa signatur

3900X, RX 6700 XT, 32gb RGB RAM.

Permalänk
Rekordmedlem
Skrivet av brainlessbob:

Dum fråga, uttalas RISC-V som V eller som 5?

Risc V eller Risc Quinque.

Visa signatur

R5 5600G, Asus ROG STRIX X470-F Gaming, WD SN850X 2TB, Seasonic Focus+ Gold 650W, Aerocool Graphite v3, Tittar på en Acer ET430Kbmiippx 43" 4K. Lyssnar på Behringer DCX2496, Truth B3031A, Truth B2092A. Har också oscilloskop, mätmikrofon och colorimeter.

Permalänk
Medlem
Skrivet av Irre:

Uttalas risk-five!

Skickades från m.sweclockers.com

Precis. (Se https://riscv.org/risc-v-isa/ )

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

Skulle vilja se något raspberry/orange/banana-pie kort till liknande pris med en risc-v processor

Skulle det finnas någon enkortsdator som är RISC-V baserad som kan konkurrera med Raspberry Pi 4 och har hyfsat bra stöd så skulle jag troligtvis köpa om priset var rimligt.

Permalänk
Datavetare
Skrivet av sniglom:

Förvirrande rubrik även om jag förstår vad som menas. Öppen/fri arkitektur kanske?

Jag hoppas det ska komma friare alternativ tids nog. Vill äga min hårdvara, inte bara min mjukvara. Hade varit roligt att verkligen få bygga en annorlunda dator, det känns som allt är x86 och ARM just nu.

Mikroarkitekturer som implementerar RISC-V både kan och kommer nog i praktiken innehåller både licensierad och patenterad teknik, lär i alla fall gälla eventuellt kommande högpresterande modeller. Svårt att undvika.

Vad det handlar om är en öppen ISA (Instruction Set Architecture) specifikation utan licenskrav. Kompilatorstödet för RISC-V förbättras snabbt, men än så länge är det inte alls på samma nivå som x86 och ARM.

Just nivån på programvarustödet lär vara det som avgör ödet för RISC-V. Blir det bra nog lär ARM få det tufft på sikt då RISC-V på många sätt påminner om Aarch64 (64-bitars ARM). Dessa två är, givet dagens kunskap, så nära man kan komma "perfekta" ISA.

POWER har nog motlut, men här finns ju ändå en långt mer mogen programflora jämfört med RISC-V. Och även om POWER inte är en "perfekt ISA" måste det vara #3; givet dess ålder får man säga att IBM verkligen visste vad de gjorde när de designade POWER. ISA som MIPS och SPARC har inte åldrats med värdighet, absolut inte samma problem som x86 men alla dessa dras med massor med dåliga beslut (givet dagens krav, många av designbesluten var helt vettig när de togs, men ingen "fine-wine" precis...).

Skrivet av brainlessbob:

@loevet: Jag vet, jag var bara osäker om det var ett 'V' eller en romersk femma. Final Fantasy är rätt så uppenbart att det är vilket nummer i serien det är.

RISC är vad jag vet en klass av processor arkitektur som blandannat innefattar ARM & MIPS. Vad jag vet så finns det inga välkända arkitekturer som heter RISC II, RISC III osv. Då är det inte lika uppenbart.

Femman kommer av att detta är den femte RISC designen som skapats vid Berkeley

  1. RISC I (som jag tror senare blev MIPS)

  2. RISC II (som utvecklades till SPARC)

  3. SOAR/VLSI-BAM

  4. SPUR

  5. RISC-V

Visa signatur

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

Permalänk
Lyxfällan 🎮

@Yoshman: minsann, det kände jag inte till! Tack för informationen, då har jag lärt mig något matnyttigt idag också 👍

Visa signatur

"We're with the press, hired geeks!"
Raoul Duke, Fear n' Loathing in Las Vegas

Permalänk

Vi går emot en framtid då vi blir allt mindre hårdvaruberoende.
Bara se på språken.
Maskinkod = ett helvete att porta manuellt på den tid man kodade denna.
Assembler = Nu går det porta program, mindre program utan besvär, men större ett helvete som ovan.
C/fortran/pascal och allt vad språken heter, nu helt plötsligt går det enkelt att porta många av de program man kodade i assembler, men vad gör man då? Jo ännu större program och man fick samma visa med porta..
Och så har de hållit på hela tiden, nu idag är Microsoft C# Core rätt portabelt, där de rekommenderar sig att använda .Net standard om man vill göra libs som fungerar till olika plattformar.

I vilket fall det har hela tiden blivit bara enklare att porta program från olika system, men samtidigt har ens program hela tiden växt i storlek. Men ändå idag satsar många på plattformsoberoende tekniker för deras lösningar.

Om vi tar folks persondatorer så går trenden emot att de kan köra på vad för hårdvara som helst och behovet av datorkraft stagnerar. Jag tycker många persondatorer är onödigt bloatade för vad användarna använder dem trenden till, men os som chromeos etc växer sig starkare.

Det jag menar med detta är att jag tycker det är positivt med konkurrens, för min egen del så en dator med bra webbläsare, rdp/ vnc, SSH och mängder med vpn klienter så kan man utföra det mesta jobb på en server.

Permalänk
Medlem

@lillaankan_i_dammen: Kör du linux fungerar 'det mesta' bara out of the box för nya processorarkitekturer. Titta bara på debian.

X86, X86-64, ARM, ARM med hårdvarufpu, Arm64, MIPS32, MIPS64, MIPS32 little endian, powerpc i olika varianter, ibm's system 360.

Och det bara för arkitekturer som lovas fungera. De har exempelvis släppt stödet för många arkitekturer, men som underhålls av voluntärer, eller är experimentella:

alpha, avr32, hppa, itanium, m32, m68k, or1k, riscv (obviously), SPARC, SPARC64, sh

Det betyder inte att det är perfekt någonstans, på något håll, bara att det finns en rejäl bakgrund med mycket testning, och fördelen med det är ju att du kan köra automatisk kompilering och testning av deras över 51000 paket :).

Permalänk
Medlem

Om man nu ska tala om fördelarna med öppen mjukvara/arkitektur bör det väl påminnas om Google.

Permalänk
Medlem
Skrivet av loevet:

@brainlessbob: Romerska siffror uttalas med ytterst få undantag med dess motsvarande siffra i det arabiska siffersystemet. Final Fantasy XII uttalas Final Fantasy Tolv, RISC-V som RISC-FEM, osv. Precis som @Irre skriver!

Men jag tror han snarare undrade om V stod för fem eller för bokstaven V.

Visa signatur

Fractal Design Meshify 2 Compact w/ Dark Tint | Intel i5 12600K | Asus ROG Strix B660-F | 32 GB Corsair DDR5 5600 MHz CL36 | MSI Geforce RTX 3060 TI Ventus 2X OCV1 | 512 GB Samsung Pro 850 SSD + 2TB WD Black SN850 NVME PCI-E 4.0 | Corsair RM750X |

Permalänk
Medlem
Skrivet av GuessWho:

Skulle det finnas någon enkortsdator som är RISC-V baserad som kan konkurrera med Raspberry Pi 4 och har hyfsat bra stöd så skulle jag troligtvis köpa om priset var rimligt.

Priset är väl det stora problemet, har sett demokort med R-V processorer men priset har varit högt. Kan ju köpa en Orange pi för en hundring eller en Raspberry för några hundra till.

Visa signatur

Du behöver inte vaccinera dina barn, bara dom du vill behålla.

Permalänk
Medlem
Skrivet av Yoshman:

Mikroarkitekturer som implementerar RISC-V både kan och kommer nog i praktiken innehåller både licensierad och patenterad teknik, lär i alla fall gälla eventuellt kommande högpresterande modeller. Svårt att undvika.

Vad det handlar om är en öppen ISA (Instruction Set Architecture) specifikation utan licenskrav. Kompilatorstödet för RISC-V förbättras snabbt, men än så länge är det inte alls på samma nivå som x86 och ARM.

Just nivån på programvarustödet lär vara det som avgör ödet för RISC-V. Blir det bra nog lär ARM få det tufft på sikt då RISC-V på många sätt påminner om Aarch64 (64-bitars ARM). Dessa två är, givet dagens kunskap, så nära man kan komma "perfekta" ISA.

POWER har nog motlut, men här finns ju ändå en långt mer mogen programflora jämfört med RISC-V. Och även om POWER inte är en "perfekt ISA" måste det vara #3; givet dess ålder får man säga att IBM verkligen visste vad de gjorde när de designade POWER. ISA som MIPS och SPARC har inte åldrats med värdighet, absolut inte samma problem som x86 men alla dessa dras med massor med dåliga beslut (givet dagens krav, många av designbesluten var helt vettig när de togs, men ingen "fine-wine" precis...).

Femman kommer av att detta är den femte RISC designen som skapats vid Berkeley

  1. RISC I (som jag tror senare blev MIPS)

  2. RISC II (som utvecklades till SPARC)

  3. SOAR/VLSI-BAM

  4. SPUR

  5. RISC-V

Vad säger du om Alfa-arkitekturen då? Enligt mig så var det synd att Intel fick HP satsa på Itanium i stället vilket dödade Alfa. Minns jag rätt så var det den snabbaste processorn ett tag.

Permalänk
Datavetare
Skrivet av SAFA:

Vad säger du om Alfa-arkitekturen då? Enligt mig så var det synd att Intel fick HP satsa på Itanium i stället vilket dödade Alfa. Minns jag rätt så var det den snabbaste processorn ett tag.

Alpha var en bra ide fram till att CPUer fick mer än en kärna... Precis som SPARCs registerhjul är designen för minnesoperationer i Alpha ett lysande exempel på hur rejält smarta idéer kan bli ordentliga ankare när det sker lite mer fundamentala förändringar i vad som är mest viktigt.

Alpha har också riktigt dålig kod-densitet (ett problem den delar med MIPS och SPARC, men dessa är inte fullt lika dåliga på den punkten). Ett litet problem när det begav sig, ett allt större problem ju mer RAM-latens sackar efter hastigheten hos CPU-kärnorna.

Itanium är ett exempel på att man kan göra allt enligt konstens alla regler, men ändå hamna i en dynghög. Itanium togs fram i en tid när man från akademiskt håll var övertygad om att framtiden låg i att göra mer optimeringar i programvara som kompilatorer då komplicerade breda out-of-order designer har rätt dålig prestanda vs antal transistorer skalning.

Tankevurpan det visade sig hela det spåret hade är att man bara kan ta hänsyn till statisk information för optimering, dynamiska aspekter där utfallet beror på hur den data man råkar jobba med påverkar körningen kräver av (när man är efterklok ) rätt uppenbara skäl information som bara finns när man faktiskt kör programmet.

Det RISC-V och Aarch64 (som man måste vara medveten om är en helt ny ISA från 32-bitars ARM, så finns en anledning varför ARM-prestanda först nu drar iväg så pass) är optimerat för är just att göra "IPC mot antal transistorer"-kvoten så bra som möjlig. Dessa ISA har egenskaper som möjliggör effektivt utnyttjande av väldigt många pipelines i backend, detta genom att designa instruktionerna så att de har minimalt med beroende mellan sig (hos 32-bitars ARM och än mer i x86 har tyvärr de flesta instruktioner en påverka på ett för CPU-kärnan globalt tillstånd, flag-fältet).

x86 har också problemet att överhuvudtaget vet var instruktioner börjar och slutar. μ-op cachen har flera fördelar (Cortex A77 har en μ-op$ av strömsparande orsaker), men för x86 är den helt kritisk för att kunna nå riktigt hög IPC då det är enda realistiska sättet att kunna avkoda tillräckligt med instruktioner per cykel.

Just här finns ett beslut som fundamental skiljer sig mellan RISC-V och Aarch64. Hos RISC-V kan instruktioner vara 2- eller 4-bytes, hos Aarch64 är de alltid 4 bytes. Båda har för- och nackdelar, högre kod-densitet mot enklare front-end. RISC-V är inte i närheten av x86 där instruktioner kan vara allt från 1-15 bytes (OK med variabel längd, men vem tyckte 1-15 bytes uppdelade i variabellängd-prefix, variabellängd-opkod och variabellängd-argument lät vettigt)...

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:

Alpha var en bra ide fram till att CPUer fick mer än en kärna... Precis som SPARCs registerhjul är designen för minnesoperationer i Alpha ett lysande exempel på hur rejält smarta idéer kan bli ordentliga ankare när det sker lite mer fundamentala förändringar i vad som är mest viktigt.

Alpha har också riktigt dålig kod-densitet (ett problem den delar med MIPS och SPARC, men dessa är inte fullt lika dåliga på den punkten). Ett litet problem när det begav sig, ett allt större problem ju mer RAM-latens sackar efter hastigheten hos CPU-kärnorna.

Itanium är ett exempel på att man kan göra allt enligt konstens alla regler, men ändå hamna i en dynghög. Itanium togs fram i en tid när man från akademiskt håll var övertygad om att framtiden låg i att göra mer optimeringar i programvara som kompilatorer då komplicerade breda out-of-order designer har rätt dålig prestanda vs antal transistorer skalning.

Tankevurpan det visade sig hela det spåret hade är att man bara kan ta hänsyn till statisk information för optimering, dynamiska aspekter där utfallet beror på hur den data man råkar jobba med påverkar körningen kräver av (när man är efterklok ) rätt uppenbara skäl information som bara finns när man faktiskt kör programmet.

Det RISC-V och Aarch64 (som man måste vara medveten om är en helt ny ISA från 32-bitars ARM, så finns en anledning varför ARM-prestanda först nu drar iväg så pass) är optimerat för är just att göra "IPC mot antal transistorer"-kvoten så bra som möjlig. Dessa ISA har egenskaper som möjliggör effektivt utnyttjande av väldigt många pipelines i backend, detta genom att designa instruktionerna så att de har minimalt med beroende mellan sig (hos 32-bitars ARM och än mer i x86 har tyvärr de flesta instruktioner en påverka på ett för CPU-kärnan globalt tillstånd, flag-fältet).

x86 har också problemet att överhuvudtaget vet var instruktioner börjar och slutar. μ-op cachen har flera fördelar (Cortex A77 har en μ-op$ av strömsparande orsaker), men för x86 är den helt kritisk för att kunna nå riktigt hög IPC då det är enda realistiska sättet att kunna avkoda tillräckligt med instruktioner per cykel.

Just här finns ett beslut som fundamental skiljer sig mellan RISC-V och Aarch64. Hos RISC-V kan instruktioner vara 2- eller 4-bytes, hos Aarch64 är de alltid 4 bytes. Båda har för- och nackdelar, högre kod-densitet mot enklare front-end. RISC-V är inte i närheten av x86 där instruktioner kan vara allt från 1-15 bytes (OK med variabel längd, men vem tyckte 1-15 bytes uppdelade i variabellängd-prefix, variabellängd-opkod och variabellängd-argument lät vettigt)...

Compressed subset i RISC-V skiljer sig ganska mycket från Thumb läget i tidigare Aarch versioner.

RVC är enbart en lista med alias som kan bakas in ganska triviellt för att komprimera kod, det är ett helt frivilligt tillägg, men är rekommenderat för generella implementeringar (bl.a. pga. det sparar ca 20% cache).

Kretsdesignare som vill klämma ur mer prestanda kan t.ex. implementera "macro op fusion" internt, vilket enklare kretsdesigner kan ignorera helt och hållet om de vill spara på transistorer och komplexitet.

Thumb läget i Aarch är ett helt separat exekveringsläge (i stort sett en egen ISA), så för att effektivt använda det måste man undvika byten till och från det läget, opraktiskt om man vill komma åt utökningar av standard ISAn som SIMD samtidigt som man vill spara på bytes, vilket jag gissar står till stor del varför man gett upp på det med Aarch64.

En annan grej jag tror står till skuld att de gav upp på Thumb är att modern Aarch har ganska många CISC liknande kommandon, som t.ex. "LDMIAEQ SP!, {R4-R7, PC}" vilket är en "stack pop and return from a function call", definitivt mindre bytes än motsvarande i RVC men börjar sträva iväg från RISC principen.

Visa signatur

"Oh glorious cheeseburger… we bow to thee. The secrets of the universe are between the buns..."
"All my farts come straight from hell, you're already dead if you notice a smell"

Permalänk
Medlem
Skrivet av Yoshman:

Alpha var en bra ide fram till att CPUer fick mer än en kärna... Precis som SPARCs registerhjul är designen för minnesoperationer i Alpha ett lysande exempel på hur rejält smarta idéer kan bli ordentliga ankare när det sker lite mer fundamentala förändringar i vad som är mest viktigt.

Alpha har också riktigt dålig kod-densitet (ett problem den delar med MIPS och SPARC, men dessa är inte fullt lika dåliga på den punkten). Ett litet problem när det begav sig, ett allt större problem ju mer RAM-latens sackar efter hastigheten hos CPU-kärnorna.

Intressant om Itanium mm.
Att Alpha har dålig kod-densitet ses ju lätt på den den av GCC genererade koden, men vad är problemet med minnesoperationer vid flera kärnor?
Man nämner ju multiprocessorsystem redan i målen med arkitekturen, så man tycker ju de borde ha tänkt på det.

Off topic så finns ett litet påskägg i de ~30 sista sekunderna av ovanstående.

Permalänk
Datavetare
Skrivet av SAFA:

Intressant om Itanium mm.
Att Alpha har dålig kod-densitet ses ju lätt på den den av GCC genererade koden, men vad är problemet med minnesoperationer vid flera kärnor?
Man nämner ju multiprocessorsystem redan i målen med arkitekturen, så man tycker ju de borde ha tänkt på det.

https://www.youtube.com/watch?v=klg1FtHADso

Off topic så finns ett litet påskägg i de ~30 sista sekunderna av ovanstående.

Alpha har en minneskonsistensmodell som med den specifikation vi idag använder skulle bli ineffektivt att implementera.

Kommer inte ihåg namnet på makrot i Linux-kärnan, men finns något som är en no-op på alla CPU-arkitekturer förutom Alpha just kring minneskonsistens. Aarch64 och RISC-V har klart fördel på denna punkt, dessa designades efter att programmeringsvärlden lärt sig hur en vettig modell bör se ut, så Aarch64 och RISC-V har en 1:1 mappning mot det. Alla de andra skjuter över målet med vad som synkroniseras i varje fall -> sämre prestanda än nödvändigt.

Visa signatur

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