Nekem első körben egy túlhegyeztett mobil SoC-nek tűnik.

Persze oké, vannak új Oryon magok, amiknek kérdéses sorsa, hogy később leszivárog-e a mobilpiacra ténylegesen...?

-

Hajrá ARM-os PC-k, modernizálják bátran a 40 éve x86 CISC chip architektúrát!

Már pár helyen elindult a vita, hogy nem kell WIN sem, mehet az asztali gép Android alapokon is. Samsung DEX és Huawei asztali mód már ma is hozza a PC élményt, ha nagy monitorra kötöd és BT-s billentyűzetet és egeret használsz. A legfontosabb szoftverek már megvannak Androidon: office, böngésző, total commander. 99%-ban ma is ezt használom vállalati laptopon, PC-n. A maradék 1% meg kb játék, ami mehet konzolra.

Így ugyan kerülő uton, de végre betör a Linux desktopra.

[ Szerkesztve ]

Azért pár PCI-E 5.0 igazán elférhetett volna egy 2023 év végi újdonságban.

Én kérek elnézést!

Az a felület Androidon, amit touch-os mobil használatra terveztek, csak pár réteg a megjelenítésben, simán cserélhető, ahogy Samsung és a Huawei is megtette már. (ez egyébként nem egyedi ötlet, linuxon az X-en is cserélgetheted az ablakozó felületet a teljes képernyőt kitöltő buta ás kis erőforrás igényűtől a teljes WIN szerű ablakozós felületig)

Ezen kívül a teljes ökoszisztéma egy módosított Java virtuális gépen fut, ahol megint bármit cserélgethetsz a motorháztető alatt és lassú energiahatékony működésből bármikor válthatsz a nagy teljesítményre anélkül, hogy az app markethez hozzá kellene nyúlnod.

[ Szerkesztve ]

Lényegében szerintem ez lesz a gen4. Ezért is írtam tegnap a gen3 témába, hogy az inkább egy gen2+, mert a durvulás jövőre érkezik.

"Ez nem változtat azon, hogy tisztességtelen dolog botokkal felvásárolni 160-180e indulóáron a 3060 Ti-t, aztán 250e-ért árulni a HA-n." Ez miért lenne tisztességtelen? Te is meg bárki lesheti botokkal a boltokat, ugyanúgy meg tudod venni a cuccot azon az áron, mint a scalper.(1 házigazda válasz...)

Ez nyilván teljesen szubjektív kérdés, de többek közt a Raspberry Pi-ok népszerüsége miatt már évek óta nagyon sok mindent buildelnek natívan ARM-ra is Linux/BSD platformokon, úgyhogy valószínüleg egyedül Windows-on kell ténylegesen komoly kompromisszumokat kötni.

Azért a 4,6 Tflops grafikai teljesítmény elárul dolgokat. Ezt úgy 32 bites lebegőpontos számításban szokás megadni.
Nagyjából ennyit tud teljesítményben egy GTX 1060 kártya vagy egy PS 4 PRO. A PS 5 az 10,2 a XBOX series X az 12 Tflops egy RTX 3060(12 GB) az 12,6. Egy RTX 4090-es meg úgy 70-80 Tflops....... szóval nem ezen a gépen fogjuk játszani az utóbbi évek játékait úgy tűnik. Ráadásul az X86-os program kódok csak valami ARM-ra irt virtuális gépben fognak futni. Ami igen csak megnyesi az elérhetó teljesítményt. Azt hiszem a következő 20 évben is maradni fogok az X86-os PC-nél....

ez valóban így van. Az ARM-os cpu igen csak messze esik teljesítményben valós környezetben egy X86-os CPU-tól. Mondjuk egy egyszerű sebességtesztben amikor valami egyszerű számításokat kell végezni például integer számítások, prim szám keresés ciklusban és hasonlok még nem is olyan nagy az elmaradás, de egy olyan környezetben, mikor párhuzamosan sok tucatnyi folyamat közt kell meg osztani a rendelkezésre álló magokat. (multitasking) igen csak gyengén teljesít az ARM architektúra. Például jól elvan végül is egy telefonban vagy tabletban, mert ott nem szokás aktivan futtatni egyszer mondjuk fél tucat alkalmazást. Az ARM abban a pillanatban rondán alul teljesít, mikor valós feladatokat kell végezni párhuzamosan. Az erőforrás ütemezője egyszerűen nincsen azon a szinten, mint a már 40 éve fejlesztett X86-os CPU-khoz alkotott windows erőforrás ütemezője. Azért mind az X86-os CPU-ban, mind pedig a WIndowsban évtizedek fejlesztése és kísérletezése van benne....

