- uid_18128 blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Nem a 128 bit az elsodleges cel (kinottuk egyaltalan a 64 bitet? A 32 bitnek a >2GB RAM megjelenese megrendezte a temeteset, de a 64 "kinovesehez" elobb az kene, hogy Moore torvenye egyaltalan meg letezzen hardver oldalon is, ne csak szoftverkovetelmenyekben), hanem hogy a mar nVidia tulajdonaban levo ARM holdings-nak ne kelljen jogdijat fizetni. Az open source architektura erdekli oket leginkabb:
https://www.macrumors.com/2021/09/03/apple-alternative-arm-architecture/
(Eszembejutott amikor az MS 10+ eve azzal reklamozta a .NET-et, hogy architektura-fuggetlen (Windows Phone 7 idejen). Utolag visszagondolva es latva, hogy az Apple mennyire kezd kozel allni hozza, es meg igy is milyen messze van tole, egyre viccesebb)
- A hozzászóláshoz be kell jelentkezni
128 bitnel az a cel hogy olyan nagy cim tartomany hogy nehez megtippelnie a gonosz tevoknek hol van valami ertelemes ;-)
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
És a malloc-ot is le lehet cserélni egy random generátorra :-)
- A hozzászóláshoz be kell jelentkezni
Alabecsulod a posztmodern Javascript fejlesztok kepesseget. A vegen meg megmutatjak, hogy akkor sem mindegy. :)
- A hozzászóláshoz be kell jelentkezni
ARM körül lesznek még furi dolgok: https://prohardver.hu/hir/arm_china_gyakorlatilag_kulon_entitas_valt.ht…
Egyébként a verseny nem a 128 bit irányában megy, hanem a jobb számítás/watt arány inkább a motiváló. A RISCV ez utóbbira ígéretesnek tűnik, aztán majd kiderül.
- A hozzászóláshoz be kell jelentkezni
Azert nem lenne rossz elso lepesnek az hogy a RISC-V workflow kicsit jobban elterjedjen. Kb ezek lehetnek most a szuk keresztmetszetek:
- Lehessen venni a boltban ilyen architekturaju ic-ket amiken lehet gyakorolnunk
- Legyen valami kiforrottabb, sztenderdizalt(abb) MCU/SoC core logika (mint a Cortex-M-eknel az NVIC/SCB/SysTick ill ezekre a CMSIS)
- Egy-ket verilog referenciaimplementacio sem lenne rossz.
Marmint tenyleg egyetertek azzal hogy fasza kis architektura ez, rengeteg elonnyel, de most ahhoz pl hogy jatszunkk vele, a fentiek azert ugy nem artananak...
- A hozzászóláshoz be kell jelentkezni
Ha nem lenne kapható RISC-V lapka, akkor ilyen Rust projektek sem születnének: https://blog.cecton.com/posts/rust-and-riscv/
- A hozzászóláshoz be kell jelentkezni
Igenigen, köszi!
Ez viszonylag újnak tűnik, és legalább van az igazi bótban is. Csak magát a SoC-ot nem lelem (FE310), szoval ha fejlesztenék is rá egyedi hardvert akkor sem biztos hogy ez a jó irány... Persze ettől függetlenül 1-2 ilyen dev boardra beruházok majd ;)
- A hozzászóláshoz be kell jelentkezni
Csak tipp, de az nVidia felvásárolta az ARM-ot, az Apple meg az nVidia nem igazán szeretik egymást; lehet nem akarnak tőlük függeni.
- A hozzászóláshoz be kell jelentkezni
Úgy tudom, egyenlőre erre még csak akarat van, de az uniós és amerikai versenyfelügyelet részéről is vannak bőven fenntartások a rábólintásig...
- A hozzászóláshoz be kell jelentkezni
Jogos, én úgy emlékeztem, hogy már rég tető alá hozták.
- A hozzászóláshoz be kell jelentkezni
egyenlőre
Ugyanazt a bort isszak? (Nem, nehogy valaki idepaste-elje a sorozatgyilkosos ezredszer mar unalmas szojatekot, probaljunk ki valami ujat :P )
- A hozzászóláshoz be kell jelentkezni
<trinitix> egyenlore orulok hogy talaltam eletcelt
<koszik> egyenlore a sorozatgyilkos fog darabolni mielott kihordja a reszeid az erdobe
<koszik> a szo amit kerestel az 'egyelore'
- A hozzászóláshoz be kell jelentkezni
Ezt melyik Apple-fikazasomert kaptam? :(
- A hozzászóláshoz be kell jelentkezni
Vagy másképp nézve ugyanez, nem feltétlen akarnak ARM-ról elváltani, de szeretnének jobb tárgyalási pozíciót maguknak. Ahhoz pedig jól jön, ha demonstrálni tudják, hogy van B tervük.
Az iparban kevés szereplőről hiszik el, hogy képes a teljes ökoszisztémán sikeresen keresztülvinni egy architektúraváltást, az Apple pont ez a kivétel, aki már 3 és félszer megcsinálta (6502->68000->PPC->x86->ARM).
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Szerintem is értelmetlen a címzést 128 bitre felskálázni, az adatokat viszont volna értelme. Ehhez szerintem nem kell egy teljes új architektúra, hanem elegendő néhány 128 bites regiszterrel kiegészíteni ami van, és ezekhez utasításokat adni.
Na jó, még a memóriabusz szélességét megéri feljebb skálázni, hogy egyszerre 128 vagy több bit menjen át rajta.
- A hozzászóláshoz be kell jelentkezni
Regiszterből van még 512-bites is az x86-ban, az adatbusz az, ami 64-bites. Viszont azt akkor memória oldalról el is kell tudni látni adattal, szóval vagy átállunk GDDR-re, vagy mindenképp két DDR-es modul kell majd egy olvasáshoz.
- A hozzászóláshoz be kell jelentkezni
GDDR helyett HBM2. Sőt már van HBM3 is. Nézz utána, érdemes.
NVIDIA Tesla A100 és hasonló brutál gyors számítási teljesítményű modulok ilyet használnak.
- A hozzászóláshoz be kell jelentkezni
Megpróbáltam rákeresni, hogy mennyiért vesztegetik, de semmi érdemlegeset nem találtam, azon túl, hogy 2019-ben a HBM2 GB-onként $7.5 volt, azaz egy 64 GB-os HBM2 modul cca. 144000 Ft lehetett akkoriban. Hát, nem az az asztali PC kategóriás cucc. Amúgy mindenütt csak GFX kártyákban jött szembe, de konkrétan CPU-hoz nem találtam semmit.
- A hozzászóláshoz be kell jelentkezni
Sima Raspberry-nél nincs értelme. Drága és semmit nem gyorsít.
Ennél a CPU-nál viszont akkora a számítási tempó, hogy HBM2-be dolgozik: https://www.fujitsu.com/downloads/SUPER/a64fx/a64fx_datasheet.pdf
- A hozzászóláshoz be kell jelentkezni
Ki beszélt RPi-ről; x86-ról, asztali PC-kről volt szó.
- A hozzászóláshoz be kell jelentkezni
PC szintén olyan kategória, ahol hasonlóan a Raspberry4-hez nem jellemző az annyira kiemelkedő számítási tempó, amiáltal a leggyorsabb procis PC-nél a DDR5 szintén nem okoz gyakorlati korlátot az adatokkal való etetésnél.
Ellenben a PC-be rakott 5000-10000 darab processzort tartalmazó számító egység (például NVIDIA A100) adatkiszolgálásához erős korlát a GDDR5x is, oda célszerű a HBM.
Vesd össze:
AMD Ryzen 3600 484 GFLOPS
NVIDIA A100: 19,5 TFLOPS
Utóbbi adatokkal való etetéséhez nem elég a GDDR5x.
- A hozzászóláshoz be kell jelentkezni
Én hiszek neked, de itt az asztali gépek 128-bitesítéséről volt szó. :) Ezért mondtam, hogy GDDR, vagy mindenképpen kettős DDR, mert különben nincs értelme a CPU adatbuszát kiterjeszteni 128-bitre, ha maga a RAM csak 64-bites adatbusszal bír.
- A hozzászóláshoz be kell jelentkezni
Miért lenne előnyös? Kevés valakinek most a 4 milliárd darab 4 gigabyteos RAM mint kicímezhető memóriatartomány?
Vagy aritmetikát akarsz párhuzamosítani? Arra ott a 256 bites és 512 bites AVX.
Egy 64 bites rendszerben RAM csatornából nyugodtan tehetsz N*64 bitet és hardveresen multiplexálhatod a CPU boszorkánykonyhájának kiszolgálására. Ebben nem akadályoz semmi. Ezt a 64 bites architektúrákon szépen meg lehet tenni és gyakran meg is teszik. Például Xeon Gold procikban 6 csatornás memóriavezérlő van, ezzel az alábbiak szerint gyorsítva a DDR4 memória sávszélességét.
| Bandwidth |
Single 19.87 GiB/s Double 39.74 GiB/s Quad 79.47 GiB/s Hexa 119.21 GiB/s |
|---|
Persze ha valaki 1 darab nagyméretű RAM-ot tesz ilyenbe, az nem használja ki ezt, így járt.
Továbbá aki olcsó x86 Celeron procival akar nagyot alkotni, az szintén így járt.
Tehát kínálat van x86 terén is, bár itt is igaz hogy "olcsón húdegyorsat" nem játszik.
Aztán vissza a realitás talajára: 15 wattos U procis laptop előtt ülök éppen, elég a számítási teljesítménye a hozzászólás megírásához. Otthonra nem kell több.
Ipari célokra pedig olyat, amit a feladat igényel. Választék ahogy látszik, van.
- A hozzászóláshoz be kell jelentkezni
Kicímezhető memóriatartomány??? Te valamit nagyon félreértettél, adatbuszról volt szó, nem címbuszról.
A multi-channel az nem ekvivalens a kiterjesztett adatbusszal, az olvasás ott továbbra is több lépésből történik meg, lévén a CPU-nak nincs annyi data-pinje.
Ki beszélt olcsó Celeroncsokról, könyörgöm??? Egy esetleges jövőkép 128-bitesített adatbuszú x86-osairól volt szó.
Übersebességről sem volt szó; arról volt szó, hogy 128-bites regiszter van az x86-ban, de az adatbuszra egyszerre nem fér ki annyi.
Ne haragudj már, de te melyik szálat, vagy kinek a hozzászólásait olvasod? :) Csak mert konzekvensen nem arról beszélsz, amiről szó volt.
- A hozzászóláshoz be kell jelentkezni
A 128 bit széles RAM bitszélességet már régen túlléptük az erősebb x86-nál.
Architektúrában viszont 64 bites marad. Az adatbusza régóta sokkal szélesebb. Talán a Pentium-II korában jött be a 128 bites adatbusz?
- A hozzászóláshoz be kell jelentkezni
A DDR 64-bit széles. Mindig is annyi volt.
A Pentium II-nek 64-bites adatbusza volt, ahogy az összes többinek is. Kívül, fizikailag. Az, hogy belül az x86-osok cache-e hány bites adatbusszal bír, illetve a fizikait hányszoros ciklussal tudja írni/olvasni az más kérdés; itt a fizikai adatbuszról volt szó, az pedig még mindig 64-bit, lévén a DDR RAM is 64-bites. Ezért mondtam, hogy ha a CPU adatbuszát kibővítjük, akkor vagy át kell állni a GDDR-re, vagy mindenképp csak párosával lehet a DDR-t használni.
- A hozzászóláshoz be kell jelentkezni
Kicsit kekeckedő módon visszakérdezek: miért száll el az x86 SIMD utasításkészlete segfault-tal align 8 esetén?
- A hozzászóláshoz be kell jelentkezni
Oké, de ha align 16 van, akkor a CPU kibírja az SSE-t MOVAPS-sel is, mivel akkor a 128 bit szélesség egyben van és nem kell unaligned miatt átrotálni, ami mellesleg lassít.
- A hozzászóláshoz be kell jelentkezni
Tudom, de nem ez volt a lényeg. Még csak nem is az, hogy van unaligned access-t lehetővé tevő parancs. A lényeg, hogy a fizikai adatbusz 64-bites. Igen, belül a cache már 256, meg 512, meg mittudomén hány bites adatbusszal is bírhat. Igen, a fizikai adatbuszt sokciklusosan tudja meghajtani a CPU, így működik a multi-channel is. De a fizikai adatbusz 64-bites, így az egyszerre közlekedő adatmennyiség az 64-bit és annyi is marad, mindaddig, amíg a fizikai lábak számát nem bővítik. És ha ez megtörténik, akkor pedig vagy átállunk egy szélesebb adatmozgatást lehetővé tevő RAM típusra (pl. GDDR, vagy akár a HBM, ha valaki aranyból akar gépet építeni), vagy kettő (vagy több) DDR RAM-ot kell a CPU-val használni, különben a 64-bit feletti lábak a levegőben fognak lógni. Erről volt szó, nem másról.
- A hozzászóláshoz be kell jelentkezni
Na akkor kezdjük újra. Hallgatlak, hogy mit értetek 128 bites processzor alatt?
Csak mert ahogy írod, akár 512 bit széles a mai CPU-k cache-e és a többcsatornás memóriakontrollerrel párhuzamosítják akár 8 * DDR szélesre a külső buszt (Lásd EPYC: 4096 lábas foglalatát).
További boszorkánykonyha, hogy 4 vagy ennél is több utasítást dolgoz egyszerre fel a gyors processzor magonként (lásd out-of-order architektúrák lehetőségeit).
- A hozzászóláshoz be kell jelentkezni
Kész... Asztali gépekről és azok CPU-iról volt szó; te most tényleg egy sort nem olvastál el a threadből, vagy direkt szívózól? Ezt hogy dugod be egy PC-be, vagy egy Mac-be?
- A hozzászóláshoz be kell jelentkezni
A Threadripper x86 asztali PC processzor.
- A hozzászóláshoz be kell jelentkezni
Család, de mellékes; 64-bites adatbusza van. Asztali gépbe csak 64-bites adatbuszú CPU-t tudsz rakni (vagy kisebbet, de az mellékes most).
- A hozzászóláshoz be kell jelentkezni
És ebből van párhuzamosan 4 darab, hogy ezáltal 256 bit széles memóriabuszról tudjál olvasni a széles belső cache-be.
- A hozzászóláshoz be kell jelentkezni
És? Fizikailag továbbra is 64-bites a címbusz mind a CPU, mind a RAM oldalon.
- A hozzászóláshoz be kell jelentkezni
Igen, és ez mit jelent? Kisebb RAM méretet tud kicímezni?
- A hozzászóláshoz be kell jelentkezni
Adatbuszt akartam írni, csak elbasztam. Nem mintha nem tudnád, hiszen végig adatbuszról beszéltem, többször fel is hívtam rá a figyelmed. Tényleg kötekedni akarsz? Tőled nem vártam volna.
- A hozzászóláshoz be kell jelentkezni
Ok, félreértettelek. Bocsi.
Adatbusz mint írtam, a drágább x86 prociknál ma is N * 64 bitként van átvíve. Ez a CPU főprocijánál sokkal nagyobb számítási sebességű (ma már mellesleg szintén OoO) SIMD engine parallel tölti be. De ezt is letisztáztuk.
Még mindig az a kérdésem, hogy az N * 64 bites parallel DDR adatátvitelhez képest milyen előrelépést okozna az N/2 * 128 bites szervezés?
- A hozzászóláshoz be kell jelentkezni
Az N * 64-bites párhuzamos DDR-hez képest nem valószínű, hogy a fele annyi csatornán hajtott, de kétszer akkora adatbusz szignifikáns sebességnövekedést okozna (valamennyi biztos lenne, de nem sok), de ilyet nem is állított senki. Amennyiben kiterjesztik az adatbuszt, akkor mi indokolná, hogy hirtelen lefelezzék a csatornaszámot, mi abban a haladás? Természetesen azonos csatornaszámról és kétszer akkora adatbuszról van szó. Jelen pillanatban asztali gépbe csak 64-bites adatbuszos CPU-k és RAM-ok vannak, a multi-channel, meg a többprocesszoros alaplap nem változtat azon, hogy az az adatmennyiség, ami egy CPU és egy RAM modul között egyszerre mozgatható, az 64-bit.
- A hozzászóláshoz be kell jelentkezni
Hát ha nem hoz gyorsulást, akkor tulajdonképpen mindegy, hogy lepárhuzamosított 2 x 64 bitről beszélünk, vagy 1 x 128 bitről.
A NYÁK-on így sem, úgy sem lesz több adatvezeték áthuzalozva, mert tervezési és gyártási költségben az össz vonalszám a meghatározó.
(Threadripper: 4 x 64 = 256 adatvezeték, EPYC: 8 x 64 = 512 adatvezeték fut a sokrétegű NYÁK-on a CPU <--> RAM foglalatok között.)
- A hozzászóláshoz be kell jelentkezni
Akkor nem hoz gyorsulást, ha a csatornaszámot lefelezed, de mint írtam, nem tudom, hogy honnan veszed, hogy ha kibővítenék 128-bitre az adatbuszt, akkor lefeleznék mellé a csatornaszámot, mert annak tényleg nem lenne értelme.
- A hozzászóláshoz be kell jelentkezni
A kockás papír mindent kibír, simán lehet 128 bites vonalból 16-ot párhuzamosan odavezetni RAM modulhoz. Legalábbis papíron.
A gyakorlatban az 512 adatvonal CPU <--> RAM közötti átvezetése drága mulatság. Szerinted hány rétegű NYÁK-on tudják ezt megtenni?
Mindegy milyen szervezésben teszed (8 x 64 vagy 4 x 128 logikai felosztásban), ez így is úgy is 512 adatvezeték átvezetése a NYÁK-on a CPU <--> RAM foglalatok között.
Ráadásul mint nagy sebességű vezetékek, a hosszára és szórt kapacitására stb. oda kell figyelni hogy időben együtt fusson bennük az adatbit, ne csússzon el időben a kapuzó órajelhez képest.
- A hozzászóláshoz be kell jelentkezni
Az lehet, hogy nem gazdaságos, ehhez nem értek. De elméleti bővítésről volt szó, gazdasági szempontok nem voltak eddig.
- A hozzászóláshoz be kell jelentkezni
AMD EPYC 8 csatornás DDR4 kontrollere:
| Bandwidth |
Single 23.84 GiB/s Double 47.68 GiB/s Quad 95.37 GiB/s Hexa 143.05 GiB/s Octa 190.73 GiB/s |
|---|
Threadripper csak 4 csatornás DDR4 kontrollert tartalmaz.
- A hozzászóláshoz be kell jelentkezni
Ld. itt a második bekezdést. Multi-channelt 128-biten is lehet csinálni; kb. megduplázhatja a 64-bites multi-channel sebességét.
- A hozzászóláshoz be kell jelentkezni
"adatbusz az, ami 64-bites"
A cimter.
https://en.wikipedia.org/wiki/X86-64
40-bit, 48 bit, 52 bit, 57 bit...
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Olvasd el még egyszer:
Although virtual addresses are 64 bits wide in 64-bit mode, current implementations (and all chips that are known to be in the planning stages) do not allow the entire virtual address space of 2^64 bytes (16 EiB) to be used.
Tehát a címtér maga sem 64-bites. De amúgy is, buszokról volt szó, nem a virtuális címtérről; az adatbusz pedig 64-bites.
- A hozzászóláshoz be kell jelentkezni
oke ;-)
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Az, hogy 64-bites regisztereid vannak és ezért szükségszerűen csak 64-biten tudsz csak belül címezni, az nem jelenti, hogy a fizikai címtered is tényleg annyi; a wiki cikk pont ezt írta le. Aztán ott van még maga a címbusz kérdése is (ha már buszokról volt szó); tudsz mutatni egyetlen AMD64-es CPU-t, aminek tényleg 64-bites a külső címbusza?
- A hozzászóláshoz be kell jelentkezni
Montam hogy oke.
Nem akkarok terminoligain lovagolni, mert ertelmetlen. Mindketten tudjuk, hogy mirol van szo.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Ez nem terminológián való lovaglás. A címtér mérete nem ekvivalens a címzésre felhasznált regiszterek által kicímezhető tartomány méretével. Ld. még Motorola 68000 és 68010. A címzésre használt regiszterek 32-bitesek, de a fizikai címbusz csak 24.
- A hozzászóláshoz be kell jelentkezni
Ha van egy kutyud aminek a docsija azt mondja egy addot cim tartomanyrol "resrved for future use" az a cimter resz -e ?
Cimzes oda technikailag lehetseges (tudsz olyan kodot irni) es mondjuk a mukodes nem definialt (FAULT included) vagy 0 olvasas NOP iras a definialt mukodes, vagy ..
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
A reserved for future use az minden, csak nem a címtér része. Nomen est omen, az majd a jövőben lesz használva, most nem a címtér része. Meggondolhatják magukat, csődbemehetnek, más kerülhet oda, stb. 68000-esen is tudok olyan kódot írni, ami 0x01000000-től 0xffffffff-ig firkál a memóriába, lévén a címregiszterek 32-bitesek, csak éppen nem fog semmi történni, mert a címtér 24-bites. Ha valami fizikailag hozzáférhető, akkor a címtér része. Ha nem férsz hozzá valamihez, akkor hiába tudod beírni egy regiszterbe a címét; ennyi erővel 512-bites címtered is lehetne, lévén az x86-ban még 512-bites regiszterek is vannak.
- A hozzászóláshoz be kell jelentkezni
Ok, tehet ha van egy 24bites buszos kutyud ahol egy 1 cimre azt modjak hogy reserved, akkor az 23.999.. bites cimter. ;-)
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Nem. Kétszer két dolgot keversz: egyrészt a jelenlegi címteret a jövőbenivel, másrészt meg a címtéren belül fenntartott tartományokat a címtéren kívül fenntartottakkal. Ha a címtérben valami le van foglalva, az attól még a címtérben van. De az, amit a jelenlegi címtéren kívül foglaltak le, az a címtéren kívül van. A példád akkor lett volna jó, akkor passzolt volna az egyel korábbi "resrved for future use" posztoddal, ha azt mondod, hogy van egy 24-bites címbuszú kütyüd, aminek a címterét a jövőben kiterjesztik 32-bitre és a 0xfffff000-0xffffffff tartományt fenntartják jövőbeli használatra. Teccikérteni? Hiába fogják kiterjeszteni a címteret és hiába van már most lefoglalva a leendő címtérben egy tartomány valamire, a mostani címtérnek a 0xfffff000-0xffffffff tartomány továbbra sem része, mert a címtér jelenleg 0x00000000-tól 0x00ffffff-ig tart.
- A hozzászóláshoz be kell jelentkezni
FYI: A virtualitás address -ek kozepe van lefoglalva nem a teteje.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
FYI: Érdektelen, hogy melyik része van lefoglalva, amíg jelen pillanatban nincs, ami a lefoglaltakhoz fizikailag hozzáférne.
- A hozzászóláshoz be kell jelentkezni
Hany bites az ipv6 cim ter ?
Ami meg erdekes hogy manapsag sorosan megy ki cim (pcie), AFAIK magat pcie -t nem zavarja hogy a CPU mit tud latni ,
de valoszinuleg senki nem keri oda base addresst amit CPU nem er, de nem limitalt eszkozok tudnanak komunikalni.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
CPU-k címteréről és buszáról volt szó; hogy jön ide a csak virtuálisan létező IPv6, ill. egy soros bővítőbusz? Hol számít a CPU-k címtere kapcsán, hogy a PCIe-n mit hova tudnak bemappelni?
- A hozzászóláshoz be kell jelentkezni
Off: egyebkent en nem ertem, hogy a CPU-knak miert busza van. Sokkal logikusabb lenne, ha villamosai lennenek. ;)
- A hozzászóláshoz be kell jelentkezni
Vagy switch matrix -a , az jobban hangzik. ;-)
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
ARM esetén az SVE 2048 bit szélességig skálázható a gyártáskor a speckó szerint.
Ebből a világelső Fungaku szuperszámítógép procijában csak negyedét, 512 bit SVE szélességet implementáltak.
- A hozzászóláshoz be kell jelentkezni