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.
Apple by si klidně mohl vyvinout ve vlastní režii první velkou implementaci RISC-V, když na to přijde. ;)
A proč by to dělal? To je ekonomický nesmysl. Inhouse vývoj procesoru je drahý a zbytečný. Jediný skutečný důvod, proč si dělají Ax procesory byla arogance Intelu...
No je otázka jestli je ekonomický nesmysl vyrábět si procesor za 281 - 393 USD sám resp. navrhovat a vyrábět nebo každé vydání nového MacBook XXX odkládat až se Intel milostivě vytasí s novou generací (obvykle se zpožděním). Do zařízení jako je BacBook by ARM stačil.
Navíc jak jsem psal již dříve, otevřelo by to dveře ke streamovaným aplikacím a lepšímu uplatnění Apple Cloud.
Bežny uzivatel ani v minulosti priliš neriešil aky ma v PC procesor ale riesil ci mu jeho počitač niejde priliš "pomaly" a či mu spusti všetke aplikacie ktore potrebuje. A momentalne stale nevidim nejaku vyhodu napriklad ARM Androidu v notebooku oproti Windowsu. Windows toho zvladne stale viac ako zastupca plnohodnotneho desktopoveho OS. Takže ARM si viem predstavit maximalne na Apple notebookoch kde by tiež vyvstal problem s kompatibilitou softu ktory by uzivatel riesil ten sa da ale vyriesit emulaciou, tá by bola ale vdaka pomalosti ARM troška "lenivá". Pri Apple nie je problem aby pretlačil aj "koniny" a už v minulosti presiel z jednej CPU architektury a inú kludne to moze zopakovat. Aj ked tomu veľmi neverím, podla mna ostanu na x86_64...
Ta mánia okolo ARM je podla mna dost nafuknuta, hlavná výhoda ARM je podla mna v otvorenej licenčnej politike. Ta zabezpecuje nekonečný vstup kapitalu a konkurencie na trh s ARM procesormi.
Presne tak, to co uzivatele zajima je fungovani aplikaci a rychlost s jakou mu to cele bezi. Co se tyka rychlosti, tak jasne, ze x86 Atom byl v podstate od Intelu krok vedle a ikdyz toho Intel hodne prodal a dost na nem vydelal, tak prave zde dojde k uplnemu nahrazeni ARM, protoze ARM maji a mohou mit vyssi vykon, zatimco x86 Atom je proste pomaly a aplikace se sekaji. Jenze klasicke x86-64 procesory jsou stale na mile vzdaleny ARMum. Mi ukazte cim nahradim core i3, i5, i7 nebo dokonce Xeon. A ten jejich vykon samozrejme potrebuji. Lide si velmi rychle zvyknou treba na OCR, ICR technologie a tam je vykon seksakramentsky potreba.
A je tu jeste ten aplikacni problem. Podivejte se na aplikace pro Android, kolik mate profesionalnich aplikaci? Vsechno to je leda tak pro domaciho uzivatele. Zakladem dnesnich pocitacu jsou stale win32 aplikace a klasicke Windows. Jiste tech 5% uzivatelu linuxu nebude mit se takovy problem prejit na ARM, protoze open-source aplikace prelozite pro ARM snaze. Ale spocitejte i na linuxu pocet distribuci pro x86-64 a pocet distribuci pro ARM (ty spoctete na prstech jedne ruky). Takze i na linuxu stale vitezi x86.
Takze ARM to je dnes pro vyuziti sirokou verejnosti predevsim Android a ChromeOS. ChromeOS ma s aplikacema problem, moc jich neni a proto konecne Google dodelal podporu aplikaci pro Android. A samotny Android to je splacany javovsky OS s enormni rezii jen pro OS.
Takze ano, az se vyrazne prosadi nejaky normalni ARMovy operacni system, tak se muze Intel zacit klepat strachy, ale zatim tu nic takoveho neni a i Microsoft bere projekt Windows ARM jako neco co by jim mohlo pomoct nekdy daleko v budoucnosti a co jim pomaha v nekterych specifickych oblastech uz dnes, ale neni to neco, co by dnes MS povazoval za klicove, tim jsou stale Windows x86 stejne jako i na linuxu je hlavni vyvoj kladen na Linux x86.
Pokud srovnáváš nějaký moderní ARM a prastarý Atom, je to jasné. Stačí ale sorvnat s moderním "Atomem" (nyní Pentium N) a ARM z tohoto srovnání opět vypadne jako ten slabší. A když přijde čas na šifrování, zpracování médií (i těch, pro které nemá procesor specializované obvody/akceleraci), intel vyhrává na celé čáře.
ARM je CPU vhodný pro běžné spotřebitele, ale jako "pracovní" CPU si jej nedokážu představit. A split platformy, kdy část jede na ARMu a část např. na x86, už vůbec ne. Přitom platforma není jen masa spotřebitelů informací, ale taky těch, kteří tvoří. Z tohoto důvodu se domnívám, že aktivity Apple i MS v tomto ohledu budou neúspěšné.
"to co uzivatele zajima je fungovani aplikaci a rychlost s jakou mu to cele bezi"
A prave proto mam 32 bitovou verzi Windows 10, a mit budu.
Neumím si představit d es fungování se 4 GB RAM.
Proč ne? Já nestříhám video v rozlišení 4k, ani neprogramuji. A na otevření Chrome, Total Commanderu, Wordu, Photoshopu mi necelé 3 GB dostupné RAM v kombinaci s SSD stačí...
No stačí, když to dohání swapování na SSD. MOmentálně právě zlobí notebook, tak jsem vyndal 8GB a mám jen 4 GB + 4 GB SWAP, a neustále narážím na nedostatek RAM jen v kancelářské práci.
Až na to že sis jaksi neuvědomil, že tvých 8GB na 64bit systému je úplně přesně to samé, co jeho 4GB na 32bit systému (a tvých 4GB po vyndání paměti je tedy úplně přesně to samé, co by byly 2GB na 32bit).
S prominutím totální blbina. Na 64bit nejsou všechny datové typy 2x větší, ale pouze některé (ukazatele a některé druhy integerů). Např. u obrazových dat není ve spotřebě 32bit a 64bit žádný rozdíl. Výsledný rozdíl je dle programu (a kvality převodu do 64bit) od procent do desítek procent, nikoli dvojnásobek, pokud není program vyloženě zprasenej).
Další věc je, že pokud máš 4GB paměti, tak při 32 bitech nemalou část z tohoto prostoru (viděl jsem i 1,5GB) zabere oblast paměti mapovaná pro IO zařízení. Takže ve výsledku je to jako bys měl něco kolem 3GB paměti. U 64bit OS máš k dispozici celé 4GB, takže je tento fakt zpravidla přinejmenším vyrovná větší náročnost 64bit.
Zůstane Ti ovšem to, že 64bit kód je rychlejší, protože 64bit instrukční sada má více registrů a umí používat některé fce, které 32bit nepoužívá (přiznám se, že teď z hlavy nevím, jestli proto, že opravdu použít nejdou, nebo proto, že 32bit aplikace jsou kompilovány backward compatibile) a tak je možno zkompilovat kód efektivněji. U některých programů jde i o desítky procent výkonu.
Já mluvil o hardware, jantare. Datové typy nějakého vyššího jazyka si do toho motej jak chceš, ale seš mimo a ve skutečnosti vůbec nevíš, jak s pamětí ten který kompilátor zachází - ovšem to že jsou registry 64bit CPU (a tudíž i data v nich) dvakrát tak velké než 32bit neokecáš, protože to tak prostě je FYZICKY, přímo v materiálu. Nějaké rozšířené 64bit only sady se speciálními svými registry absolutně nezajímají, protože právěže nejsou backward-compatible a nikdo (krom "speciálek") to nepoužívá, a se současnými low-end procesory na trhu hned tak nebude, vždyť tam se 64bit arch. dostala teprve nedávno. Možná tak za deset let, stejně jako teprve dnes se pořádně začínají využívat multicore CPU, přestože jsou už deset let na trhu. Nekompatibilitu si nikdo na triko nevezme.
PAE? Jednotlivé aplikace budou omezené na 2GiB, ale celý OS může v pohodě používat třeba 16GiB. Mám jeden takový stroj. Víceméně tak zůstal z lenosti upgradnout OS a nic kritického mne netlačí to udělat vzhledem k tomu, co na tom stroji běží (Core i5, 16GiB RAM, swap se nekoná vůbec, lepší zpomalený přístup do RAM přes PAE než swap).
přeji si, aby tu x86-64 procesory byly neustále. Proč? Protože právě to, že lidi berou počítač jako monolitické zařízení, přináší spousty problémů. A ještě to podělat ARMy?
Když si teď lama koupí notebook jako má soused, tak přinejhorším sáhne po nevýkonném Atomu, byť jeho soused má ve stejném šasi Core i5. Holt se mu budou spouštět aplikace pomaleji, ale půjdou.
Když si lama koupí notebook až x86 CPU nebude "automaticky osazovaný", tak ačkoliv ty dva stroje budou k nerozeznání, tak jednomu ta x86-64 aplikace pojede, druhému při nejlepší vůli ne.
To bude maglajz. Pak něco supportujte. Aplikace Vám nejde spustit, protože to píše není na tomto počítači podporována? Co máte za počítač? Notebook. Je to Apple nebo něco jiného? Lenovo. Máte na tom Windows nebo Linux? Nevím co to je. Aha, máte v dolním levém rohu takové okénko? Ano. Vedle je lupa? Ano. Takže Win10. To je divné, to by ta aplikace měla běžet. A přitom má nějaký ARMový křáp. Jasně, nakonec se toho doberete a je to zákazníkovo problém, ale toho zbytečného času ... zbytečně vyhozených peněz.
Navíc to tento segment neposouvá nikam dál. Ta ARMová platforma není ani výkonnější, ani univerzálnější, ani úspornější ... jen je levnější. Všechno špatně. Pokrok nelze stavět na low-costu.
To by bylo v 21. století smutné, aby se aplikace nevypořádaly s něčím tak triviálním jako je změna ISA. Všechny kousky skládačky k něčemu takovému už asi dvacet let máme.
smutné to sice je, ale také je to dnešní a bohužel i zítřejší realita ...
Realita je to akorat ve svete woken, Android dnes funguje uplne stejne na X ruznych variacich ARMu (a IMO appli masox by s tim taky nemel problem). Nebo si snad myslite ze vsechny vyrobene mobily doted pouzivaji stejnou ISA ? nikoliv. A ty vyhozene penize co spominate, se uplne stejne vyhazuji uz ted za zbytecne problemy ktere pridelava Microsoft jak na bezicim pasu, takze tam by zadna zmena nebyla :)
Aplikace se nemají co vypořádávat se změnou ISA - to má mít na starosti OS. OS poskytuje aplikacím nějaké rozhraní k HW, aplikace toto rozhraní využívají a je jen otázka, jak moc je to rozhraní abstraktní vůči HW. Pokud se bavíme o WIN - možnost změny ISA znamená, že musíš zahodit staré Win rozhraní a používat pouze Modern Win Apps - a jak aktuální statistiky ukazují, to je věc do které se naprosté většině uživatelů absolutně nechce - sílu setrvačnosti se nesmí podceňovat. Jinak z technického pohledu možnost změny ISA znamená ztrátu části výkonu platformy - musí tam být mezivrstva která ISA abstrahuje, což žere část výkonu.
OS ale nemá s ISA moc společného, viz třeba NetBSD. Mnohem zajímavější jsou tady kompilátory.
"OS poskytuje aplikacím nějaké rozhraní k HW, aplikace toto rozhraní využívají a je jen otázka, jak moc je to rozhraní abstraktní vůči HW. "
To ano. Ale to je do mnohem větší míry otázka celkové architektury stroje než pouze ISA. Změnit ISA je celkem jednoduché. Třeba přejít z IBM PC na Connection Machine je něco úplně jiného. V porovnání s tím je změna ISA naprostá banalita. Což je ale dobře, protože tím počítačoví architekti dostávají možnost ISA změnit podle toho, co se ukáže jako optimální návrh v dané době, a když nám teď výkon procesorů stagnuje, je to jeden z mála zaručených způsobů, jak posunout výkon počítačů někam dál. Ostatně právě od toho vyšší jazyky vznikly: aby se o tohle programátor nemusel starat a aby architekti počítačů mohli dělat svou práci a nebýt zatíženi tím, že je při návrhu svazuje X starých programů.
"Jinak z technického pohledu možnost změny ISA znamená ztrátu části výkonu platformy - musí tam být mezivrstva která ISA abstrahuje, což žere část výkonu."
Nemyslíte, že LLVM tyhle bludy už definitivně vyvrátilo? Pracuje s abstraktní mezivrstvou a stejně ho dneska cpou všude, kde na výkonu záleží. Do kompilátorů C++, ovladačů grafických karet apod.
Kromě toho jste před chvílí mluvil o hlavní roli OS. Teď sám sobě odporujete, protože API OS nemá s ISA prakticky nic společného (a i ABI s tím má něco společného jen do určité míry).
To neni zrovna trivialni. Hlavne k tomu OS musi mit patricne predpoklady. Apple to urcite adekvatne vyresi, protoze to delali uz nekolikrat a vedi jak na to. Na unixovych distribucich s vlastnima repozitarema to taky vicemene neni az tak hrozny (nez dojde na prusvih, ze aplikace v repozitarich neni a pak je uzivatel ztracen). Ale pak tu mame ten zbytek... treba tu vetsinu s windows a tam microsoft dlouhodobe ukazuje svoji neschopnost.
Že není? Jestli za to někdo může, tak to jsou výrobci, protože třeba Oberon tohle před dvaceti-pětadvacetli lety zvládal zcela rutinně.
Průmysl PC prostě dojel na Jevonsův paradox, jehož důsledky se nečekaně přelily do podoby setrvačnosti masivních systémů.
Pred 25 lety byl svet jinde. Bylo tu vedle sebe nekolik ruznych cpu architektur. Programatori byly kvalitou o spoustu levelu vyse. Tehdy dokonce i windows umeli plnohodnotne nekolik ruznych cpu architektur...
Troufl bych si tvrdit, ze systemovi programatori jsou na tom odborne o dost lepe nez pred 25 lety a musi toho zvladat o hodne vic. Nejde porovnavat hrusky a jabka. Pred 25 lety neexistovala vetsina dnesniho HW a tim padem ani vetsina programatoru, kteri pro nej vytvari SW s ruznou urovni abstrakce a odbornosti.
Pozor, že Windows byly zkompilovány pro PPC, MIPS a Alphu ještě neznamená, že to mělo nějaký zásadní význam.
Byla velká škoda že podporu Alphy Microsoft zabalil u betaverze w2000, mimochodem běží na nich i x86 aplikace a nativní jsou k nesehnání... kdyby někdo věděl kde se dá cokoliv najít sem s tím :)
Vyznam to nemelo. Ale je to vlastne pekna ukazka upadku microsoftu, kdyz dneska nejsou schopny udelat plnohodnotny wokna ani pro arm :(
Oni ale jsou, jen ten ARM na to nemá dostatečný výkon. ;-) A tudíž to nemá moc smysl.
A to je nenapadlo dřív, než udělali W10 Mobile?
A jak se ta edice windows prosim jmenuje ? Hned si to pobezim stahnout z MSDN. Ale at hledam jak hledam nevidim zadnou edici windows pro arm, kde je plnohodnotny desktop. Edici, ktera na armu umi plnohodnotne winapi a muzu tam poustet nativne zkompilovane aplikace pro arm winapi pouzivajici. Vykonu na bezny aplikace ma dnesni arm dost. Coz sem si overil pred rokem a pul, kdyz sem portoval aplikaci pro raspberry pi s windows 10 iot core (ale tam je jen krute osekany winapi).
Navic microsoft i u toho co beha na armu neumi poradne nic jinyho nez cipy od qualcommu.
A k čemu ti bude desktop, když tam nebudou aplikace? ;-) A není to Win32API osekané proto, že ARM jednoduše nenabízí stejnou funkcionalitu, resp. že přepsat a překompilovat 25 let vývoje Windows na ARM by bylo zřejmě vysoce neefektivní? Co s dalšími "špeky" typu .com, .net, které se do Windows postupně "nabalovaly"?
Když to vezmeš racionálně, tak třeba Apple to při přechodech na nové HW platformy (MC68k -> PPC a následně PPC -> x86) vyřešil ne zcela dokonalou emulací a přechodem na nové API - a to bez diskuse s uživateli, a bylo to přijato jako fakt. Když totéž udělal MS (WinRT), tak je to špatně - a to se tu bavíme o situaci, kdy by x86 neměl být opuštěn a zároveň o platfotmě PC, která je modulární, nikoli jako Mac, který má už roky pevně danou HW konfiguraci (jediný úkrok stranou jsou klony z půlky 90. let).
Shrnul bych to tak, že Windows prostě nejsou Linux, který byl vytvořen tak, že jeho monolit lze provozovat na téměř libovolném HW. Z toho plynou výhody a nevýhody (jak pro Win, tak pro Lin) a pokusy dělat z jednoho druhé a z druhého první logicky už z povahy obou systémů nemůžou dopadnout dobře. A já se domnívám, že tato diverzita je dobrá a vhodná, protože se nakonec vzájemně tyto OS doplňují. je dost možné, že skalní příznivci Windows a Linuxu to tak nevidí, ale já jsem přesvědčen, že toto je optimální stav.
Neni desktop - nejsou aplikace. Nejsou pouzitelne windows pro arm - nejsou pro ne aplikace. Typicky problem slepice a vejce. Dokud to microsoft nerozsekne, tak se nemuzou divit ze jsou tam kde jsou.
To winapi je osekane, protoze ho microsoft osekal. Jako dukaz lze pouzit windows rt, kde slo vetsinu nedostupne funkcionality zpristupnit pomoci hacku. To osekane winapi je navic spolecne i pro x86/amd64 verzi a cely UWP zazrak. Neumi to ani nacist .dll knihovnu za behu a proto hry pod uwp nepodporuji modifikace.
Kdyz apple prechazel na novou platformu, tak vzdycky dodal dostatecnou funkcionalitu. Microsoft po letech vyvoje ma stale nepouzitelnyho kripla, ktery je funkcionalitou jen maly zlomek toho co je potreba.
Hmm... Já ti nevím, když se podíváš na WP platformu, tak tam to bylo hodně tristní. Dokud nepřišly W10 do desktopu a konečně trochu pohly s poměrovým zastoupením WinRT-capable OS, tak to bylo dost o ničem. A to, že první podání MS vždycky zmrví, je už celkem známo. :-))
K tomu je krasny priklad microsofti surface. Prvni dve generace meli i verzi s armem a prodavala se tragicky. Od ty doby delaj jen x86 s normalnim windows a prodeje dlouhodobe stoupaji.
Notebooky to jsou hlavne windows a dokud windows nenabidnou plnohodnotny desktop a moznost normalnich aplikaci tak arm nema sanci na vetsi rozsireni. Zustane na minoritnich platformach jako je chromeos. Teda pokud se nestane nejaky zazrak :o)
"To by bylo v 21. století smutné, aby se aplikace nevypořádaly s něčím tak triviálním jako je změna ISA."
To platí jenom do doby, než přijde řeč na multimédia, které bez výjimky potřebují hardwarovou akceleraci (u které není reálné, aby řešila všecko do JPEGu přes poslední formát videa od Googlu, které vycházejí tempem jeden za dva roky), nebo rušně napsaný SIMD asemblér.
Jako klidně si můžeš překompilovat x264, x265 na ARM nebo na Power, ale když k tomu někdo (no, spíš několik někdů) nebude dva tři roky psát ručně SIMD, tak to pojede 3-5x pomalejc.
Jednodušší věci jako dekodéry tolik času nezaberou, ale FFmpeg nemá pokrytej pořádně třeba ani ARMv8 u všech důležitejch dekodérů. Kdyby chtěl někdo přejít na Power, tak je úplně na suchu. RISC-V si to teprv vyžere, jestli se někdy dostane do praxe.
Z mýho pohledu je x86/x64 díky té dlouhé kontinuitě obzvlášť pro tyhle účely (všichni máme rádi, když software je optimalizovanej, ne?) moc cená architektura a když se ji bude dařit udržovat výkonově na špičce i další dekády, tak to bude jenom dobře. IMHO přínosnost těch existujících SW optimalizací dnes v průměru určitě převyšuje úroveň nějaké teoretické "x86 tax" - pokud ta vůbec existuje.
A jinak ARMy jsou ještě děs a hrůza z toho pohledu, že každý čip potřebuje specifickou podporu v Linuxu a většinou ji nemá v upstreamu - výrobci většinou jenom vydají nějaký patchset/fork staršího kernelu a ty patche se nikdy nedostanou do Vanilly. Nechápu, jak Linuxák dokáže takovej stav považovat za lepší proti platformě x86 :D Stav s ovladačema GPU v ARMech je taky dost děs.
> FFmpeg nemá pokrytej pořádně třeba ani ARMv8 u všech důležitejch dekodérů.
Nema a ani mit nebude, protoze na mobilni platforme se o takovyhle nesmysl nikdo ani snazit nebude. Sebevic optimalizovanej SIMD dekoder vam nikdy nedosahne ani na 1/2 efektivity HW dekoderu, takze na mobilu o tom fakt nikdo ani uvazovat nebude. (BTW ARMv8 je trochu blbej priklad, sotva se rozjizdi..)
> u které není reálné, aby řešila všecko do JPEGu přes poslední formát videa od Googlu,
Realne to je naprosto bez problemu, protoze velci multimedialni hraci (na Androidu minimalne YT ale predpokladam ze i Netflix a dalsi) si zjisti, jakej format vam vas HW akceleruje, a poslou vam video presne v tom formatu. A tech formatu neni az tak moc, jak pisete.
> každý čip potřebuje specifickou podporu v Linuxu a většinou ji nemá v upstreamu
Jo tohle je ten hlavni problem IMO.
"Realne to je naprosto bez problemu, protoze velci multimedialni hraci (na Androidu minimalne YT ale predpokladam ze i Netflix a dalsi) si zjisti, jakej format vam vas HW akceleruje, a poslou vam video presne v tom formatu. A tech formatu neni az tak moc, jak pisete."
Tak v mobilní hračce budiž, ale aby notebook/PC mohl dekódovat vždycky jenom starší formáty a pro podporu novějších abych si musel kupovat novej CPU (a desku, nebo tady novej notebook), to mi přijde naprosto uhozený. Za rok bude například zmraženej AV1. S x86 notesem si počkám, až bude sw dekodér - ffmpeg ho určitě bude mít dřív, než bude formát používanej "in the wild". Podpora v hardwaru bude ale tak rok-dva trvat, a i potom nebude ve všem na trhu, budu si muset vybírat, jakej notebook koupit. Nechme stranou, že jsou i formáty, které hd dekódování nemají (cokoliv 4:4:4, 4:2:2, 10bit VP9 umí jenom Intel Kaby Lake, 10bit H264 nic, 12bit HEVC umí jenom aktuální Nvidia...)
A taky mám takovou zkušenost, že tyhle dekodéry mají skoro vždycky nějaký mouchy a nedá se spolehnout, že přehrajou všechno i v profilech/levelech, které oficiálně mají podporovat. Je tam docela slušná zabugovanost, takže sw dekódování je vždycky stabilnější.
P.S. Jako já nepopírám, že tenhle scénář může nastat a že se svět přizpůsobí (co mu bude zbývat...). Akorát říkám, že to bude pěkně na levačku a je naivní si myslet, jak to bude všechno supr.
Tohle jsem si myslel, že vyřeší Open CL, nebo DXVA s patricnou grafikou. Programátoři ffmpeg a dalších enkoderů by na to museli myslet pri implementaci.
Je to tak. Software bude vždy lepší řešení než hardware. A to platí odjakživa. Vždy když něco máte jakože počítáno nějakým čipem, tak to znamená hlavně to, že s tím skoro nic nemůžete jinak dělat. Chce to jedno hlavní CPU dostatečně výkonné pro vše a je pokoj. Bohužel v tomto stádiu ještě asi mnoho let nebudeme...
>>Nechápu, jak Linuxák dokáže takovej stav považovat za lepší proti platformě x86 <<
Jestli ono to nebude tím, že většina Linuxáků se bohužel nezajímá o to, jaká zvěrstva je potřeba udělat před spuštěním jádra. A že to občas stojí za to (tedy podle toho, co jsem slyšel od přímo zainteresovaných lidí). Většina BLU (běžných linuxových uživatelů vč. pokročilejších adminů) totiž skončí u toho, že nainstalují distro připravené někým jiným. Běží? Běží. A tím to hasne.
Ona jen prostá výměna distribučního jádra za vanilla může být na ne x86 platformě docela výzva. Na x86 to bývá naopak poměrně trivální a rutinní záležitost.
ještě k té poslední větě - jediné místo, kde má lowcost prostor pomoci nějak pokroku je na počátku vývoje něčeho nového. Dostat novou technologii mezi lidi, byť za cenu některých omezení.
Problém je v tom, že vývoj počítačů v současném pojetí není na počátku, ARM není nic nového, je to jen jiné. Alternativa která nic nového nepřináší - jen problémy.
Ano, teoreticky je tím možné dostat další levná zařízení mezi lidi a něco málo krátkodobě vydělat, ale tím si výrobci podřezávají pod sebou větev. To co platí vývoj, jsou ta drahá zařízení.
Lidi jsou zvyklí dát za noťas alespoň 12000Kč. Tak proč to tlačit někam k 6000Kč? Jak pak chcete ospravedlnit prodej noťasu za 30, 50, 100 tisíc Kč, když je to podle lamy notebook jako notebook ... no bóže, ten jeden je asi rychlejší, ale když jsem před 5 lety kupoval jiný za 12000Kč, tak ten za 6000Kč musí teď stačit. A ono ne. Jak tedy chtějí vydělat?
Jak na tom chce vydělat MS? Vždyť mu to akorát zkazí ještě více jméno. Najednou se mezi lidi dostane něco, co nefunguje jako to ostatní, byť to vypadá úplně stejně. Něco pojede v režimu emulace, něco vůbec, něco pomalu, něco s omezením ... ty lidi tomu nebudou rozumět, nakonec se nakrknou a utečou k Apple. A nebo k Android 16 Kremrole.
Když chtějí přijít s něčím novým, tak budiž. Proč ne? Ale ať je to nové komplet, odlišitelné od stávajícího a přináší to nějaké benefity. Tohle je jen plácání se na místě v dravé řece.
"Lidi jsou zvyklí dát za noťas alespoň 12000Kč. Tak proč to tlačit někam k 6000Kč?"
Blbost. Proč bych dával za rychlestárnoucí hovadinu jako je notebook 12 000? Před 2 rokama jsem koupil ASUS za 7300, dnes je to asi složitější. Pointou je, že moje HP co mě stálo 18 000 v roce 2007 rozhodně nepřevyšovalo ten ASUS v žádném parametru... Zapomeňte na 12 tisíc.
No pokud používáte nějaký rozumný OS, tak je změna ARM vs x86 vs POWER vs MIPS vs ... nepodstatná. Stačí vzít zdroják aplikace a zkompilovat pro danou platformu. Třeba na Fedoře člověk nepozná, jestli v tom má ARM nebo x86 (až na výkon). Všechen SW, co mám na x86, mi pojede i na ARMu :)
V obou případech je samozřejmě podmínka mít podporovaný HW.
Pokud na tom poběží Android, tak by mělo být jedno, co je pod kapotou, aplikace jsou v podstatě Java, tedy v nějakém bytecode. Stačí když se prekompiluje OS s interpretrem.
Vem čert Android, to je sice pěkný varovný příklad, ale pointa problému je, že pokud jsou aplikace i část OS kompilované do nějakého bytecode a ne nativně pro konkrétní CPU, tak se to celé vleče jak smrad a nepomůže tomu ani pomazání marketingovými buzzwordy.
Bývaly doby, kdy se programovací jazyky vyvíjely tak, aby se v nich nejenom daly psát a udržovat hodně rozsáhlé programy, ale taky aby to svižně běželo, tak svižně, že se nevyplatilo trávit čas assemblerem. V dnešní době, kdy se na výsluní dostávají opět jazyky interpretované, jde opět výkon do hajzlu. Doslova.
My, co máme zkušenosti s pomalými počítači z 80 let víme jak obrovský rozdíl je mezi kódem v assembleru, interpretovaným BASICem a zkompilovaným BASICem. Tehdy na pomalých CPU to bylo víc vidět. Dnešní situace kupříkladu s Pythonem není zas tak odlišná, jak by se mohlo zdát. O Javascriptu nemluvě.
95% softwaru je dneska podělaný bloatware (to číslo jsem si vycucal ze zkušeného prstu). Efektivní a kvalitní kód se prosadí málokdy. Bohužel. Prostě proto, že uživatelé vidí nejprve vzhled, tu a tam vnímají ergonomii a jen velmi výjimečně něco víc.
Pokud na tom poběží Android, tak by mělo být jedno, co je pod kapotou, aplikace jsou v podstatě Java, tedy v nějakém bytecode. Stačí když se prekompiluje OS s interpretrem.
V dobách kdy Apple opustil architekturu RISC došlo samozřejmě k odlivu pracovních, grafických... no prostě profesionálních strojů jako PowerPC a pod. Přechod k x86 platformě byl samozřejmě pro profíky obrovskej "průser" a krok zpět jak vůči výkonu tak i stability. Ovšem směrem k BFU a celkovým výdělkům to byl plus. V dnešní době označit Apple produkty za profi pracovní nástroj může jen sadomasochista, nebo člověk, který je ochoten zaplatit 2-3x více za ten samý HW v superduperhyper designu...
Takže u Apple a BFU je přechod k ARM jistý, ale v profi segmentu je to čirý nesmysl.
To tedy nevím o čem mluvíte. Přechod od v té době stále více zaostávajícího PowerPC k Intelu byl fantastický výkonový skok. A stabilita? No fakt si nepamatuji že by někdy OS X lehnul. A ktomu Rozeta zajišťující velice slušnou emulaci ještě mnoho let po přechodu. Člověk kolikrát ještě před pár lety s překvapením zjistil, že nějaká stará aplikace běží v emulaci a ani o tom nevěděl (to když se Rozeta "nedávno" rušila). Co více si profesionál může přát - výrobce kompletně změní HW platformu a vás se to dotkne jen rámcově nebo to ani nepoznáte. Pořád mám starý PowerPC na specifické věci a obecně mám RISC rád, ale bez přechodu na Intel by Apple zanikl se zámrzem PowerPC platformy.
Jestli je něco úpadek, tak je to současné provedení MacBooků Pro s omezenou konektivitou a blbostmi typu touchbar. Naopad přechod mezi PowerPC a x86 byl tehdá odveden naprosto příkladně.
Bavím se o době kdy v serverech tikaly Pentia 133MHz, ješte ani pro verze neexistovali, sítě LAN byli většinou v té vyšší verzi BNC 10MBit, Zálohy vydání jednoho nejmenovaného deníku jsme uploadovali přes BBS 9,6kBit, SCSI řadič a disk byl bůh a nebe ... atd. Tenkrát Apple byl opravdu profi firma na jakékoliv průmyslové využití. Grafika, design DTP, CAD, CAM, CAE ... atd. Jestli si nepamatujete že by někdy OS X lehnul, tak jste velmi mladý nebo jste s Applem spolu jeli tak v rychlíku :-) "Chyba 1" - nejlepší hláška OS X, to totiž není že lehnul, ale rovnou umřel :-)
A abych předešel dalším stupidním výpadům ať použiju google (viz. komentáře níže) apod, já začínal na DOS 3.0 a IBM PC i80286 - 12MHz, tzv. od píky
V době P133 už byl 100Mbit lan, 28kbit modemy a internet v Čechách, a apple do návratu Jobse upadal. Trošku mi přijde že od roku 2000 je Apple jen o snobském pocitu příslušnosti k image který si vybudovali.
Povídáte o odchodu Apple od RISC, ale najednou máte Pentium 133 a nemáte ethernet. Co mám PowerPC G4 i G3 Maca (takže ten RISC) tak ty mají IDE, 100BaseT ethernet, SCSI už ne, je tam jako PCI karta (a bylo tomu tak už dlouho před tím). Pak byl skok rovnou do x86 procesorů Intel Core, zažil jsem, prošel jsem si. OSX se mi položil jen jednou, kernel panic, odešel HDD. Ale jinak fakt nikdy nehavaroval (na rozdíl od některých mizerných aplikací). Na rozdíl od Mac OS 9 což byla fakt padavka na úrovni Win 98. Použití jen čistě pracovní, na grafiku (jak ty PowerPC tak Intelové).
Mladý se ještě cítím, rozhodně. Začínal jsem před něco málo méně než 30 lety na Amize 500 (Motorola 68000, 7,14 MHz 512 kB RAM, tzv. od píky. :-)
:) .. starci na chmelu .. hmm .. od piky .. kto si rucne neopravoval projekt na diernych stitkoch (prelepovanie a rucnou dierovackou) tak nezacal od piky ;) .. ano doma uz potom niektory "stastlivci" trapili sinclair, comodore, alebo atari
Tak proč vlastně přecházeli od PowerPC k tomu prašivému Intelu? Prosím tě, dej si do Google "G5 vs Intel" a podívej se, jak to vypadalo. Výkon byl dost nesourodý v různých disciplínách, ale v zásadě to vypdalo tak, že existovaly věci, kde se Power 970 dotahoval na x86 a někdy jej o pár procent předběhl, ale velmi často byl 2x pomalejší a hůře. (A to byl svět tehdy optimalzovaný pro Power.)
Tak on ten Power se taky od té doby vyvinul. Konec konců konzole x360 a PS3 běží na PPC. Ale to je už stará generace, od té doby se to zas posunulo.
Sice se posunul, ale posunoval se pomalu na to aby s ním Apple zůstal konkurenceschopný.
Xbox 360 a PS3 - tam je to to centrální standardní CPU jádro v Cellu - nejsou moc dobrý příklad, to jsou hodně pomalá (vykuchaná) jádra.
Jinak ale ten přechod jablek na x86 byl tak hladkej proto, že ta nová CPU měla o hodně větší výkon, takže ten postih za binární překlad se ztrácel. Notebooky přecházely z Motorol G4 na Core 1 Duo (jádro Yonah), IIRC. Yonah měl sice mizernej výkon v SSE/SSE2 SIMD (a z dlouhodobýho hlediska byla velká škoda, že není 64bitovej), ale kromě toho to bylo slušný CPU, už trošku ukazující na výkon Conroe.
Dneska by ten ARM nahrazující Intelovo velké jádro asi nebyl o 50-100% rychlejší v jednom vlákně, takže by to taková prča nebyla.
Myslím, že by pan von Neumann divil, že jeho architektura procesorů je tu po 70 letech stále. Vždyť ji vymýšlel za úplně jiných technických odmínek. A ARM, to je RISC, tedy jen 40 let stará architektura. Apple na chvíli používalo 3. generaci od IBM, ale nepohodli se. Aby to bylo ještě komičtější, uvnitř Intelovského procesoru je počítač se superskalárním procesorem, který zajišťuje paralelismy a multivláknovost procesoru.
Možná by se nedivil, protože byl naprosto geniální (mj. jeden z nejlepších matematiků 20. století - když přijdete do projektu Manhattan a i tam mezi už tak geniálními lidmi *o vás* začnou kolovat legendy, tak asi opravdu vyčníváte), a technické podmínky takového abstraktní návrhy příliš mnoho neovlivňují. Možná přijdete na nějaké nové věci, ale ty staré kvůli tomu fungovat nepřestanou.
Nedivil. Protože je naprosto vhodná k tomu, co od toho většinou chceme.
Ano, můžeme mít třeba umělou neouronovou síť, jsou aplikace, kde je vhodná - ale je daleko více těch, kde vůbec vhodná není...
Myslíte, že by se pan Newton divil, že jeho zákony stále plati i po několika stech let? :-)
Ono celá tahle úvaha co nám prezentuje Mr Ježek je tak krapet na vodě.
Jediné co je dneska jisté (a z čeho vůbec ale vůbec nemám radost) je, že se posunujeme z "wintel otroctví" do otroctví korporacím poskytujícím cloudové služby
Co je pravda je to, že běžného uživatele celkem nezajímá, coje uvnitř, ovšem tento uživatel se velice zajímá o to, co za aplikace na tom železe běží, chce tam mít to na co je zvyklý (určitě znáte časté případy které jsou nešťastné jenom z toho, že se jim ikonka na ploše posune jinam, nedej bože že jim člověk nahraje program se stejnou funkcí, ale jiným rozhraním)
Spekulovat o tom, jestli ARM nahradí x86(64) v noteboocích je věštění z křišťálové koule - takovéto články se tu objevují takových posledních pět let pravidelně a pořád se to neděje, předpovídá se, že win musí umřít a ono se mu potvoře pořád nechce, naopak po bouřlivém rozvoji non-win zařízení v nedávné dochází teď ke stabilizaci stavu.
Co se týká vousatosti platformy, zas tak velký rozdíl mezi nima není - x86 má nějakých 45let, ARM cca 35let.
"Jediné co je dneska jisté (a z čeho vůbec ale vůbec nemám radost) je, že se posunujeme z "wintel otroctví" do otroctví korporacím poskytujícím cloudové služby"
Já bych řekl že se přesunujeme do doby otroctví "telefon/tablet/X je blackbox a když výrobce za 18 měsíců přestane vydávat aktualizace, je kvůli nulové bezpečnosti na vyhození". Zlatej Wintel proti tomu.
Chca nechca, vše směřuje k ARMům do všeho. I Intel dělá chyby a občas vypustí časovanou bombu. Aktuálně viz. umírající Atomy C2000 v embeded systémech. Tady si asi výrobci škubou vlasy, proč nepoužili ARM, ale Atom, který jim Intel "vnutil". Microsoft má také našlápnuto a usilovně pracuje na "Win10 Cloud"pro ARM platformu. Dříve známou jako Windows RT:
http://www.windows10update.com/2017/02/download-windows-10-cloud-iso/
Ale C2000 je technologická chyba, ne chyba architektury (není to tam ani chyba jádra procesoru, chcípá clock generator, tohle se mohlo stát v podstatě každému výrobci)
A já myslel, že Windows RT chcípnul a pokud ani tentokrát nenabídnou 100% kompatipilitu se SW, tak ten WinCloud chcípne taky.
Naprosto souhlasím. Jen dodám, že nekompatibilita Windows RT byla naprosto umělá. Oproti standardním edicím Windows zavaděč pouze navíc kontroloval, zda je nativní exe/dll podepsáno MS certifikátem, a pokud ne, odmítl ho zavést. Když člověk přeložil typickou Win32 aplikaci pro ARM, tak na jailbreaknutých Windows RT fungovala úplně v pohodě. Jsem přesvědčen že Windows Cloud budou opět přesně to co Windows RT ...a stejně i dopadnou.
Ja jsem dost fanousek ARMu, ale fakt si neumim predstavit ze bych kupoval notebook s ARM. Viz muj komentar vyse, ze hlavni problem ARMu je, ze tu neni zadny zivotaschopny OS, pokud nechci jen nejake konzumni zarizeni.
Ano, pokud si dnes budu kupovat telefon, tak si koupim neco s Androidem, dokazu si predstavit i poptavku po tabletech, ale to jsou vsechno jen konzumni zarizeni a mnoho lidi dnes notebook pouziva jako nahradu desktop PC. Takze pokud potrebujete vic nez konzum tak mate jedinou moznost, poridit minimalne notebook s x86-64 core i3-xxxxU nebo lepe pro opravdovou nahradu pocitace core i5-xxxxHQ. Na ten zadny ARM ndosahuje a hlavne pro ARM nemate operacni system a aplikace.
Androidí tablety letí s prodeji dolů stejně jako iPady. Kupodivu Windows tablety s x86 procesory za poslední rok 19% nárůst...
no z 0.5% sa lahko robi aj 100%
ale podla netmarketshare
mal Win OS na tabletoch v 3/2016 2.54% a v 1/2017 uzasnych 1.48% cize pada.
Android 3/2016 60.99% a v 1/2017 63.99%
iOS 3/2016 31.76% a v 1/2017 32.03%
https://www.netmarketshare.com/operating-system-market-share.aspx?qprid=...
cize MS kona rozumne ze zacina uvazovat nad podporou ARM.
Ak by, a to je pravdepodobne, zacal do Airov davat Apple ARM tak by stale bolo mozne mat dualboot a hlavne mohol by ist aj na lacne tablety
Nepíšu o podílu, ale o prodejích. Ostatně, jak ten server pozná, že jde o tablet, když jsou to standardní Windows 10 s libovolným browserem?
BTW NetMarketShare - už se tam ukázal GoogleOS? Ta šílená hrozba pro Microsoft, jak se všude píše už několik let?
Jmenuje se to user-agent string. Pro inspiraci par prikladu:
Mozilla/5.0 (Android 4.4; Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
Mozilla/5.0 (Android 4.4; Tablet; rv:41.0) Gecko/41.0 Firefox/41.0
Nebo si prostudujte napr projekt Mobile-Detect. https://github.com/serbanghita/Mobile-Detect
a jak to řeší ten předešlý příspěvek? Na x86 tabletech je standardní W10 edice (není tam žádná mobilní nebo tabletová speciálka) a jede tam normální desktop prohlížeč tj má stejný user-agent jako na stolním PC
Uplne mi vypadlo, proc jsem zacal psat ten komentar. Ja jsem fanousek ARM, napriklad nastupujici Snapdragon 835 od Qualcommu uz bude mit hodne dobry vykon a moje predstava je ta, ze koupim jedno male zarizeni (smartphone), ten budu schopen nejak pouzivat nekde venku na baterii, potom prijdu do kancelare, pripojim k monitoru a spustim Excel a na tom samem "telefonu" normalne pracuju, potom prijdu domu, pripojim k TV a na tom samem "telefonu" cumim na filmy.
Tady je vyhoda ARM nad Intel x86 zcela jasna, energeticke naroky!
Jenze dneska, pokud byste chteli takto fungovat s ARM, tak mate v podstate jen Android a jeho aplikace a Android je konzumni nestabilni platforma, ktera navic dokaze sama pozrit jakykoli vykon, takze ani ten Snapdragon 835 nakonec nebude stacit. Pro ARM tak jednoznacne chybi pouzitelny operacni system a cele ekoprostredi i s aplikacema. A protoze nic nevypada, ze by nejak tezce nastupovalo jako lepsi nahrada Androidu, tak muze byt Intel v naprostem klidu.
Sice je to takové fandovské, co třeba Sailfish OS?
Energetické nároky vs. hrubý výkon je přesná analogie s pletením biče z exkrementu. I když takový bič po velké snaze upleteš, tak jím nezapráskáš. A to je přesně problém ARMu. Jakmile dosáhne reálného výkonu x86 (byť toho nejpomalejšího soudobého Atomu), tak energeticky to bude HORŠÍ, než roky piplaná x86 architektura, která sice má milion evolučních běhových režimů, ale taky naprosto univerzální možnosti použití.
Uf, jak z informace o tom, že Apple chce ARM čip co pojede napozadí v době kdy ntb bude vypnutý a jediný co bude hlídat jsou maily apod a to vše jen kvůli spotřebě, dostat, že Intel končí... :-D
O co tu jde?
x86 nebo ARM, neni to jedno? až bude vládnout klidně ten ARM, tak ho bude sekat intel jako teď x86 a wokenice budou ARM ready.
Nemyslim si že by ty firmy nebyly připravený, ale proč dokud je tu odbyt stávajícího něco měnit, je to z části i pohodlnost.
A ano ve výsledku je to jedno na čem co běží, když to plní požadavky výkonu a soft umí to co chce uživatel. Bohužel se programuje pro masy a tak ten vývoj/přechod někam jinam je hodně vleklý. (z důvodu že lidi jsou líný od přírody a tak jsou vůči novým přístupům rezistentní - pokud stávající zaběhlé postupy plní jejich nároky)
V oblastech kde je ten vykon potreba se ARM nema sanci prosadit - aspon dokud (pokud) nesrovna vykon s x86 - coz je z povahy rozdilu architektur docela scifi :o)
V této chvíli je dobré že tady máme Windows, Linux, Apple a Android. Intel, AMD a ARM. Je to konkurence. A to tlačí na ceny a vývoj.
Takže doufejme že nikdo další z trhu nevypadne, opět bychom se přiblížili k původnímu monopolu Intel - Microsoft.
To je ta kapitalisticka soutez, horsi jak za komancu
Nedokazi si predstavit ten prechod z dobre dokumentovane x86 (-64) na ty SoC kramy zalozene na ARMu. Jestli se dobre podivate, tak zadny vyrobce cehokoliv s ARMem nema dostupnou detailni dokumentaci, ani verejnou ani neverejnou. Neni to zazrak ze to funguje, protoze ubastlit lze kde co (vetsinou vam jadro upecou inhouse), ale tomu tak nejak odpovida kvalita veci (stabilita i spotreba je otazkou nahody, totalni katastrofa v ohledu podpory).
Zde je seznam: Apple, Samsung, Qualcomm, nVidia, Allwinner, HiSilicon.
A Intel zadne ARMy delat nebude, zrovna jsem projizdel specifikace k Joule - je to hezky ekvivalent mobilnich procesoru (4C/8T, 14nm, PoP pamet, grafika, jedene externi pmic, 4k30 encode/decode). I s wifi na desticce 48x24 mm. Predpokladam ze tento druh jader by se mohl objevit i ve FPGA po koupi Altery.
To by mě zajímalo kde jsi přišel na to, že na ARM jádra není dostatek dokumentace? Dokumentace poskytovaná ARM Holdings je naprosto dostatečná jak pro výrobce čipů tak koncového zákazníka. Jaká dokumentace ti chybí k ARM jádrům? To že nějaký výrobce špatně zdokumentuje periferie které implementoval do SoC (viz. např. nVidia) přece není chyba ARM jádra.
Nevím jaká je situace u velkých jader, ale k Cortex-M je dokumentace dostatek. Nějakou dobu jsem dělal na bezdrátovém SoC s dvěma jádry Cortex-M na čipu (M4-aplikační procesor, M3-síťový koprocesor). Nikdy jsem nezaslechl, že by si lidi co navrhovali silicon stěžovali na nedostatek dokumentace od ARM.
Z dokumentace toho CPU jádra a ISA toho moc o konkrétním SoC od Qualcommu, Samsungu, nebo odněkad z Číny (Amlogic, Allwinner, Rockchip) moc nezjistíš, ten průšvih nastane až na té úrovni.
Jinak by slušná podpora RPI3 automaticky znamenala, že budou skvěle a hned out-of-the-box bez další práce fungovat všechny SoCy s Cortexem-A53 (a díky RPI2 s A7). Což evidentně vůbec neplatí.
Tak si vezmeme proces bootovani (specificky cold boot):
A) x86: definovany rezim (Real mode), cpu provede load z adresy FFFF:0000 kde by se mel nachazet inicializacni kod (napr. PC BIOS, ale muze tam byt cokoliv)
B) RPi (Broadcom): https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=6685 v prekladu:
- GPU zacne vykonavat interni hardcoded program v romce, ktery nacte neco z SD karty do L2 cache
- neco (bootcode.bit) zprovozni externi ramku a nacte dalsi blob v kroku nize
- neco (loader.bin) nacte firmware pro GPU (start.elf) a zpracuje config.txt a pokracuje na kernel
Krome toho ze to zni velice legracne (proc to delat jednoduse ze..), tak opravdovy problem je, ze vsechny tyto kroky jsou v utajenem rezimu a zdrojaky tech blobu neexistuji. A ted ten problem, proc toto vsechno vim - vyrabime displeje ktere maji jenom preferred mode (custom timing) a zadny standardni rezim. Je to samozrejme spravne indikovano v EDID od displeje. Potiz je ta, ze ten kus blobu u bootovani bud neni pripraven tyto data o displeji pochopit, nebo to vubec neimplementuje = displej nefunguje out of box, jako plug and play. Ale v config.txt lze zadat rucne custom rezim, a s tim to pak jede. Chteli jsme se podivat na implementaci toho zpracovani EDIDu, ale neni to mozne.
Prijde vam porad ARM jako bezproblemovy svet? A to se prosim jedna o jinak velice otevrenou a dobre podporovanou vec - RPi!
To že nějaký výrobce něco pěkně blbě implementuje v nějakém SoC přece nemá nic společného se samotným ARM jádrem. Já třeba zase znám SoC s x86 jádrem (Turbo186) které bootují též velice podivným způsobem. A i když se to nezdá, většina těchto "podivností" má své technické opodstatnění.
Tvé zevšeobecňování mi připadá nesmyslné. Jsou špatní implementace jak x86 tak v ARM světě. Protože těch SoC s ARM je podstatně více, tak i je více špatných implementací v těchto SoC. Nic miň, nic víc za tím není.
spíš by mě zajímalo, jestli vůbec existupe nějaký dobrý příklad. dlouhodobě podporovaný, s dokumentací, s podporou ve vanila, plně funkční bez binární blobů...
Srovnáváte nesrovnatelné. Rpi je hotový subsystém, který má vlastní "BIOS", takže u x86 byste to taky musel srovnávat s mainboardem (asi byste se taky jen tak nedostal ke zdrojákům BIOSU desky a videokarty. (http://wiki.beyondlogic.org/index.php?title=Understanding_RaspberryPi_Bo... a
https://github.com/raspberrypi/firmware)
Na PC existuje CoreBoot jako opensource nahrada BIOSu.
A jak rozjedeš plnohodnotně periferie jako jsou grafické karty, wifi adaptéry bez nedokumentovaných binarních blobů?
x86 bootuje z 0xFFFF_FFF0 který musí být v hardwaru přemapován na 0x000F_FFF0, aby mohl procesor vůbec skočit na nějaký kód (protože na 0xFFFF_FFF0 zbývá místo jen pro far jump). Data se posílají před SPI nebo LPC řadič, který musí být nastavený už z resetu (obchází PCI plug'n'play konfiguraci).
V případě SPI si navíc musí Intel čipset načíst část BIOSu do paměti, ověřit zda sedí certifikát, rozparsovat formát na vnořeném ARC (?) MCU a dešifrovat. Bez toho "MCU" některé počítače ani nenabootují.
Po prvním far jumpu někam do 0x000F_xxxx musíme načíst GDT (aby šlo vůbec používat adresy vyšší než 1MB). IDT (aby šlo v chráněném módu používat přerušení). Obojí jsou komplikované tabulky. Po načtení musí BIOS nahodit chráněný mód zápisem do registru, provést far jump do platné oblasti (definované v těch tabulkách) a nacpat něco jako index v těch tabulkách do všech segmentových registrů (teda v CS je už po tom skoku a teďka se jmenujou selektory a ne segmenty). Tyto tabulky se v linuxu (a libovolném stránkovacím OS) už nikdy nepoužijí (maximálně pro power přechody, kdy se CPU vypíná).
Dále by bylo dobrý zkontrolovat zda je připojenej pin 20 adresních linek (A20 brána), jinak nebude fungovat každej lichej megabajt. Naštěstí ten čip na PC (8042) se nemusí konfigurovat, je mimo PCI sběrnici a navíc často klonovanej na další místa (který se taky nemusej konfigurovat).
Teprve teďka můžeme přistupovat k celému adresnímu rozsahu x86 procesoru, teda pokud není chyba třeba v mikrokódu, který jinak musíme nejdřív updatovat a/nebo pokud nám stačí 64kB BIOSu (rozsah 0xFFFE_xxxx a případné mapování na 0x000E_xxxx) je nutno už ručně povolit (i když to může záležet na čipsetu).
A to ještě nemluvím o tom, že se používá i to, že se ve smyčce přečte celý BIOS rozsah, čímž se dostal do cache i kód, dále takový BIOS vypnul přístup k té adrese odjinud než z cache (asi aby se ty řádky cache nesmazaly) a skočil naslepo na tu adresu, která ale už byla v cache takže to prošlo :-D.
Samozřejmě je ještě potřeba inicializovat kotel dalších registrů pro stránkování, věci jako koprocesor a ani nevím co se má dělat pro povolení NX, VT-x a nebo x86-64.
Je neudržitelné dávat x86 do laptopů asi tak stejně, jako dávat spalovací motory do aut. Je to sice pravda ale obojí se ještě hodně dlouho bude dělat.
Apple chce do svých laptopů ARM zatím jen PŘIDAT nikoliv jim nahradit x86. Takže si v článku autor pěkně zafabuloval zřejmě na základě chybné informace, která se k němu dostala...
Těší mne nostalgie a jistý konzervatismus diskutujících, ale pan Ježek má pravdu. V korporátním prostředí jsme používali na androidech zdálený přístup na virtuální počíteče běžící na windows serverech 2012 R2. Tam běžely kritické systémy a rohraní zhlediska bezpečnosti. Android měl na starosti drobné úlohy používané lokálně. Nějaké ty prezentace, tabulky atd. Už tato platforma zvládala správu klientských zařízení dost dobře. Mnohem větší integrace podpory pro android (a IOS) bude realizována na windows serveru 2017. K tomu se přidají aplikace běžící v prostředí prohlížečů a je vymalováno. Pokud není notebook semi - pracovní stanicí pro specifické úkoly např. typu CAD atp. pro 90% použití nemá ARM problém. Notebook není stanice. I když se někteří snaží dokázat opak. Xeony a x86 tu stále budou, v serverech a stanicích pro těžkou práci.
Kolego dufam ze srandujete. Robim v korporatneho IT ale co sa tyka androidu , skusali sme to ale je tam mega problemov - vzdialeny pristup je nespolahlivy, secure connection je nocna mora, bezpecnost je vtip a ked uz aj pouzijete 3rd party app ako je mobile iron alebo podobne tak jeden update androidu vam to cele rozhodi proste IT nighmare + dalsich 1000 problemov s kompatabilitou. Web aplikacie ano ale len niektore ak su optimalizovane pre IE tak na androide na 99 % nefunguju. Ano mozete sa mi pokusit povedat ze sa to zlepsi ze je to len otazka softwaru. Ale software na Win - x86 platforme je svetelne roky dalej a tak nechapem preco by som mal pouzivat riesenie kde viac ako 70 % veci nefunguje tak ako ma alebo vobec ked mam stabilne riesenie s trilionom dalsich moznosti a vyuzitelnosti. Dalej si neviem predstavit ako by sa to riesilo v korporaciach s 10000 + zamestnancami ? vyhodite vsetky notebooky a date im android ? to nikto neschvali. Vymienat to postupne ? aby ste mali vedla seba 2 systemy ktore su tazko kompatabilne spolu a pritom to nic neriesi ? Momentalne firmam raz za 4-5 rokov staci pomaly obmienat notebooky a ked uzivatel dostane novy notas do hodiny ma tam vsetko co potrebuje.
O profesionalnych softweroch ani nebudem rozpravat tie na androidoch neexistuju a chcem vydiet niekoho kto bude napr autocad ovladat na 5 palcovom telefone alebo 10 palcovom tablete cez vzdialeny pristup.
Upřímně nevím proč mluvíte o ARM a CAD, když jsem uvedl, že je to přesně ten případ, kdy nemá smysl rozvíjet debatu. CAD patří na stanici. Žádný notebook v přenositelné formě na CAD nestačí (pokud pominu 6 kilové experimenty). Z vlastní zkušenosti mluvím o tabletu s klávesnicí (kdy jsou tyhle hybridy ještě tablet a kdy už je to nová kategorie je diskutabilní), biometrickým podpisem, elektronické kanceláři, podpoře obchodníků v terénu - transakce, podpisy smluv atd.) HW je unifikovaný v celé síti a systém odladěný jen na ten užívaný typ. Což znamená nemalé náklady na IT. Ale bez nich bychom mohli ještě dnes orat hákem. Který směr vývoje bude životaschopný ukáže čas. Pokud zabrousím do SOHO tak doma na NTB fakt x86 nepotřebuji. Práci s videem zvládne 6 tijádrový server přes vzdálenou plochu ke kterému už dávno není připojený monitor a i klávesnice jen když je třeba řešit něco nestandardního na místě. Dohromady (SOHO a corp.) je prodejní vektor s nemalým potenciálem. To neznamená, že v některých firmách nebudou x86 NTB ještě dalších 10 let nebo více. Ale budou jiné, kde se za 10 let bez nich obejdou, jelikož jejich funkční a obchodní model bude jiný. Protože v rámci dlouhého cyklu budou zvažovat změnu nebo rozvoj platformy. O individuálních buildech systému včetně uživatelského SW a jejich správě mne nemusíte nijak zvlášť poučovat. S tím se setkal v korporátním prostředí snad každý. Článek je o určité vizi. Nemusíte ji přijmout, to je Vaše právo. Ale neznamená to, že se zcela či zčásti nenaplní. Finanční instituce patří zhlediska IT k nejkonzervativnějším, kdy jádrové systémy běží mnohdy na Unixových mainframech, přesto s touto cestou minimálně experimentují. Kdyby to bylo od počátku tak jasné, že jde o mrtvou cestu, určitě by neutrácely miliony za vývoj. Ty platformy budou dlouho koexistovat bez ohledu na to jestli si tu roztrháme občanky nebo ne :-).
Proč by nestačil, sám občas používám Altium což je CAD pro návrh PCB na vykopávkovém notebooku s jednojádrovým procesorem. Netvrdím, že to jede jako na mém PC s i7, ale rozhodně to není nepoužitelné a kromě pomalejšího zapnutí pokud člověk oželí nějaké 3D renderované pohledy se na tom dělat dá a diky 4:3 LCD se mi na tom dělá lépe než na novějším notebííku s 16:9 LCD.
Měl jsem spíš na mysli náročnější a složitější věci při kterých se zadýchají i nová Quadra. Automotiv atd...:-).
to je spíš efekt nedotažené optimalizace. Např. se renderují modely v sestavě, které nejsou vidět. Když je dokových 10000, tak je to samozřejmě peklo. Například dám kolegovi mode PCB, všetně součástek. To je samo o sobě několik set až několik tisích modelů. Takových deset je ve výrobku 7. Inventor to renderuje v sestavě vždy a vžechno, i když je to schvané v modulech, otevření celého projektu si pak vyžýdá 35GB paněti a nedý se s tím pracovat. Máme tedy zbytečně dva modely - se součástkami a bez. Pro sestavu se pak použije ten jednodušší. Zbytečná práce, pravděpodobně jenom proto, že si někde někdo řekl, že výkonu je dost...
Prepacte moj komentar bol asi moc agresivny. V kazdom pripade odpovedali ste iba na jednu vec z mnoho , ktorymi som argumentoval ja. Taktiez by som chcel podotknut ze CAD bol len priklad existuje milion softwerov ako Matlab,processexplorer, visio,PCB designer atd atd atd atd na ktore vam notebook staci uplne v poriadku ale neviem si ich predstavit na androide alebo na ARMe celkovo.
Také se omlouvám za razanci. Osobně si myslím, že tu určitě budeme mít dlouho rodinu NTB s X86, které něco počítají.. A rodinu zobrazovadel s ARM, které nic z toho dělat nebudou..
Android je do korporátu rozumě nepoužitelný, min. do té doby, než se pořeší updaty - je jeden pro všechny. Mám ale dojem, že i když by se google snažil, tak to je nemožné, protože celá platforma je bordel na kolečkách s hromadou bastlů jak se strany vyrobců (to je ještě řešitelné), tak ale hlavně ze strany SoC a kernelu. Na víc Linux je tvrdě monolitický. Myslím si, že v současné době je nemožné se v Arm-Android světě dostat k univerzílním centralizovaným updatům, jak to známe z windows. Kernel musí updatovat výrobce SoC, vlastní systém (a často i částečně kernel) výrobce zařízení.
Jediná cesta by byla nějakým (absolutně nevím jak) donutit, že všechny použité SoC a jejich moduly musí být podporovány v mainline, nebo změna architektury se stabilním ABI a ovladače ven z járda. Obě možnosti jsou v dohledné době mimo realitu...
Jenže to neřešíš problém, to jej obcházíš. Tím, že z ARMovské krabičky uděláš tenkého klienta, ses nezbavil x86 aplikací na terminálserveru.
Jenže cílem není zbavit se aplikací, nýbrž zbavit se drahých zařízení založených na x86. Možnost používání stávajících aplikací je naopak velká výhoda.
Tak ti nevím, ale laciný Atomový notebook s pentium N dnes koupíš za 5 litrů... A samotnou cenu určuje spíše kvalita obalu notebooku a displej. A kromě toho, že to lze použít jako terminál, to lze použít na Citrixu i k zábavám typu streamování aplikací (narozdíl od ARMové šlupky).
No vzhledem k ceně licencí potřebného SW je náklad na HW naprosto zanedbatelný.
Mne to skor pride ako Autorov vlhky sen aj kvoli linuxu a tej jeho predstave ze cim lacnejsie tym lepsie.
x86 platforma nas mozno aj prezije. Ked sa na to pozriete komplexne tak pre ARM mozno okrem spotreby nic nehovori neni tam App base , neni tam OS base ... nic.
Delší dobu si všímám, že někteří fanatici považují ARM platformu za něco otevřeného, protože si na to jednou něco zbastlili. Už nevidí to, že u X86 nic bastlit nemusí, vše už je hotové a díky dlouhé standardizaci prostě funguje...
"Je neudržitelné dávat do notebooků x86 procesory"
Tuhle myšlenku slýchám co dva roky už asi 20 let a ono zatím nic, takže si dovolím být nadále skeptický
A pokud se tak stane, všichni přejdou na nový ARM based Win OS a Váš linux stejně ostrouhá.
Sen, který sníte tak jako tak nebude.
Kdyby mi chtěl někdo odporovat, tak nejdříve shlédnout toto https://www.youtube.com/watch?v=A_GlGglbu1U
Lidi, kupte si Pi, nainstalujte Raspbian, stáhněte si Firefox, spusťte a zkuste deset minut surfovat. To vám dá jistou představu, jak na tom současný Arm s výkonem proti x86. Ano, není to Snapdragon 835, ale ten to moc nezachrání - ten bude párkrát rychlejší, nicméně je potřeba překonat řádový rozdíl.
Na spuštění vzdálené plochy v korporátním prostředí to samozřejmě stačí, ale osobně bych teda takový netbook pro "plné" aplikace používat nechtěl.
Tak tyhle laciné ARMy nejsou zrovna směroplatné. Když zkusíte iPad s A9 (nebo něco s tím Snapdragonem 835), tak tam je prohlížeč násobně svižněší než na běžných x86 notebookových ořezávkách. Člověka to až zarazí jak v pohodě se vyrovnává s Drupal monstry typu těchto stránek nebo s UHD videem (pochopitelně s pomocí grafiky). Srovnávat to s i7 pochopitelně nemá cenu, ale zase na prohlížeč a kanclsoft mít i7 je jako jít s tankem na vrabce.
Problém je spíše kompatibilta aplikací, než že by dnes nebyly dostatečně výkonné ARMy na běžné použití.
Jenomže tady ty mobilní browsery jsou hrozné ořezávky - třeba "zapomínají" taby na pozadí, zastavují je, nemají žádná rozšíření a jsou celkově optimalizovány na plečkovní procesory. Člověk nemusí mít iPad, klidně i mobilní Chrome nebo Fennec na androidu fungují obstojně. Navíc aplikace "na pozadí" mají zásadně jiný režim, než na PC. To je všechno samozřejmě správně - kdo by chtěl mít zasekaný mobil nebo tablet, tady ty ústupky a optimalizace se udělat _musí_, aby to šlo používat.
Ale je nefér srovnávat tady tu nízkovýkonovou ořezanou platformu s plným desktopem a vydávat to za benchmark, protože desktop na nic takového optimalizovný není. Abych to nějak absurdizoval, připadá mi to jako vzít 4K video, převést jej na 320x200, nechat to 4K přehrát na počítači a to 320x200 na Píčku a pak na základě tohto "testu" prohlásit, že obě platformy přehrají stejné video a jsou tudíž vlastně výkonově rovnocenné.
Aby bylo srovnání objektivní, je potřeba spustit si stejný kód, jaký běží na té x86, kterou chceme ARMem nahradit. Na to mi přijde ten Rasbian optimální, i když je vlastně taky osekaný - má třeba velmi lightweight prostředí.
A na otázku, jestli by vlastně běžným uživatelům nestačil tak ořezaný desktop, aby fugoval na ARMu, existuje velmi jednoznačná odpověď - nestačil. Stačí se podívat, jaké je zastoupení androidu, ARM Windows a iOS na desktopu - nula celá něco málo procenta uživatelů to uspokojí. A rozhodně se nedá říct, že by se třeba v MS nesnažili uživatelům tuto alternativu nabídnout, dokonce se dá říct, že na to vsadili svou čest.
x86 je dnes tažný kůň, který se psím spřežením ARMů pro těžbu dřeva nahradit prostě nedá a tato situace ještě několik let vydrží. Ale David má pravdu, časem se to posune. Existují tři cesty, které všichni, kdo to myslí vážně, už řeší. Zaprvé zvyšování výkonu ARMu a alternativních platforem obecně, zadruhé přebírání optimalizací z "mobilních" platforem do desktopových OS a jejich "debilizování" a zatřetí přesun výkonu na server v podobě různých "cloud" služeb. Nakonec tu x86 utlučou čepicemi.
Když ono je to o tom, že většina BFU fakt to dřevo netěží. Jim stačí fejsbůk, jůtůb a nějak se dostat k mailu v prohlížeči + nějaký ten Kanclsoft a to fakt dá i ten ARM s prstem v nose ve 4k (protože mu píchne grafika).
Nemyslím si, že by to bylo hned, ale čím hůře se bude dařit Windows jako hegemonovi závisláckém na x86, tím otevřenější vrátka pro jiné CPU.
Až se to "posune", bude ARM ve stejném stavu jako x86, takže nahrazovat jej bude bezpředmětné.
To si myslím taky, ale pšššt, nekaz tu iluzi jednoduchého procesoru proti molochu. :-)
Tak predne co se Ipadu tyka tak jediny duvod proc se ti mozna zda sviznejsi je ze prohlizec nic moc neumi a jede vicemene jen v jednom okne, otevri si v tom 100+ tabu a pak se muzeme zacit bavit o tom co je sviznejsi.
Arm je fajn v mobilu pripadne tabletu ale v rozumnych noteboocich ci desktopech nema co delat. Jednak kompabilita softu a jednak vykon nejsou dostatecne.
V životě jsem neměl potřebu mít otevřeno 100+ tabů. :-). Jsem holt pořádkumilovný a raději otevřu ze záložky než mít tuny tabů, stačí pár jen tomu co se zrovna věnuji. Ale to je spíše o paměti, tab na pozadí má nejlépe spát.
Nepopírám, že ty browsery jsou jednodušší, ale co se týče renderování stránky, tak za dospělými prohlížeči nezaostávají. Koneckonců ty nejlepší ARMy se vyrovnají zhruba i3 a přitom mají lidi v netebookách mnohem strašnější "chroustadla. Většina levných notebooků by mohla vyprávět.
A to se zase vracíme k tomu co bylo na začátku, a to je, co kdo potřebuje a nepotřebuje. Fakt je ten, že "většina" si vystačí s FB a webmailem. Ale co ten zbytek?
Nejlepší ARMy se nevyrovnají ani PentiuN, natož i3. Jistě lze najít syntetické "testy" kde se ARM dotáhne na i3, ale to je asi tak vše.
S čím si kdo vystačí nebo nevystačí a kolik má otevřených tabů je jenom pavlačová diskuse o dojmech. Reálně jde vidět, že toto prostě nefunguje - různé "Transformery" nebo jiné notebooky s ARMem prostě zmizely, protože to asi nestačilo. FB a webmail tato zařízení v pohodě zvládla, byla často levnější, než běžné notebooky, měla masově rozšířený systém a dost aplikací, byla lehoučká, dlouhá výdrž atd., ideální. A výsledek? V mobilech ARM lidi berou, tablety jako přechod k notebooku umírají i u Apple a notebook s něčím takovým v podstatě neexistuje, protože by si to nikdo nekoupil.
Myslel jsem to spíše tak, že mi šlo o potenciální/hypotetický "běžný" počítač s ARM a Windows pro nenáročné spotřebitele.
Transformery apod. končí většinou proto, že to není ani ryba ani rak - plovat to pořádně neumí a klepeta jsou slabá jako čaj. :-)
Jinak bezvýhradný souhlas, vidíme to hodně podobně.
Tak jistě. My to hodnotíme skrze naše potřeby, ale BFU si pak koupí plastový NTB za desítku s nějakým dýchavičným Atomem (a že jich je) a možná zjistí, že jeho Android na ARMu má mnohokrát lepší "user experience" než táhnout monstrum velkého OS na takovém ořezávátku.
Já zatím též potřebuji velký komp s x86 na práci, ale kdo ví co bude za 10 let. S různými "výpočetními" API by se kupříkladu ARM mohl změnit na něco jako řídicí procesor systému a vše náročné by delegoval na výpočetní jednotku (řekněme zatím grafiku). Nebo nějak úplně jinak. To vše se ovšem zřejmě netýká Windows, které jsou za ta léta příliš zapečené do x86. Ale jsou to všechno jen takové úvahy. Microfot podle mě nemá žádný zájem na změně. Apple pokud chce být ještě placatější a úspornější může mít motivaci a schopnost vyrazit novým směrem, ale osobně tomu moc u macOS nevěřím.
Jinak pokud si člověk chce osahat slušně výkonný ARM, tak je fakt nejlepší a nejjednodušší si zkusit osahat ten iPad (klidně někde v Applestoru) i když jej třeba nemáte rádi a to proto, že to je v jádru prostě FreeBSD s grafickou jablečnou nadstavbou a běhají tam nativní 64 bit ARM aplikace bez javy nebo jiné mezivrstvy, má to velké rozlišenî a kompletně šifrované úložiště - takže je celkem hezky vidět co v tom pouze dvoujádrovém procesoru je za potenciál.
Ale to je úplně něco jiného - Kodi na Raspberry Pi 1 jede taky jak z praku, a to je úplně prašivá 700MHz (?) Cortex-A6. To celé dokazuje, že jde udělat "na zakázku" úsporná softwarová platforma - což koneckonců není nic divného, DOS na 486 s 4MB RAM a 0,05GHz procesorem taky běhal jak z praku, včetně různých grafických věcí.
Ale spustí uspokojivě současné aplikace z Windows nebo Linuxu? Ne. A o to tady jde. Lidi už si znovu masově procesory s výkonem prvního Atomu nekoupí, protože kdyby po nich toužili, tak je donedávna měli normálně v nabídce a různé plečky se dají sehnat i dnes.
Problém je, že to je nesrovnatené. :-)
Druhá otázka je, jestli je tedy potřeba těžkotonážní OS na BFUistické potřeby, když už existují odlehčené OS a popravdě se funkčně přibližují těm těžkým, ač jsou filosofií dost jiné zejména kvůli dotykovému ovládání. Ale jak jsem napsal jinde, to jsou jen takové plané úvahy.
x86 architektura tu bude ještě pěkně dlouho. Pokud jsme si zvykli na levný výkon, není zatím jiného řešení. Plnotučná Windows pro ARM, jak tu kdosi psal jednoduše nejsou, protože pak by ty finální výrobky prostě neposkytovaly to, co se od nich očekává. Nízkou cenu a zároveň potřebnej výkon. I ten výkon, ke kterému se ARM dobral by vzal za svý při emulaci prostředí pro win32 aplikace, který většina chce využívat. Proto existovaly neúspěšné windowsy, které ovšem win32 apky neuměly spuštět. No a o to byl minimální zájem. Za dlouhodobou existencí x86 stojí tuny nativního sw a nic nenasvědčuje tomu, že se cokoli změní. Herní "Performance sw" ještě dlouho bude jen pro x86 resp. x64. Crysis 4 v java kódu ? Asi ne. Jak to tak vypada, budoucnost bude patřit stále x64, kde se obsoletní balast pomalu odstraní. Viz. nedávné zprávy o odstranění MMX instrukcí anebo, to je živé už nyní, staré, málo používáné instrukce v čipech běží pomaleji - emulace na úrovni hw (?) a to jen kvůli potřebě zpětné kompatibility.
x64 bude stále více energeticky škálovat a pokryje veškerou, potřebu. Zajímavé by bylo, co by nastalo, pokud by Intel a AMD uvolnily k licencování x86 a x64 architekturu. Zabilo by to ARM ?
Ale veď v Číne (čo je pekne veľký trh) funguje čínsky x86/x64 Zhaoxin (VIA Alliance Semiconductor Co Ltd.), ktorý má v portfóliu dua-core, quad-core, octa-core procesory.
zdroj: http://www.zhaoxin.com/Solution.aspx?id=3
A jak je na tom ARM na serveru naleznete dobré srovnání např. zde: https://www.servethehome.com/exclusive-first-cavium-thunderx-dual-48-cor...
Dobrý. Takže....and very quickly see that an ARM core is not equal to an Intel Haswell/ Broadwell core.
V raytracingu Intel 2x 8c/16t x64 poráží 2x 48c/48t armv8. Tak snad ten ARM vyjde levnějc, sw&support bude levnější a pápne míň energie. Jinak nevím k čemu je to dobrý. Na tyto otázky ale článek neodpovídá. Tak snad aspoň ten cloud.
Za vším hledej peníze. A rychlost. Příklady: Co běželo v praxi rychleji? Účtování v SAP na lokále nebo ve virtuálním počítači farmy nabušených Xeonů v datacentru? B je správně - pochvalovala si asistentka. A neplatí to jen pro SAP. Pokud mám zaměstnance co celou šichtu buší data do centrální databáze přes terminálové služby nebo vzdálený přístup je to jen otázka návrhu.. kde se dá ušetřit a kde naopak přitlačit. Zrovna v tomhle případě není třeba se nad Armem ušklíbat. Akcelerovaný přenos vzdálené plochy zvládne s prstem v nose. Věci jsou barevnější.. ne černobílé. Myslím si, že v IT stejně jako jinde jde o předem připravený návrh infrastuktury a ne jako když kočička s pejskem pečou dort. Podle optimalizovaného návrhu se tu zaplatí servery tu úšetří na koncových bodech..Tu x86 jindy něco jiného. Třeba řízení letového provozu bych na x86 a win moc nechtěl.. a jesti už je to pravda tak už asi nelítám:-).
Tenhle příspěvek píši na HP Pro book s i3 5010U. Podle Geekbench má stejný singlecore výkon jako Snapdragon 935 a pouze 2/3 v multicore tj za Armem ztrácí. O videoakceleraci, a dalších integrovaných věcech škoda mluvit. Taky by asi nepotřeboval ventilátor. Takže ARM dospěly. Jen by to chtělo vylepšit OS.
Copak dnes se programuje v assembleru? Jsem slyšel, že dnes dělat něco v assembleru je kontraproduktivní vzhledem k vyspělosti kompilátorů. Což potvrzuje např. hudební organizér Music Bee, který si strčí rychlostí zpracování velkých dávek alb takové machry jako Foobar 2000 s jeho album list nebo Winamp s jeho library, do kapsy, a to je údajně psaný ve Visual Basicu... Takže je skutečně problém v architektuře CPU nebo spíše v OS (32bit / 64bit)?
Ale jistě. Typicky optimalizovaný SIMD kód. I u některých běžných knihovních funkcí je rozdím naprosto propastný. Třeba takové obyčejné memcpy, mezi kompilátory na x64 jsem viděl rozdíl 6x...
No to hold nesmíš používat knihovny, které autor kompiloval bez zapnuté optimalizace :)
To není jenom věc nastavené optomalizace. Např. embarcadero builder (C) a MS C. Po krokování v ASM - první vmenovaný u této funkce - očividně nějaký prostý for. MS lezl přes SIMD, a FPU, ani jsme přesně nepochopili, jak to funguje, ale mají to 6x rychlejší. To není věc optimalizace, se kterou to bylo zkompilované, ale toho, že to někdo tak, asi přímo v ASM napsal. Některé věci tak taky v softu máme - optimalizace x64 některých kritických věcí v SIMD ASM. Běžné věci kompilátor vymyvlí lépe než člověk, ale tohle ne, případně to musíte psát přesně nějakým stylem v C aby to pochopil (třeba for cykly v C pro AD DSP aby to pochopil a použil DAG jednotky) - a to je zase vendor lock....
Efektivní kód se jinak psát nedá. O zvěrstvech typu - Java VM na mobilu pro vše ani nemluvím, to to tragédie, navíc ani na tom ARMu to potřeba není. Nakonec iOS APPs jsou nativní....
V tomto smyslu mě nejvíc zajímá, jestli bude Ryzen podporovat FMA3 (a zda ano / už ne FMA4) a TSX. Resp. jestli ten jejich A.I. scheduler nebo jak to nazvali není v mezičase lepší řešení, než programátoři začnou používat TSX (jestli kdy) - tím by AMD trošku vypálilo rybník Intelu, kdyby měli něco jako "autoTSX". Protože .NET JIT FMA3 umí a používá, u FMA4 (stavební stroje), si nejsem tak jistej. Svým způsobem se tady totiž bavíme o instruction set wars a o nepřítomnosti SSE5 - AMD tedy možná půjde cestou ASF a další bordel na světě. Šifrování evidentně není problém, v tom je Ryzen (na jeho frekvenci) nad 6900K. http://tinyurl.com/jk3edwz
Ani bych si nedivil, že kompilátor od Embarcadero neprodukuje nějaký rozumný kód. Vždyť ta firma ustrnula v dávné minulosti a žijí z programátorů "těsně před důchodem" co se nejsou už schopni naučit něco nového. Jejich reklamní maily mi připadají Horsta Fuchse z teleshoppingu - kupujte dokud jsou, nebudou, nebudou...
V libavcodec ti nepřijmou assembler, který čeká navíc jeden takt nebo ignoruje cache preload efekt:
http://ffmpeg.org/pipermail/ffmpeg-devel/2008-May/053683.html
Stejné instrukce nejsou v GCC ani generovaný a to je jen upravenej MMX od intelu pro intelí ARM :-D.
Jiste ze se v asm nedela cela aplikace nebo knihovna. Ale stale se vyplati sem tam nejaky kousek v asm napsat. A pak je to kousek tady, kousek tamhle a u vetsich veci se to docela nasbira.
Nemusi to byt vylozene asm kvuli vykonu, ale pro pouziti intrukci procesoru jinak nez to umoznuje programovaci jazyk. Videl sem asm kod pro atomicke operace, protoze v c++ nejsou dostupne takovym zpusobem jaky byl pozadovan.
Tomuto přístupu se snaží moderní vývoj vyhnout jak to jen jde, ale je pravda, že především realtime aplikace nebo náročné hry se snaží vyhnout operacím dělení a násobení, nebo pokud není podpora SIMD v překladači, tak se kus udělá v asm. Jo ještě se tak przní NT jádro, proto je obtížně portovatelné mimo x86.
Není nadto sepsat článek, který zvedne emoce. Emoce = diskuse = návštěvnost. To Ježek moc dobře umí. Meritum článku je jak ohraná písnička. Kdyby tam byla datum l.p. 2010, nic by to na tom neměnilo. Stejně tak stačí tenhle článek vydat v roce 2020 a bude to pořád stejné a stejně ohrané.
O konci x86 se mluví od doby co x86 nastoupilo. A ještě tak 20 let se mluvit bude.
Takhle vidí RDS (vzdálenou plochu Microsoft. H264, 4K, Photoshop, AutoCAD, Solidworks and similar middle-weight GPU-powered solutions. IOS a Android.
Xeony - servery, koncová zařízení cokoli co dokáže zpracovat H264.
https://blogs.technet.microsoft.com/hybridcloudbp/2016/11/15/new-rds-cap...
Toto je fajn vize a myslím, že to může i po technické stránce fungovat. Jediné, co mi u těchto Desktop "aaS" zatím vždycky neštimuje je to, že je to v reálném životě dražší, než koupit normální hardware a provozovat to na vlastní stanici. Protože představa MS bude určitě nějakých plus mínus minimálně 1500Kč / měsíc a to mi přijde při dnešních cenách jako blbost.
Krása "Desktop-aaS" většinou končí s první flashkou, jejíž obsah potřebuješ do tohoto desktopu nahrát. :-) A to je teprve začátek, pak se to zvrhne ve specializované karty, přechod na VDI a po zaplnění serverovny, útratě spousty peněz a bolehlavu ajťáků k pokornému návratu k pracovním stanicím. :-D
Netvrdím, že to takto dopadá vždy, jen nelze mluvit o univerzálním řešení. Je to řešení pro některé typy infrastruktury a nepopírám, že třeba Citrix mám hodně rád, za těch 10+ let mi jeho filozofie přirostla k srdci, ale všechno ocamcaď-pocamcaď.
No defakto jen 1500 za měsíc za Windows a Office ...
A kto prevedie tie tisícky plateného softu na ARM ? Stačí sa len pozrieť aké problémy sú s x64. A pre mnohých by to znamenalo aj výmenu desktopu.
Aha ... takže pokud si odskočíme třeba k tabletům, tak zjistíme podle aktuální statistiky, že Androidí a iOS zařízení zažívají obrovský pokles prodejů, zatímco ty "Wintel" tablety naopak rostou.
Za takové situace tvrdit, že Wintel je v notebooku překonaný zavání naprostou ignorací. Právě tablety dokazují, jak je ARM platforma dobrá leda tak do mobilu a na nic většího se nehodí, ať už na ní běží Android nebo iOS. Uzavřený systém bude vždy použitelný pouze pro konzumaci obsahu. Na práci a tvorbu obsahu tu naštěstí máme kombinaci Windows plus Intel a po nějaké době to vypadá konečně zase i na AMD.
Pri pohledu na to, jak jsou Windows cim dal tim min otevreny, jeste stesti ze tu mame Linux.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.