Názory k článku První Mac s procesorem ARM: navzdory NDA unikly fotky a testy, slušný výkon x86 emulace
-
Podle mě je zásadní faktor zvolený test, který procesor nijak zásadně nedrtí, a spíše využívá testy I/O a pokud už něco počítá, tak s podporou API (OGL, Vulcan apod.), takže emulace v tomto ohledu moc roli nehraje.
Nicméně výsledky ukazují, že minimálně střední třída Maců, určená do běžné kanceláře, na ARMu běžet může (ale to samo o sobě není žádné novum - iPadPro s klávesnicí takto někteří už dávno používají.) Stále si ale myslím, že na reálnou těžkou zátěž ARM stačit nebude. -
Smazaný profil
Naivně jsem si myslel, že Apple přeloží svoje aplikace do ARMu. S tou emulací mi tedy vyrazili dech. Předpokládal jsem, budou postupovat standardní cestou. Asi na rekompilaci nemají sílu a proto postupuji tuhle nesystémovou a nešťastnou cestu.
I když je brzy něco hodnotit i tak si myslím, že obětovat čtvrtinu výkonu jenom protože použijí jiný procesor aby se zbavili spatné pověsti Intelu to je hodně nerozumné. Touhle koncepcí prakticky vytvářejí nový standard vývoje tedy x86 kód aby byl kompatibilní s Apple ARM emulátorem. Navíc se odstraňování chyb a nekompatibilit také nevyhnou. Jsem opravdu zvědavý jak tohle nakonec dopadne. Přece jenom v budoucnu může vše vypadat jinak. -
Jan Olšan (neregistrovaný)
"Stále si ale myslím, že na reálnou těžkou zátěž ARM stačit nebude."
Proč? Pokud instrukční sada není nějak špatně navržená (a ARMv8 je dobře vyvážená instrukční sada), tak není problém na ní založit výkonné jádro, hlavní je jenom návrh toho jádra, tzv. mikroarchitektura, ne instrukční sada.
To je jako bychom tvrdili, že angličtina proti němčině (nebo obráceně) se nehodí například na uměleckou literaturu, filozofii nebo na vědecké statě. -
jenže architektura souvisí s instrukční sadou - ať chceš či ne, musíš funkci dané instrukce nějak promítnout do křemíku - registry počínaje, a vlastním ALU konče. To je přece klidně i příklad AMD vs AVX, kdy implementováno sice měli, ale naprosto neoptimálně a dorovnali to až s Ryzenem.
A tady je IMHO kámen úrazu. ARM umí navrhovat malá RISCová jádra pro mobily a tablety, ale velké CPU jsou prostě pořád ještě o něčem jiném. Tím neříkám, že se nehodí do desktopů, protože běžný desktop ani dnes věci typu AVX nepotřebuje. Avšak kreslí se tím poměrně jasná a tlustá čára. PC, když to tak vezmu kolem a kolem (pokud si odmyslím stupidní segmentaci Intelu u Pentií a Celerů), bude fungovat od toho "nejblbějšího" i3 po nabušený Ryzen9/TR/EPYCa - stačí si vybrat výkon. U ARMu se budeš muset vždy nejprve kouknkout, co je to přesně za příchuť a pak ještě zkoumat, kolik křemíku bylo obětováno na implementaci a kolik je toho (potenciálně) řešeno mikrokódem, protože toto dříve či později nastane - odříznout se od ARMv7 jako to udělala v8, nebude tak docela možné, stejně jako nebude možné mít tři platformy podle typu použití. Arm se prostě dnes chová jako Nokia s Microsoftem - uvedli WP7, pak WP8 a nakonec Win10Mobile a tyhle verze, ač byly evolucí, nebyly zpětně kompatibilní, a to ani vůči aplikacím z desktopu. Výhoda "nové" platformy byla zároveň i její největší nevýhodou. -
Ne. To je tvuj jednostranny pohled. Existuji kvalitativni rozdily pri pouziti SW a HW enkodingu. To ze tobe se zda, ze vyhovuje jeden zpusob neznamena, ze vyhovuje vsem.
Pokud mas subjektivni problem s enkodingem, muzes si za nej dosadit neco jineho. Treba nekolik virtualnich stroju pro testovani, importy dat, matematicke vypocty, atd. -
Kvalitatívne rozdiely medzi hw a sw enkodingom môžu byť pri nejakých bezplatných implementáciach, kde niekto skúša použiť CUDA alebo OpenCL, ale pochybujem, že by sa našli v implementácii od Applu.
Virtuálne stroje potrebujú dostatok RAM, nie hrubý výkon procesora. Import dát potrebuje rýchlu sieťovku a disk. Aj mac mini sa dá kúpiť s 10Gb sieťovkou a diskom so zápisom okolo 3GB za sekundu. A na matematické výpočty je lepší koprocesor, ktorý si Apple upraví ako chce, ak ho potrebuje. -
V čom je horší hw encoder pre HEVC v Z12Z procesore oproti sw encoderu v iPadOS?
Už vidím, ako niekto spúšťa viacero virtuálnych strojov a v každom niečo náročné na procesor aby niečo testoval. Taký test by nedával žiaden zmysel.
10Gb sieťovka je dobrá na import dát.
Výhoda vlastného procesora je v tom, že si môže vytvoriť aj vlastný matematický koprocesor presne na tie matematické úlohy, ktoré tam budú bežať. -
Jan Olšan (neregistrovaný)
"Kvalitatívne rozdiely medzi hw a sw enkodingom môžu byť pri nejakých bezplatných implementáciach"
To teda nesouhlasím.
Ten rozdíl tam je (velký) a principiálně pramení z toho, že hardwarový enkodér (ASIC) zdaleka není tak pružný a nemá tak velké schopnosti udělat nejoptimálnější rozhodnutí mezi jednotlivými kandidáty predikcí/pohybových vektorů, kvantizérů, sílami loopfilteru a tak dál, jako to dokáže software.
S tím souvisí i že tam bývá horší (pokud vůbec nějaká) úroveň psychovizuálních optimalizací.
Řekl bych, že tohle je fundamentální faktor, který se nebude dát překonat. Samozřejmě že může existovat mizerný SW enkodér, který prohraje s dobrým HW enkodérem. Je klidně možné, že nějaká profi aplikace bude mít mizerný sw enkodér v sobě. Ale když se srovná state of the art versus state of the art, tak softwarové enkódování bude prostě mít výhodu. -
"Kvalitatívne rozdiely medzi hw a sw enkodingom môžu byť pri nejakých bezplatných implementáciach"
.. tohle je principielne hloupost co jste napsal. V cem by jako ta "bezplatna" implementace mela byt horsi? To jako ze na ni pracuji horsi programatori a apple zamestnava jen vykvet? :) Krome toho OpenCL nebo CUDA vubec nepotrebujete pro SW encoding. Doporucuji, aby jste si veci napred trochu osahal, nez o nich zacnete mluvit.
"Virtuálne stroje potrebujú dostatok RAM, nie hrubý výkon procesora."
.. tohle je dalsi hloupost. Potrebujete oboji a zavisi to od typu ulohy, kterou budete mit. Zadne obecne zavery se z toho nedeaji delat.
"Aj mac mini sa dá kúpiť s 10Gb"
.. naopak pro lokalne spustene virtualky, pokud se nebavime o serverech, zadne 10gb sitovky nepotrebuji.
" A na matematické výpočty je lepší koprocesor, ktorý si Apple upraví ako chce, ak ho potrebuje."
.. Jak muzete mluvit o koprocesoru, kdyz nevite, jaky typ matematicke ulohy budete zpracovavat. Nebo on snad existuje "koporocesor", ktery zpracova vsechny typu matematickych uloh? Nerika se mu nahodou obecne CPU? :) -
"V čom je horší hw encoder pre HEVC v Z12Z procesore oproti sw encoderu v iPadOS?"
.. ja nevim, ja iPadOS nepouzivam. Nicmene bavime se obecne a v obecne rovine vase tvzeni neplati. Vemte si Adobe Premieru pro MacOS, ta pouziva jak HW, tak SW encoding. Krome toho, existuji dalis nastroje a programy, takze Vase tvrzeni o tom, ze HW enkoder je stejne dobry jako SW je zalozen na cem? Na jednom programu IpadOS? A neni to trosku malo? :))
"Už vidím, ako niekto spúšťa viacero virtuálnych strojov a v každom niečo náročné na procesor aby niečo testoval"
.. Muzete videt co chcete, to nedela Vase tvrzeni opet pravdive. Existuje bezpocet moznosti, jak vyuzivat virtualni stroje lokalne a Vy si tvrdite, ze nepotrebuji vykon? Kde jste na to prisel, vy jste prosel vsechny mozne scenare nasazeni, ze neco takoveho muzete tvrdit?
"10Gb sieťovka je dobrá na import dát."
.. a co kdyz mam ty data lokalne, to by neslo? A jak vite, ze nebudou bottleneckem importu treba vykon CPU? Opet vy znate vsechny mozne scenare pro importovani dat, ze si neco takoveho dovolite tvrdit? :))
"Výhoda vlastného procesora je v tom, že si môže vytvoriť aj vlastný matematický koprocesor presne na tie matematické úlohy, ktoré tam budú bežať."
.. opet.. vy si vymyslite nejaky svuj idealni priklad a delate na nem zavery. Ukazte mi ten "koprocesor" ktery zpracovava vsechny ty "matematicke" ulohy, aby jste nejak mohl dokazat, ze to CPU k tomu nepotrebujete? -
Jan Olšan (neregistrovaný)
Hmm, no je pravda že totálně netuším, jaký má apple SW enkodér. Můžou mít něco licencovaného (x265 se dá licencovat pro komerční closed-source použití), ale spíš to asi může být vlastního, a pak pochybuju, že to bude špičková implementace. Třeba softwarové H.264 v Quicktime blahé paměti (2005-2010) bylo notoricky mizerné. A tehdy to byl jediný enkodér v systému, kdežto teď je ten software nejspíš jenom nouzovka/fallback.
To, že se to srovnává jenom s nizoučkou laťkou, ale neznamená, že ten hardware pořád nebude horší než dobrý SW enkodér.
Jinak teda ještě na okraj - OpenCL nebo CUDA nejsou hardwarové enkodéry, je to spíš GPGPU software pro GPU. Který teda většinou hodně trpí omezeními architektury, proto to vymřelo - tyhle GPGPU aplikace nebyly konkurenceschopné ani s čistým softwarem pro CPU, ani s hardwarem (ASIC). -
udělali to dokonce 2x
při přechodu z MC68K na PPC, kdy mezi verzemi 8.0 až 8.5 postupně odbourávali 68K kód. Tehdy byla emulace trochu jinak a k tomu frčely fat binaries (aplikace měla dva streamy s kódem pro 68k i PPC). Nicméně Rosetta pro emulaci PPC kódu byla přítomna pouze ve verzích OS X od 10.4 do 10.5 a šla ručně doinstalovat ještě do 10.6. Od "Liona" (10.7) už v systému není. -
MasoxCZ: jo, to jsou takový ty naivní představy.
koupíš předraženýho macka s ARMem a zjistíš, že je to lemra. Tak za další balík pořídíš výpočetní stroj do racku, nebo rovnou celý grid. Pak zjistíš, že to brzdí síť a začneš zařizovat 10G switch pro grid a tvého macka. A nakonec zjistíš, že ten macek ani nemá kam ten 10G adaptér připojit, tak to celé poleješ benzinem a zapálíš a jdeš koupit normálního iMac Pro nebo Mac Pro za půl melounu, protože se to nakonec ukáže jako nejlevnější řešení. :-)
-
|21. 12. 2024
Návody a tipy
23. 10. 2024
| online
31. 7. 2024
| online
6. 7. 2024
| online
