Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Tak zatím co doposud Apple vždy přecházel na výkonnější platformu (MC68k -> PPC -> x86), nyní je to "sešup" na horší, zato levnější.
Jsem zvědavý, zda to jablečné ovce sežerou.
Ich mobilne AMRy ale nemaju taku plochu/chladenie ako by sa mohlo dat napr. do macbooku pro. Vobec nevieme ake takty a IPC z toho vytiahnu, ak si budu moct dovolit 15W TPD a nasobne viac tranzistorov.
S tim vykonem neblazni, to je zcela nerealne, ze by Apple dokazal vyvinout vykonejsi procesor nez je RyZen nebo Coffee Lake.
Spis to bude o tom, ze Apple veri, ze do 2020 vyvine procesor s dostacujicim vykonem na beznou praci, ktera je u uzivatelu MacBooku rozsirena. Pokud se to podari, tak uzivatele nebudou mit duvod prechazet jinam. Tezko lze ale ocekavat, ze by snad Apple defiloval vykonem.
"S tim vykonem neblazni, to je zcela nerealne, ze by Apple dokazal vyvinout vykonejsi procesor nez je RyZen nebo Coffee Lake."
Slavná poslední slova? :) Uvidíme...
ARM platforma nema sanci. Docela je mozne, ze bude k x86 konkurencni, protoze dneska spouste lidi staci x86 Atomy a tomu muze ARM hrave konkurovat, ale ze by ARM treba i ve spolupraci s Apple dali vykon procaku jako je RyZen 7 2700X nebo Coffe Lake i7-8700K, ani nahodou tomu neverim.
No vzhledem k drobnemu faktu, ze Cavium ThunderX2 ma vykon na jadro v prumeru stejnej jako 18-ti jadrovej Broadwell, neverit muzes klidne dal..
To jako vazne? Ze to nechces srovnavat s desktopovym ci WS CPU? Mimochodem nejaky odkaz na test s realnym nasazenim by nebyl?
> Ze to nechces srovnavat s desktopovym ci WS CPU
Srovnavam serverove CPU vuci serverovemu CPU, oba na pomerne nizkych frekvencich. Vite o nejakem zasadnim duvodu, proc by Apple nemohl udelat podobny navrh CPU, nataktovat ho na 4GHz a nechat si to vyrobit u Samsungu / TSMC ? Slycham tady spoustu hlasek o tom, jak Apple nemuze vyrobit ARM s podobnym vykonem jako x86, pricemz vsechny tyhle "argumenty" lze shrnout dvema slovy: "neverim tomu".
> Mimochodem nejaky odkaz na test s realnym nasazenim by nebyl
mimochodem jsem cekal ze lidi na technickem portalu umi googlit.. evidentne jsem se mylil. Tak pro zacatek: https://www.nextplatform.com/2017/11/13/arm-benchmarks-show-hpc-ripe-pro...
jinak Gigabyte uz prodava tusim 2U servery s timhle CPU, plus nekolik firem nabizi virtualky v klaudu. Je to pro vas dostatecne "realne nasazeni" ?
To next jsem nasel tez a prijde mi to jako silne nedostatecne....proto jsem se ptal jestli neexistuje lepsi "mereni" ktere by ukazalo univerzalnejsi potencial navrhu i mimo danou oblast nasazeni kterou apple zrejme neplanuje .. to ze v danem segmentu nabizi slusny potencial je celkem logicke vice jader i vyssi takt a uzce specializovany navrh tomu prispiva ...bylo by divne kdyby tomu tak nebylo :)
Jenže právě srovnání serverových CPU je pro použití v desktopu naprosto zavádějící. Na serveru běží typicky jedna hlavní služba, která masivně multithreaduje, takže z ní těží mnohajádrové CPU typu (historicky na tom takto "vydělávaly" SPARCy), kdežto na desktopu se jedná o multitasking, kde se navzájem střídá větší množství konkurenčních procesů bez schopnosti zasadnějšího threadování, kteréžto s rostoucím počtem jader zase tak dobře neškálují.
Sám jsi odlinkoval přesně takový zavádějící test, který je pro použití v desktopu úplně k ničemu - takže prosím, šetři s hláškami o googlení na technickém portále.
Pochybujem, ze Apple chce konkurovat svojimi ARMami 95W monstru na skoro 5GHz. Porovnaj to s tym, co davali posledne roky do macbookov (2jadrove Hasswelly s 15W). Ludia na takychto strojoch strihali videa, programovali v tazkych IDE a pod.
Ale oni se nevyrovnávají jen Ryzenu nebo Coffee Lake, oni musí najít náhradu za Xeon W
Napadá mě taková myšlenka. Všichni řeší že to bude ARM platforma což nikde nebylo oficiálně řečeno. Nemohlo by se jednat o custom apu na bázi AMD podobné jak používá Sony nebo Microsoft v konzolích? Nějak si moc nedokážu představit že bych na Macbooku pro kompiloval projekt na ARMu.
To by bylo dobre pro AMD, ale ne uz tak pro Apple, ze by se Apple obratil s resenim procesoru na AMD neverim. Ale jiste bylo by to velmi zajimave, kdyby neco takoveho nastalo.
> Nějak si moc nedokážu představit že bych na Macbooku pro kompiloval projekt na ARMu.
Ja si to naopak predstavit dokazu. Co koukam testy druhe generace Cavium ThunderX, tak vykonem je to na urovni intelackeho Broadwellu. FPU o neco horsi, pamet naopak lepsi. Vsichni maji nejak zafixovano ze Intel ma patent na rozum, a jedinej umi delat rychle procesory. Horseshit... a Intel v IPC udelal poslednich pet let hovno. Je jen otazka casu nez jej ostatni dozenou.
Proto jsem rád, že se iniciativy ujalo AMD. A nutí Intel něco dělat (prozatím alespoň přidávat jádra). Uvidíme, s čím Intel vyrukuje proti ZENu 2/2+.
Je pravda, že o ARM se nepsalo, ale na druhou stranu se psalo o tom, že mobilní a Macová platforma budou interoperabilní, což by znamenalo tak jako tak kompatibilitu s ARM. Jediné, co mě (mimo emulace) napadá, je troj-čip, tj. nějaké APU od AMD s x86 i ARM jádry plus grafika. To je IMHO ale hodně šílená konfigurace..
Ikdyž o takové kombinaci se už nějakou dobu šušká.
Mně to připadá jako Commodore 128 nebo Sidecar do Amigy 2000 :-)
To byly časy... 128D jsem měl doma.
C128 jsem měl jen půjčenou, jinak jsem vlastnil set C64-II + C1541-II + Star LC10 :-)
Ve své době to byla pecka. :-))
Jak se jmenoval ten projekt AMD, kdy vyvíjeli kombinaci ARMu a X86? Dočasně ho pozastavili kvůli dokončení ZENu, ale jsem si jistý, že po jeho vydání (a úspěchu), ten projekt běží dál. I ten časový rámec by tomu odpovídal (2020).
no, on ten ARM je myslím i v Zenu - jako security processor (takže fyzicky je přítomen, jen jinak, než o čem tu mluvíte)
Špatné zpráva...už dnes aby člověk pohledal trochu kvalitně provedený notebook....
Jiří, dobře napsaný software není potřeba přepsat, takový stačí jenom překompilovat. Problém by byl s x86 assemblerem, ale toho tam bude počítám množství menší než malé.
Až takový najdeš dej vědět.
Tady jich máš přes 51 000:
https://www.debian.org/
Ale no tak.
Copak, některý z nich ti nefunguje na nějaké architektuře? Mně jede zatím všechno, jenom jsou ty ARMy hrozné plečky.
Jo i ne...tak lehke to neni. Vem si, ze dneska jakykoliv soft potrebuje nejake knihovny nebo dokonce cele frameworky a jeste knohovny, pod kterym funguje. To znamena, ze napred museji byt prelozene a odladene vsechny tyhle veci.
O necem, co funguje na urovni assembleru nebo vola nejake low level API/routiny OS ani nemluve...
To je ovšem typická Windowsí probelmatika. Jsou operační systémy, které jsou rozmáchnuté přes více CPU platforem a umí s tím žít.
O tom mi povídej. Když zkompiluju na android tak je tam stejně device specific bugů na posrání.
To sice jo, ale ty jsou device - specific. Z nich bude architecture - specific jenom mizivý zlomeček a řekl bych, že je dost velká šance, že pro velkou většinu aplikací se nebudou vyskytovat vůbec.
Tak je rozdíl pokud děláš chujovinku s příkazovou řádkou nebo 3d hru.
I tam se budeš imho bitkovat daleko víc s verzemi OS nebo OpenGL nebo s různými GPU. Problémy s architekturou CPU budou proti tomu dětské prdění do vody. Rozhodně nic, kvůli čemu bys to musel přepisovat.
(Já dělám GUI aplikace, něco jako software pro bankomaty - na ARM nebo x86, Linux, android, Windows, teoreticky i iOS nebo MacOS. Problémů s CPU mám ... teď se musím zamyslet ... zatím nula.)
Pro zajímavost, na čem staví GUI? Qt nebo nějaké Chromium HTML5 cosi či něco jiného?
Je to v kivy. Qt bylo v užším výběru, ale prohrálo "o prsa". HTML5/javascript jsme moc neuvažovali, protože renderer by na slabším hardware mohl způsobovat výkonnostní problémy, kivy je v tomto větší jistota. Navíc mám rád, když se prvky GUI vytváří kódem - jsem oldschool, toto je už možno považovat za úchylku. :-)
Dík, zrovna jsem se na kivy dnes díval a přemýšlel, nakolik je použitelné. Přeci jen mají na stránkách v ukázkách samé hry, což nepůsobí moc důvěryhodně. Kód vypadá docela pěkně.
O'Reilly k tomu vydali knížku, tak to musí být dobré. :-) (BTW je 4 roky stará, tzn. asi nekupovat.)
Ne, vážně. My jsme nic extra nepotřebovali, děláme k tomu doplněk k ERP systému, kde uživatel obecně zadá nějaká data, na něco se podívá apod. Používá se to nejčastěji ve výrobě nebo ve skladu, kde si lidi pípnou čip, napíší, kolik vyrobili kusů čeho, nebo ve skladu pípnou šarži, cílové místo, množství, systém přeskladní. Ovládá se to opravdu podobně jako bankomat - vše je typicky borderless fullscreen, uživatele se to ptá na jednu volbu (např. "načti šarži"), on ji načte nebo zadá, zobrazí to nějakou informaci nebo menu nebo se to zeptá na něco dalšího.
Na mobilu nebo tabletu to vypadá víceméně jako normální mobilní aplikace, na PC takto aplikace typicky nevypadají, ale bankomat taky nevypadá jako PC a lidi ho používají. :-) Kód je jenom jeden pro všechno stejný, build proces se samozřejmě pro platformy liší.
Ve výrobě používáme typicky stacionární dotykové "kiosky", hardwarem je nejčastěji dotykový panel z bankomatu (dovoz z Číny), který obsahuje klasické PC - buď s Atomem, nebo nějaký Celeron, 32GB SSD, 1 nebo 2GB RAM. Tam to běží typicky na Linuxu nebo Windows - ono je to vlastně úplně jedno, kromě boot procesu je to pak úplně stejné, jenom Widle už to těžko dávají a furt se aktualizují a boot trvá dlouho a tak, když se tam prdne Debian s LXDE, je po starostech, než to někdo hardwarově rozfláká. Teď pro redukci nákladů (resp. spíš zvýšení zisku :-) nabíháme na Raspberry Pi plus dotyková obrazovka bez PC - Píčko základ kivy zvládá v pohodě, otázkou je, jaká bude user experience při zobrazování a zoomování výkresů.
Dalším zařízením, které používáme - například ve skladech - jsou přenosné věci. Nejčastěji tablety s androidem, nebo zase z Číny vozíme v podstatě telefon (mobil) s integrovanou 2D čtečkou barcode. Nebo třeba normální android mobil.
Teď jsem bral na Benzině a mají na stojanu místo těch LCD displayů normální (nedotykový) monitor, tam běhají při tankování různé obrázky, teda kromě litrů a peněz. Kdybych to měl dělat já, přijde mi to jako ideální zadání pro kivy.
(Pointa té naší aplikace je v tom, že je to vlastně jenom hloupý klient. Ze serveru jí přijde XML, jaké prvky se mají na obrazovce zobrazit a když uživatel zadá nějaký vstup, pošle to na server a dostane další XML s novou obrazovkou. Takže nemusíme samotné aplikace "upgradovat", vše se děje a spravuje na serveru. Asi jako HTTP/HTML, ale víc "na míru" danému účelu a zařízení.)
Tomu s těmi knihovnami moc nerozumím - na x86 mám knihovny pro x86, na armu budu mít ty stejné pro arm, ne?
A jakože když nějaká společnost třeba zanikne a veme s sebou do hrobu i zdrojáky a nebude tím pádem možné přeložit nějakou knihovnu pro ARM? To je možná dobrá chvíle zapřemýšlet nad tím, že by bylo dobré takovou knihovnu nahradit nějakou živou alternativou.
To ano, ale urcite ne vsechny knihovny/frameworky jsou plne "platform cross over". Muzou na urcite platforme bud chybet nebo jsou tam mezi nima nuance, jako ze to byva. To je prvni vec. Druha je, ze ty stejne vyvojove nastroje musi existovat na obou platformach uplne stejne. A treti vec je, ze kdyz se zacne delat neco "specialniho", tak se zacnou volat nejake low API, ktere jsou temer jiste "platform dependent" a tam se musi manualne kod upravovat.
Jak je to napriklad s volanim grafickych API jako je Vulkan a podobne netusim. Ale treba DX12 jsou pry taky 'ruzne' verze pro Xbox a pro Win10, takze porad je potreba neco manualne doupravovavat.
Tim jen chci rict, ze jak hladce to pujde, zalezi hodne na konkretnim pripade. Nekde to bude hladce, nekde moc ne..
(double post ,sry)
Jenomže takto to dělají jenom v MS, zbytek světa to umí líp. :-)
Tím nechci říct, že problémy např. s endianitou neexistují, ale programy se pro jinou platformu v podstatě jenom upravují - pokud se nebavíme o jádře - a nepřepisují se.
Osobně tipuju, že žádný překlad x86->ARM se konat nebude, tak jak tomu bylo u PowerPC->Intel. Jednak by výsledek u komplexních aplikací nestál za mnoho - ARM ani za několik let nebude výkonnější než Xeony ve stejné době. Apple rychle nasadí universal binary ARM/x86 a momentální nedostatek aplikací vyřeší třeba tak, že umožní spouštět iOS aplikace v oknech.
Dává tak i smysl snaha Apple odříznout 32-bit binárky na Intelu, tím se ztratí spousta starých a nepodporovaných aplikací a 64-bit bude snadné přeložit pro 64-bit ARM.
Muzu se zeptat, co je mineno "universal binary ARM/x86"?
V dobe, kdy jsme jeste meli semestr assembleru a 486 architekturu :)), tak binarni kod mhl existovat jen na specificky typ CPU. Tudiz "universal" binary by mohla byt nejaka mezivrstva, ktera ale bude potrebovat dalsi preklad do "binarniho" kodu pro dane CPU.
Nesmíte se na to dívat optikou MS DOS/Windows... :-) Je to terminus technicus, před tím fat binary (68xx0 a PowerPC).
https://en.wikipedia.org/wiki/Universal_binary
Universal binary je vychytavka applu, jak do jedny binarky narvat kod pro vic platforem. Pouzivalo se to uz driv, kdy tam byl kod pro PowerPC/x86 https://en.wikipedia.org/wiki/Universal_binary
Pokud jsou to dva binarni streamy kodu v jedne binarce, tak to beru. V principu to resi "prenositelnost" aplikaci, ktere ale musi byt stejne zkompilovane nejdrive pro obe platformy.
V pripade iOS a MacOS bych ale cekal, ze tam budou trochu zadrehele co se tyce grafickeho rozhrani, takze se ty aplikace budou muset upravit/napsat s prihlednutim k tomuto.
Ono to ale nikdy neřešlo sloučení iOS a macOS (iOS se tehdy zřejmě rodil), ale provoz jedné verze OS X a jeho aplikací na různém HW. API byla shodná (systém vypadal a choval se úplně stejne jak na Power PC tak na x86), ale binárka pro CPU se lišila/byla univerzální.
To beru, v pripade 2 stejny OS (a jejich GUI) to dava smysl.
To je navíc z dnešního pohledu už trochu historické, při použití LLVM nebo podobné architektury by šel použít překlad při instalaci nebo dokonce při spuštění a šel by teoreticky klidně vydávat software pro úplně všechny platformy včetně těch, které vzniknou a vyjdou teprve v budoucnosti. Pak by mohl Apple své rozhodnutí ohledně dodavatele CPU klidně přehodnocovat a "soutěžit" co půl roku. :-)
Jenze ten preklad pri prechodu z PowerPC na Intel byl https://en.wikipedia.org/wiki/Rosetta_(software)
A stejne jako tehdy, tak ani dnes si apple nemuze dovolit prijit o tu haldu jiz existujicich aplikaci.
Také si myslím, že překlad x86->ARM nebude a uživatel nového Maca dostane přístup do cloudu kde si bude moct programy nainstalovat, poběží to v datových centrech Applu na Intelech - něco jako "vzdálený přístup". Služba (iCloud x86) bude placená, první dva roky zdarma k novému produktu.
Njn čert sere vždycky na větší hromadu. A s tím, jak se poslední dobou Intelu daří, bylo jen otázkou času, než se od něj Apple odstřihne...
2000 € fejsbuk mašinky ani nic ine ako cpu z telefonu nepotrebuju, takze ziadne strachy, svoju klientelu uspokoja. A velka vydrz na baterku ktomu.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.