A linuxos programok szinte mindegyike le van fordítva ARM-ra is. A windowsos programoknak csak az elenyésző kisebbsége létezik ARM-ra. Emiatt az ARM-os világ jelenleg csak a linux irányából tud terjeszkedni.

Az más kérdés, hogy attól még, hogy ezek a programok armos linuxon is elérhetőek, nem lesz jó a teljesítményük, egy x86-64 alapú gépen azért sokkal jobb teljesítményük lesz.

Azaz, még mindig valami pilot fázis van csak Windows ARM-ból, és egyenlőre nem nagyon akarnak belőle eladni. Meg én azt hittem a Qualcomm exkluzivitás már az előző generációval véget ért... Persze nem tudom, lenne-e egyáltalán versenyző. Így persze nem is tudjuk meg.

"aminek a készítői nem töltöttek el 4-5 évet az ARM-ra való optimizálásban"

Már megint ezt az ostobaságot nyomod, mikor jópárszor el lett mondva, hogy ez pár ritka esettől eltekintve nem létezik. Azon kívül mennyit optimalizál egy programozó x86-ra? 99.99%-ban semennyit. Megríja, mondjuk C++-ban (de lehet, hogy C#, Python, JavaScript, stb.) és kész. Az optimalizáció, hogy úgy általában az algoritmust, adatstruktúrákat, architektúrád jól tervezed. A fordító/interpreter intézi a többit, nincs is beleszólásod abba, hogy a ISA szintjént ez mi lesz.

Jól hangzó ökörségeket meg vágyvezérelt gondolatokat a csodálatos compilerről bárki le tud írni. Indíts el rajta egész nyugodtan egy libreofficet, gimpet, kdenliveot, aztán majd nagyon hamar találkozik az elméleted a valósággal, egy 10-40szeres sebességkülönbség formájában.

Nem hiszem, hogy egy átlagos C vagy C++ projekt normális fordítóval nagyságrendi különbségeket hozna.
Szerintem a külsős libek (vagy külsős libek összeakadása) jelenthetnek csak problémát és azok is csak azért, mert ARM-ra lehet eddig kevésbé voltak kitesztelve, mint x86-ra. Pl. más ütemezésre voltak kifejlesztve, más sorrendben hívják őket stb..

Szoftverfejlesztőként mondom, hogy az esetek 90%-ra kivetítve ddekany és freeapro fórumtársaknak van igaza és te írsz baromságokat marha nagy egoval és magabiztossággal (lásd aláírásod).

Számtalanszor láttam a gyakorlatban mind munkában, mind hobbi projektemnél, hogy a korszerű eszközökkel fejlesztett szoftver amit x86-on fejlesztettünk és teszteltünk, natív ARM-re (Apple Silicon) fordítva is gyönyörűen működött, még gyorsabban is annyival, amennyivel az M2 chip gyorsabb volt az előzőleg használt korai Ryzennnél.
Persze vannak kivételek, de azok nagy része eleve alacsonyabb szintű, architectura specifikus optimalizációt igénylő dolog (pl. OS kernel, 3D engine akár játékhoz akár máshoz, stb.), meg esetleg néhány szarul megírt őskövület amit példának hoztál. De az elmúlt szűk 10 évben írt C#, Go, Python, Java, JavaScript, stb. (de akár C++) crossplatform nyelveken írt üzleti szoftvereknek, webes kódoknak fikarcnyi hátránya nem származik az ARM-re való fordításból. A JavaScript kifejezetten imádja az ARM chipek brutális egyszálú teljesítményét az őskövület x86-al szemben.

Apple-nél a 2020-as ARM-re váltás előtt se gondolnám, hogy 0-ról írták újra az egész macOS-t és egyéb saját szoftvereiket.

[ Szerkesztve ]

Attól még, hogy hárman jöttök a boráztatta "korszerű fejlesztői eszközeitekről" szóló anekdotális hülyeségeitekkel, és random generátor által összegenerált 80 és 99 százalékaitokkal, még nem lesz igaz, amit írtok.

Főleg, hogy engem akarsz egoizmussban vádolni, miközben úgy kezded a mondandódat hogy te szoftverfejlesztőként mondod, a másik meg ,,a másik topikban is ez meg ez".

Bárki, aki akár csak egy raspit használt 5 percnél tovább (legyen mondjuk 4 magos, armv8as), bármilyen célra, meg tudja mondani mondani, hogy egy azonos paraméterekkel rendelkező (4 magos x86-64) rendszerhez képest egy-két nagyságrenddel lasabb MINDENBEN.

Ja, mondjuk a calculatorban, meg a mousepadban nem... Vagy talán úgy jött ki a 80%, hogy ezeket is beleszámoltad?

Persze ehhez látni kellett ilyet, nem cikkben kellett olvasni.

natív ARM-re (Apple Silicon
Szerinted az apple windowsos arm processzorokat készít? Érted, hogy miről szól egyáltalán a cikk?

Továbbá fejlesztőként illene azt tudnod, ha már így kezdted a mondandódat, hogy az apple processzora eleve nem arm dizájn, hanem az apple saját szuperskalár out of order risc processzora, amely az arm utasításokat mikrokódra fordítva hajtja végre, semmi köze nincs a qualcomm meg a többi gyártó processzoraihoz semmilyen formában sem.

A kedvencem, hogy a példákat őskövületnek nevezed (libreoffice, gimp, stb), miközben minden egyes létező irodában, közhivatalban úgy kezdik a napot, hogy dokumentumokat nyitogatnak, scannelnek, képeket dobálnak rá, ugyanis DOLGOZNAK a gépen, nem a háttérképet nézik rajta, meg a macskás videókat facebookon. Hogy ez miért releváns? Mert ez a lényege azoknak a windowsos notebookoknak, amikről a cikk szól, és nem a 3d játékok, meg a javascript, ami inkább a tartalomfogyasztó eszközök sajátja - ettől függetlenül, a 3d gaming területén nem mellékesen szólva az amd/intel/nvidia megoldásai megint csak több nagyságrendnyi előnyben vannak az armos gyártók megoldásaival szemben, vagy te komolyan azt gondoltad, hogy egy snapdragon, meg egy nvidia 4050 mobile egy szint?

[ Szerkesztve ]

Ez alapján a hardverhez is pont annyira értesz, mint a szoftverfejlesztéshez.
Ha neked 2 CPU összehasonlítása kimerül a magszámban (4 magos Raspit hasonlítasz egy 4 magos x86-hoz), akkor kár is tovább erőltetni. Van itthon Raspi 4 és ASUS Mini PC is. Az 1 Ghz-en üzemelő passzív hűtésű 2 magos ASUS PN41 Mini PC is lényegesen erősebb volt a legújabb Raspi 4-nél. Nem az ARM-re való fordítás gyengeségei miatt lassúak a dolgok Raspin, hanem mert egy egy kiherélt gyenge gép olcsón, hobbi célokra. Ettől még imádnivaló, csak hülyeség keverni az ott látott tempót azzal, hogy az ARM mire képes valójában.

"apple processzora eleve nem arm dizájn, hanem az apple saját szuperskalár out of order risc processzora, amely az arm utasításokat mikrokódra fordítva hajtja végre, semmi köze nincs a qualcomm meg a többi gyártó processzoraihoz semmilyen formában sem."

Azt hiszed okosat mondtál, de ez az összes mai processzorra igaz, ARM-re és x86-ra egyáltalán. Mindegyik végtelenül komplex módon, többek között mikrokóddal valósítja meg a hardver szintjén a logikai architektúrát (értsd: utasításkészletet). Egy Ryzen és egy Core i7 is full különböző, mégis mindkettő x86-64. Ugyanígy az Apple Silicon és egy Snapdragon is ARM, hibába teljesen különbözőek a vas szintjén.
Képes vagy átlátni ezt az absztrakciót a konkrét vas (fizikai archi) és az utasításkészlet (logikai archi) között? A magas szintű nyelveken írt szoftvert operációs rendszer és CPU architektúra kombinációjára fordítják (pl. Windows-x86). Hogy alatta ki a CPU gyártója, azon a szinten marhára lényegtelen.

"minden egyes létező irodában, közhivatalban úgy kezdik a napot, hogy dokumentumokat"
Igen, túlnyomó többségében Office 365, Google Workspace és társait használnak. Eddigi 3 munkahelyemen az életben nem láttam senkit LibreOfficet használni, feleségem ugyanezt vallja az ő tapasztalata alapján. Az, hogy te a Raspi 4-et használsz fő PC-nek LibreOffice-al és ez lassú és nem kényelmes, az az egyéni mazochizmusod, ne vetítsd ezt ki a világra.

Más fórumokban más témákban is láttam már a flegma stílusod, munkásságod, kár a gőzért. A PH fórumokon való trollkodáson és flamelésen kívül pontosan mit is dolgozol?

[ Szerkesztve ]

Én informatikusként dolgozom, csak az elmúlt két hétben több helyen voltam munkaállomásokat karbantartani és telepíteni, mint ahány helyen te egész életedben dolgoztál a saját bevallásod szerint.

Az, hogy elkezded ugyanazt leírni, mint én, csak hosszabb verzióban (utasításkészlet) még nem tesz téged hozzáértővé. Mivel fogalmad nem volt arról, hogy az apple nem az arm dizájnját használja, ezért is hozakodtál elő vele először, most meg megpróbálod kimagyarázni a hülyeségedet, és elegánsan hallgatsz róla, hogy windowsos arm gépekbe az apple dizájnjai nem fognak bekerülni.

A hozzászólásomból alapvetően semmire nem sikerült reagálnod, azon kívül, hogy valahogy úgy próbálod félremagyarázni, hogy én raspit használok fő pécének.

Halihó! Jó reggelt, Raspberry PI-re HIVATALOS windows 10 is létezik ám! Gőzöd nincs arról, hogy miről beszélsz, ezekről a platformokról szól a cikk!

A pökhendi okoskodásodat, hogy ki mihez ért, meg nem ért, meg javaslom, hogy vidd máshova, csak nevetségessé teszed magad.

[ Szerkesztve ]

Minnél alacsonyabb szintű funkcionalitást kell megvalósítani a librarynak, annál nagyobb lesz a hátránya az x86-al szemben. Például nem mindegy, hogy egy igazítatlan 64 bites számérték regiszterbe olvasása 1 opkód (x86-64), vagy 8 + 8 +1 (arm). Nincs az a memória és regiszterbackend, ami ezt hatékonyan el tudná rejteni.

"csak az elmúlt két hétben több helyen voltam munkaállomásokat karbantartani és telepíteni, mint ahány helyen te egész életedben dolgoztál a saját bevallásod szerint."

A pizzafutár is ha kimegy 20 címre az 20 munkahely tapasztalata ugye?

"Mivel fogalmad nem volt arról, hogy az apple nem az arm dizájnját használja"
Mi ez a baromság? Az ARM egy licenszelhető logikai architektúra, amihez lehet adnak egy referencia implementációt iránymutatásnak és kereteket, de minden gyártó úgy valósítja meg, ahogy akarja és tudja a kereteken belül. Qualcomm, MediaTek, Apple Silicon, ezek mind mind ARM chipek, a konkrét chipek sokban különböznek a fizikai megvalósításban, de ez lényegtelen mert mind ARM kompatibilisek. Ezen mit nem lehet ennyi hozzászóláson keresztül megérteni?

"elegánsan hallgatsz róla, hogy windowsos arm gépekbe az apple dizájnjai nem fognak bekerülni."
Ezt kell bárkinek is magyarázni, hogy az Apple saját hardvere csak Apple gépekbe kerül? Azért releváns itt az Apple Silicon, mert egy élő példája annak, hogy komplett ökoszisztémát OS-el mindennel együtt át lehet mozgatni x86-ról ARM-re úgy, hogy még a teljesítmény is javul, nem csak az akku idő. A cikk is erről szól, csak Windowsos laptopokkal kapcsolatban. Ott is menni fog ez, csak idő kell. A LibreOffice meg senkit nem érdekel mindeközben, aminek az ARM teljesítményével kapcsolatban rinyáltál.

Off:
Egyébként gőzerővel és sikeresen dolgoznak azon, hogy Apple Siliconon natívan fusson a Linux. Virtuális gépen szintén megy és jól működik a Windows 11 ARM változata Apple Silicon gépeken. Sőt, hivatalosan támogatott a Microsoft által: [link]

"A pökhendi okoskodásodat, hogy ki mihez ért, meg nem ért, meg javaslom, hogy vidd máshova, csak nevetségessé teszed magad."
Pont abban a stílusban beszélek veled, amit te képviselsz itt régóta számos topicban és ahogy itt is indítottál másokkal.

[ Szerkesztve ]

Én telepítem a gépeikre a szóban forgó libreofficet, nem a pizzát hordom nekik. Ha nem futnak rendesen valahol a megszokott programok, az a platform halálra van ítélve.

De mindegy, lehet, hogy én voltam kissé agresszívabb a témában, mint kellett volna, de nem írtam rosszallóan senkire, én a technológiáról beszéltem, amit te, és még két másik ember magára vett. Legközelebb majd figyelmesebb leszek.

Egyetérteni nem fogunk, egyébként a puding próbája az evés, és ez a puding nagyon nem lesz finom.

"lehet, hogy én voltam kissé agresszívabb a témában, mint kellett volna"
"egyébként a puding próbája az evés"
Végre valamiben egyet tudunk érteni.

Rendes kockaként és kütyümániásként van itthon minden és próbálgatom őket rendesen, és pont ez alapján mondom, hogy az ARM a jövő. Irodai szoftverek (Office 365, Zoom, stb.) legalább olyan jól futnak az ARM alapú Mac Minimen, mint a Windowsos laptopomon x86-on. Ugyanez elmondható a hobbi projektjeimről és azok fejlesztői környezetéről (C#, Visual Studio, Docker, Postgres, stb.). Sőt, még maga a Windows 11 ARM változata is fut virtuális gépen az ARM-es Macen Parallels-el, és bizonyos feladatokban jobb számokat hoz, mint a Ryzen 6800H-val (x86-64) szerelt laptopomon natívan futó Windowson ugyanezek.
Ha ez itt így összejött, miért ne sikerülhetne ez Snapdragon (és más) ARM chippel szerelt laptopokkal, natív Windows 11 ARM támogatással?
Menni fog, és jobb lesz, mint a bő 40 éves x86 további toldozása/foltozása. A teljesítmény mellett a hatékonyságról már ne is beszéljünk, ARM chipes laptopok röhögve hozzák a 15-20 óra körüli üzemidőz munkában, a gyakorlatban. A MacBookok már 2020 óta.
Ha valami lassabban fut ARM-en, mint x86-on, ott az adott szoftvert kell kalapálni, de személyes tapasztalatom szerint marhára nem ez lesz a többségi eset.

[ Szerkesztve ]

Nem tudom, hogy mi hány opkód ARM és x86 rendszerekben, de a mai modern processzorokban már 3 szintű cache van, így biztosan nem ez adja a futásbeli különbségeket. Főleg nem OOO utasításvégrehajtásnál, ahol ez mind ki van optimalizálva. De ezzel nem is kell foglalkozni, azért programozunk C és C++ nyelveken, hogy mindezt a problémahalmazt eltakarja előlünk, és egy másik absztrakciós szinten gondolkodjunk.

Tudom nehéz meggyőzni vidéki önkormányzatok rendszergazdáit, mert ők mindenhez is jobban értenek. De én már programoztam Windows, Linux, Android, Solaris, HP-UX rendszerekben, Basic, Assembly, C, C++, Pascal, Modula-2, Forth, Java, Plex, Erlang, C#, TCL, Python nyelveken. Ezért azt gondolom és is valamennyire értek hozzá.

Nem mondtam olyat, hogy nem értenél hozzá... A feltételezésed, ami alapján azt gondolod, hogy oop kód esetén épp ezek lennének kioptimizálva, viszont túl optimista. A te magas szintű oop kódod optimizálódik ki, meg ami jól fog még futni, azok az adatbázis szerű műveletek, ahol pointerekről vagy osztályok példaányairól példányaira ugrálsz, vagy egyszerűen dolgokat címezgetsz. De egy olyan library vagy forráskód már nem, ami mondjuk egy armra nem külön ráoptimizált dekóderrel csomagol ki valami nyersanyagot/resourceokat/pl képet/valamit kitömörít/ betömörít/különféle nem alignált transzformációkat/nem az archnak megfelelő szélességű deltákat vagy bitszélességeket használva, hát hát pont ezek a sebességkritikus részek rengeteg programban. És minő meglepetés, ezeken vérzik ki az arm architektúra általában, mivel az egy végletekig egyszerűsített load-store architektúra. Onnantól kezdve az ilyen kódot vagy vért hugyozva valahogy armra optimizálják, vagy nem lesz optimizálva (általában nem is szokták, hanem pont a leg naívabb c kódra ifdefelnek vissza, hogy egyáltalán működhessen), akkor viszont hiába várod a jó teljesítményt pusztán attól, hogy a deklarációidból fakadó kód overheadje nem roszabb rajta, mint x86-on.

nem a többiek nevében írtam amit írtam...

az OS adott, én meg szívesen váltanék architektúrát. ennyi.

hát de ezek intelek, lol

Papa, amúgy ezek Inteles laptopok, ahogy a kolléga is írja. Akartam is mondani, csak közben elment más téma irányába a topik és nagyon elvesztem benne én is.

Ha Arm laptopos linket tudsz, akkor azt megköszönjük. Amúgy a további probléma ezekkel az Arm laptopokkal, hogy elméletben léteznek, de egyszerűen olyan ritka, mint a fehér holló. Ha talál is az ember, azt tényleg csak ilyen nagy piactereken mint pl. az Amazon talál. Itthon szerintem még ilyen "hülyevagyokáruházban" sem találsz.

Részben igaz.
Én pl. szerettem volna egy Thinpad x13s G1-et, de kb. csak egyedi rendelésre van.

Nekem a Samsung Galaxy Book sorozata tetszik.

Qualcomm Says Its Snapdragon X Elite SoC Will Destroy Intel's Meteor Lake. The company had previously only compared it with Intel's 13th Generation processors. In late 2023, Qualcomm announced it would soon take on AMD and Intel in the laptop world with its newest Arm-based SoC, the Snapdragon X Elite.

Hü.

[ Szerkesztve ]

Ahogy nezem a Qualcomm HQ-ban valoszinuleg 24/7 ez ordit a hangszorokbol [link]

Erre én azért befizetek. De ha sikerülne, a handheld gaming piacnak mondjuk nagy hasznára lenne(Steam Deckre gondolok konkrét pl.)

nem fog, a gpu-val elhasal az egész. azé bármennyire is fostos a radeon is, az amd socoknak a legnagyobb előnyük az.

Azért nem olyan biztos, mert ott van az Nvidia Tegra X1, a mostani Adreno az Qualcomm Snapdragon Eliteben azért már jóval erősebb, s arra a Tegrára anno egy konzolt épített a Nintendo.

Kíváncsi lennék azért én is valami valódi 3Ds applikációra vagy játékra valós időben Adrenon Windows vagy Linux alatt, hogy ott mit mutatna mondjuk akár az Intel Xe vagy Radeon Mobilehez képest.

[ Szerkesztve ]

A nintendo gaming és a Steam Deck gaming nagyon más kategória. S ráadásul az általad említett nVidia Tegra X1 is konzervatívabb immediate renderer, szóval szoftveresen portolásnál ilyen szempontból nem igényelt különösebb törődést.

Az Adreno pedig továbbra is egy tileos architektúra. Ha nincs rá igazítva a renderkód, lehetnek problémák.