ja de megnézted te már mi a különbség egy Androidos office és egy PC x86-os MS office tudása és lehetősségei és teljesítménye közt. Nagyjából, mint a Rózsadomb és a Mount Everest közt..... Amúgy magunk közt szólva a X86-os CPU-k egy vegyes CISC/Risc CPU-k valójában. Kifele létezik nagyjából vagy 800-850 utasítást ismerő CISC. az első X86-os CPU nagyjából 70 féle utasítást ismert. Ami végrehajtáskor gyakorlatilag átfordul egy RISC utasítás sorozat végrehajtására. Vagyis irsz a X86-os program kódba egy akármilyen CISC utasitást, mondjuk vakarja meg a töködet miközben elfügyüli a Rákóczi indulót. Közben mikor végrehajtódik ténylegesen az utasítás az aritmetikai és logikai utasítások sorozatában már lehet, hogy 388 darab egyszerübb RISC utasitást fog végrehajtani. Nem véletlenül fejlesztik évtizedek óta újabb és újabb utasítás lehetőségekkel az X86-os CPU.kat. Egy jól kitalált az életet megkönnyítő CISC utasítás azért kerül bele a CPU-ban egyszerübben és hatékonyabban lehet megoldani valamilyen feladatot vele.

Tehát az "elmaradott erőforrás ütemezője" miatt megy ennyit több szálon az M1 Max az ipari sztenderd SPEC2017-ben?

Abba az apró ténybe bele se mennék, hogy a világ kód állományának vagy 85-90% X86-os kódban készült el. 40 éve arra fejlesztenek. itt sok száz millió szoftverről van szó. de akár több milliárd kód is lehet. Ez ha képes valami emulátorban is futni ARM architekturán is erősen kérdéses, hogy mi fut le egyáltalán és mi nem. Nem lehet előszedni a világ 40 éves szoftver állományát és mondjuk újra irni és fordítani ARM-ra. Senkinek nincsen a dologra pár millió évnyi munkája és pár trillió dollárnyi pénze. Mivel a futó kódok többsége most is X86-n müködik a másik nagy csoportja valami Apple eszközön és ahhoz tartozó oprendszeren. A mai kódok döntő része továbbra is a két legnagyobb platformra készül, mert azok a leggyakoribbak. Azt gondolom senki nem vitatja, hogy egy mobil telefon applikáció szintje azért olyan mintha valaki hintalovon akarna lovas rohamot intézni a csatában.

az egy matematikai számításon alapuló integer és lebegöpontos utasítás teszt eredménye. ami nem azonos egy komplex párhuzamosan végrehajtott párhuzamos feladatokkal. Attól, hogy valami relatíve gyorsan képes kavicsokat számolni még nem lesz átalakítva a hegy valami mássá. Mert az egy sokkal komplexebb feladat. Főleg akkor, ha párhuzamosan egyszerre mondjuk fél tucat hegyet kell átszabni....

Attól, hogy én gyorsan tudok összeadni, kivonni, szorozni és osztani illetve logikailag összehasonlítani fix és lebegő pontos számokat nagy ciklusokban még nem tudok komplex feladatokat hatékonyan és gyorsan megoldani. mert ezek a tesztek ezt mérik... ezért is nevezik őket szintetikus teszteknek.... a szintetikus tesztek az alapvető aritmetikai utasításokat tesztelik, nem az olyan cél orintált utasítások végrehajtását, mint az SSE utasítások , AVX utsítások és egyebek. .

[ Szerkesztve ]

SPEC designed these suites to provide a comparative measure of compute-intensive performance across the widest practical range of hardware using workloads developed from real user applications.
A tervező házak is ezt használják, nem kavics számolás. Konkrét példád van arra, hogy "nagy ciklusokban még nem tudnak komplex feladatokat hatékonyan és gyorsan megoldani"?

Mi a probléma a Windows on ARM-mal? Szerintem épp nem azzal volt a probléma, hanem a Qualcomm szerencsétlenkedésével ezen a területen. Szerintem a macOS sincs jobban optimalizálva az Mx chipek a zseniálisak, pl a dedikált hw-es megoldások x86-64 emulációra.

ha nem gyökerek mint eddig, akkor építenek speciális megoldásokat a SoC-ba az x86 emulációjához.

hát szerintem ez erős túlzás, hogy ezzel mind foglalkozni kellene. Szerintem elég csak azokra az alkalmazásokkal ránézni amelyeket használnak, nem működnek megfelelően, nem kielégítő sebességgel működnek. Próbáltam néhány 200x-es évekbeli játékot és hogy minden is emulálva volt alatta tökéletesen és kielégítő sebességgel futott olyan felbontással, ami akkoriban álom volt.

[ Szerkesztve ]

Kicsi több info a folyamatban lévő Snapdragon Summiten, ahol lényegesen több részletet mondnak a napok folyamán.

Mindenki mást ért desktop használat alatt, az én értelmezésemben alapvetö felhasználói feladatokhoz teljesen oké már most is az ARM föleg mióta minden web és mobile first alapon készül. Ha te desktop alatt PC játékot értesz vagy valamilyen ipari célfelhasználást, akkor nem lesz jó, azt aláírom.

#15 Robitrix: Ez nem így van. A legtöbb alkalmazás kódja egyáltalán nem használ olyan low level API-kat ahol számítana, hogy x86, x86_64 vagy ARM-on fut-e a valami, ráadásul ahol használják is ott is csak a kód töredéke olyan, ahol erre szükség van. Legtöbb esetben megadod, hogy ARM-ra is szeretnél egy binárist és a compiler lefordítja neked.

A Chromebook-ok mennyire mentek? Kb. akkora jövőt látok ebben is...

A tehén egy bonyolult állat, de ÉN megfejtem...| 2016-tól az tuti, hogy az angyalok is esznek babot...

A Qualcomm a Snapdragon 8 Gen 2 SOC-ot 160$-ért árulja, és nem igényel külön hűtést.
Ez benne a fantázia.

Bocs, de az office dokumentumokat sharepointon a böngészőben nyitom meg a céges laptopomon is. Szerinted egy office-hoz mégis mekkora teljesítmény kell?

Tudom, hogy az x86 már belül mikroutasításos RISC. A WIN csodálatos ütemezőjén meg hadd nevessek már. #14-ben láthatod az eredményt.

A modern CPU architektúra és modern oprendszer teljesítménye csak attól is nagyobb lesz, ha kidobják végre a sok legacy x86 megoldást és win32 kódot.

Rendben, akkor használj olyat. Ettől még nem sokan veszik.

A tehén egy bonyolult állat, de ÉN megfejtem...| 2016-tól az tuti, hogy az angyalok is esznek babot...

Szerintem itt arra gondolt a fórumtárs, hogy az androidos (és webes) word lebutított, alig tudsz valamit elvégezni rajta a windows-os verzióhoz képest. Itt nem csak a makrókra, hanem formázási stb. beállításokra is gondolok. Egyébként jó dolog a DeX, ahogy az iPad is fejlődik, de egy laptopot csak windows-os tablet tud jelenleg kiváltani (még), ott pedig az ARM megoldások jelenleg még lassabbak.

Dede, a Mac OS végletekig rá van optimalizálva arra az egy processzor architektúrára.
És szerintem pont ez a buktatója Arm-nak minden más OS-en. Arm-ból kismillió féle proci létezik, kismillió gyártó. Míg x86-on még a két gyártó procijaihoz is nehézkes az optimalizáló, akkor mi lesz ha 5 felé gyártó Arm procijaihoz kellene majd optimalizálni?

Én kérek elnézést!

Csak még egy gondolat: ha a compiler-nek a forráskódot először CISC utasításokra kell lefordítania, majd azt egy mikrokódnak a prociban RISC utasításra, az biztos kevésbé hatékony, mintha a compiler a forráskódot egyből RISC utasításra fordítaná, hiszen fordításidőben bármekkora teljesítmény rendelkezésre áll, hogy megfelelően optimalizálja a kódot.

Ez nem igaz, az ARM saját kézben tartotta az ARM architektúra utasításkészletét [link], valamint a legtöbb gyártó átvette a Cortex magok design-ját is.

Tesztek:
Anandtech
XDA
Android Authority
Notebookcheck
Windows Central
Stb...

[ Szerkesztve ]