Hlavní navigace

Apple představil Macbook Air, Macbook Pro a mac Mini na bázi vlastního 5nm procesoru ARM

Sdílet

David Ježek 11. 11. 2020
Apple M1 Autor: Apple

Počátek konce Intel x86 u Applu a další revoluce v jeho nabídce. Apple představil tři nové počítače (dva notebooky a jeden stolní minipočítač) stavějící nikoli na Intel CPU, ale na vlastním ARM SoC, Apple M1.

Procesor nese 4+4 jádra CPU, 8jádrové GPU a 16jádrový Neural Engine, plus další související výbavu. Celkově čip obsahuje 16miliard tranzistorů a je vyráběn 5nm procesem u TSMC, nejpokročilejším výrobním procesem na světě. I proto se Apple chlubí tím, o kolik je nový M1 lepší v operacích než libovolný Intel x86.

Po přechodu od Motoroly k PowerPC a následně k x86 jde o třetí významnou architektonickou revoluci u Applu. Paradoxně na tom je platforma IBM POWER dnes možná lépe než Intel x86, ale to je jedno. Apple míří k cíli, který mu vytyčil již dávno Steve Jobs, a sice být nezávislým na komkoli jiném.

Tedy pokud lze u fabless výrobce, absolutně závislého na geopolitické i přírodní situaci na Tchaj-wanu a víceméně libovůli TSMC, která má velký přebytek poptávky na své výrobní kapacity a která sama je s novými výrobními procesy zcela závislá na nizozemské ASML, která jí dodává zdroje EUV světla.

U Intelu je Apple od roku 2006 a dotáhne to nejspíš do roku 2022. Velmi solidní výdrž. Uvidíme, jaké procesory bude schopen dodávat Intel za dva roky, obvykle u Applu platilo, že dobře ve velkém předstihu odhadl, kdy se přesunout na jinou architekturu / jiného výrobce.

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 11. 11. 2020 0:29

    Tom04

    Co vůbec znamená "8jádrové GPU"? Pokud se nepletu, tak moderní GPU mají tisíce "jader". Například nová Navi 2560 stream procesosrů, neboli grafických jader. Co apple a ostatní (qualcomm...) tímhle počtem jader myslí?

  • 11. 11. 2020 7:16

    David Ježek

    Já už to roky neřeším. Vem si, že Nvidia se drží svých CUDA jader (či jak tomu teď nadávají), AMD zase stream processorů - ale sdružuje je do Compute Units. A těch už nejsou tisíce, ale jen desítky (či jednotky u menších/starších APU). CO tím myslí Apple, je mi šuma fuk ... třeba to, že 8core CPU + 8core GPU + 16core blabla vypadá hezky marketingově a podsouvá nějaké sdělení.

  • 11. 11. 2020 17:44

    kaliszad

    V prezentaci [0] mají v čase 11:22 slide k technickým detailům. 8 jader -> 128 execution units, 24576 threadů v souběhu, 2,6 TFlops, 82 Gtexelů/s, 41 Gpixelů/s. Jinak poměrně detailní rozborka A14 resp. částečně M1 je dostupná na Anandtechu. Z ní vyplývá, že Apple nejspíše nelže, když výkoná CPU jádra v M1 popisuje jako nejvýkonnější CPU jádra na světě. [1]
    U GPU bude počítání principem podobné spíše Intelu, který taky počítá EU kde jsou spíše v nižších dvouciferných číslech a tedy někde na polovině až třetině toho, co je v M1. [2] Výkon GPU v M1 by mohl odpovídat Iris Xe MAX, tedy aspoň s ohledem na TFlops.

    Zajímavé je, že Apple M1 CPU budou mít podobně jako A14 velmi dobrý výkon ve floating point, což se hodí na výpočty (nejenom) v JavaScriptu. Je tedy pravděpodobné, že OrgPad.com, na kterém spolupracuji, poběží nejlépe právě na zařízeních od Apple (nejspíš v Chromu, protože Safari je příšerné z hlediska podpory standardů). Tedy aspoň do doby, než Pavel udělá fyzikální animační engine na bázi CSS, který bude akcelerován v hardwaru. (Ano, omezenci okolo webových standardů nespecifikovali fyzikální animace v CSS - aspoň teda podle toho, co jsem pochytil.)
    Dále je hodně pravděpodobné, že tohle bude poměrně zásadní skok dopředu a ostatní výrobci čipů pro servery až hodinky budou nuceni se zamyslet, jestli náhodou nechtějí nabídnout něco konkurenceschop­ného. Amazon Graviton 2 jde správným směrem, ale single thread je tam mnohem slabší než u jader v M1. AMD se asi zatím své nově vybudované pozice moc bát nemusí, protože je dost softwaru, který nikdo pro ARM v dohledné době přepisovat nebude. Podobně je to i u POWER, kde má IBM výhodu v určitém lock-inu. Na druhou stranu se musí snažit, aby byli relevantní i pro věci, které nejsou v COBOLu s trochou nadsázky, protože jinak jim postupně trh vymře. Jediná výhoda těchto tří hráčů a pár dalších (např. Intel) je, že Apple nebude nabízet serverové čipy, které by měly např. 64 jader místo jen 4 (výkonných). Zákazníci ale budou chtít vědět, proč nemůžou dostat tak dobrý single-thread výkon jako u Apple, který pro spoustu věcí je stále ještě hodně relevantní. Např. +- naivní kód v Pythonu nebo třeba i C, který ale plní svoji úlohu a nikdo to nechce přepisovat, ten poběží možná i o desítky procent rychleji na Apple počítačích než potom někde v Cloudu. Jenom chci poznamenat, že takového softwaru je opravdu hodně.

    [0] https://www.apple.com/apple-events/november-2020/
    [1] https://www.anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive
    [2] https://en.wikipedia.org/wiki/Intel_Graphics_Technology

  • 11. 11. 2020 18:16

    Filip Jirsák

    Ano, omezenci okolo webových standardů nespecifikovali fyzikální animace v CSS
    Jistě, ve webových standardech musí být přesně to, co vy chcete, a musí to tam být hned.

  • 11. 11. 2020 21:22

    kaliszad

    Nechci se hádat o názor, co musí nebo nemusí být ve webovém standardu. Účelem standardu je unifikovat a poskytnout robustní řešení určitého problému tak, aby na to bylo spolehnutí a dalo se to efektivně implementovat v produktech, která mají mít určitou interoperabilitu.

    Jistě budete souhlasit, že fyzikální animace jsou reálně to, co uživatelé chtějí, protože to vypadá přirozeně. Btw. jsou fyzikální animace to, co tu s námi je minimálně od uvedení iPhonu, takže času na to bylo opravdu dost.
    Takhle máme situaci, že většina animací na webu a např. v aplikacích na Androidu prostě není pěkná. Úkolem standardu je vyřešit něco, co je běžné zadání tak, aby nemusel každý vývojář vymýšlet kolo znovu.
    Je to asi jako kdyby si každý vymýšlel rám okna a tlačítka pro zavírání a zmenšování. To asi taky obyčejně nechceme a 99% případů je lepší, když se na to použije nějaký framework nebo API operačního systému.

    Shrnul bych to tak, že zrovna s fyzikálními animacemi v CSS (a já nic jiného nezmiňoval) by se vyplnilo přání mnohých vývojářů, kterým není estetický zážitek uživatelů a přitom dobrý výkon aplikace ukradený. Chápu ale, že tohle možná jde úplně mimo standardizační výbor, kde nejspíš sedí jedinci, kteří nikdy moderní, vizuálně přitažlivou webovou aplikaci nepsali a nemůžou tedy tušit, co je podstatné pokud jim to někdo jiný neřekne. Rozhodně taky chápu, že nemůže každý umět všechno. Možná se mýlím a potom se omlouvám a sypu si popel na hlavu.

  • 11. 11. 2020 22:26

    Filip Jirsák

    Jistě budete souhlasit, že fyzikální animace jsou reálně to, co uživatelé chtějí, protože to vypadá přirozeně.
    Ne, s tím souhlasit nebudu. HTML byl původně jazyk pro značkování textových dokumentů, pak se k tomu přidalo CSS, aby se základním způsobem mohl určit vzhled dokumentu. Od té doby se to neskutečným způsobem vyvinulo, dnes se ve webových technologiích píšou celé aplikace, včetně bitmapových editorů které konkurují Photoshopu, včetně kancelářských balíků. Jenže s tím se logicky neustále zvětšuje množství požadavků, co by prohlížeče ještě měly umět. A logicky nejde implementovat vše najednou.

    Btw. jsou fyzikální animace to, co tu s námi je minimálně od uvedení iPhonu, takže času na to bylo opravdu dost.
    Času bylo dost, ale lidí bylo málo. Potřeba řešit v prohlížečích layout byla zřejmá před více než dvaceti lety – a flexbox tu máme pár let, css grid necelé dva roky. A to je potřeba řešení layoutu tisíckrát důležitější, než fyzikální animace.

    Je to asi jako kdyby si každý vymýšlel rám okna a tlačítka pro zavírání a zmenšování. To asi taky obyčejně nechceme a 99% případů je lepší, když se na to použije nějaký framework nebo API operačního systému.
    No tak na webu si každý vymýšlí rám okna a tlačítka pro zavírání a zmenšování. A vymýšlí je i spousta aplikací – např. webové prohlížeče.

    Když už někdo chce na webu řešit fyzikální animace, může použít nějakou knihovnu. Ano, výkon nebude tak dobrý, jako kdyby to bylo implementováno nativně. Ale v prohlížečích je spousta věcí, které řeší knihovny a které by ten nativní výkon využily ještě daleko více. A také je tam spousta věcí, které prostě žádná knihovna zevnitř prohlížeče vyřešit nemůže.

    např. v aplikacích na Androidu prostě není pěkná
    Za to, že to Google neimplementoval do Androidu, také můžou webové standardy? Nebude to spíš tak, že je vlastně skoro nikdo nepotřebuje? Že je to přesně ta nice-to-have vlastnost, na které si potrpí Apple, aby uživatelský zážitek dotáhl do posledního detailu – ale ve skutečnosti to není nic, co by u uživatelů rozhodovalo?

    Shrnul bych to tak, že zrovna s fyzikálními animacemi v CSS (a já nic jiného nezmiňoval) by se vyplnilo přání mnohých vývojářů, kterým není estetický zážitek uživatelů a přitom dobrý výkon aplikace ukradený.
    Jenže takových standardů, které by vyplnily přání mnohých vývojářů, jsou stovky. Napsal jste velmi trefné slovo – „omezenci“. Které ovšem vůbec nepatří autorům webových standardů, zato velmi trefně sedí na vás. Vidíte svůj uzoučký výsek webových technologií a myslíte si, že zrovna to, co vy znáte, je pupek světa. To, že máte velmi omezený pohled na svět, je váš problém. Ale nehodnoťte na jeho základě lidi, kterým nesaháte ani po kotníky.

    Chápu ale, že tohle možná jde úplně mimo standardizační výbor, kde nejspíš sedí jedinci, kteří nikdy moderní, vizuálně přitažlivou webovou aplikaci nepsali a nemůžou tedy tušit, co je podstatné pokud jim to někdo jiný neřekne.
    Hlavně ale nechápete, jak dnes vznikají webové standardy.

    Rozhodně taky chápu, že nemůže každý umět všechno.
    Tak příště hlavně myslete na to, že vy neumíte všechno.

  • 12. 11. 2020 0:33

    kaliszad

    Nevím, jak jste usoudil, že někomu abstraktnímu nesahám ani po kotníky. V jakém ohledu to myslíte, jako nějak celkově? Prosím Vás, co jsem komu udělal?

    Nepřijde Vám, že když někdo chce něco standardizovat, že by asi měl být v odvětví expert a kromě toho mít ještě určitý nadhled, což je přesně smysl standardu? Na úrovni CSS se dalo přidat pár detailů a ty fyzikální animace tam mohly být s minimálním úsilím navíc! Místo toho teď budou lidé psát knihovny (a ono jich bude víc), které tohle budou bastlit přes JavaScript a nebo kombinaci JavaScriptu a CSS s řádově vyšším úsilím pro horší výsledek. Možná ti takzvaní experti ale nemůžou nadhled mít, protože všechno lámou přes koleno v C++ nebo nově Rustu, kde samozřejmě přidat pár detailů aby chodily fyzikální animace je porod, protože musíte řešit spoustu detailů, které s řešením problému prakticky vůbec nesouvisí.

    Dobře, pokud Vám nejsem dostatečně kompetentní já, tak Vás možná překvapí, že já jenom s myšlenkou souhlasím, ale ten názor na fyzikální animace a CSS není z mé hlavy, ale z hlavy někoho, kdo pro Google pracoval na vyhledávači, má PhD z matematiky z MatFyzu a je i jako člověk a odborník rozhodně mimořádný až geniální a to nejenom podle mého soudu.
    Jak jsem psal, přesně tento člověk si tu knihovnu hodlá napsat sám, protože prostě aktuální animace v CSS nejsou dostatečně dobré, abychom to mohli předkládat našim uživatelům a react-motion má taky své četné nedostatky, které bohužel musíme do té doby tolerovat.

    Nezamyslel jste se někdy na tím, že se možná jen věci tak nějak patlaly (a patlají) a že by ten web obecně mohl být úplně jinde, když jsme už před více než deseti lety pochopili, že se ve webovém prohlížeči bude dělat prakticky všechno?
    Možná se mohl pro začátek upravit JavaScript tak, aby uměl používat celá čísla. Ten CSS grid je fajn, ale mohl tu být už před tak 10 lety, ale to všichni jen breptali, že tabulky na layout ne-e a nikdo nepřišel s konstruktivním návrhem jak jenom neškatulkovat divy s různými offsety.

    Mimochodem Google je asi jednou z firem, kterou by kvalita webových aplikací mohla zajímat hodně a je to firma, která Android vyvíjí. Jejich cit pro uživatelskou přívětivost je ale znát už jenom když otevřete Gmail. Nastavovátka na všech hranách a i uvnitř. Nic není vyloženě očividné a hlavně nic z toho není pěkné. Dobře, neplacený produkt. Bohužel úplně stejně nebo hůř vypadají i věci v rámci GSuite nebo Workplace nebo jak se to teď jmenuje. Pokud lidé s takovou zkušeností tvoří webové standardy, tak je zcela nasnadě, proč v CSS nejsou fyzikální animace a proč věci fungují tak, jak fungují.

    Nakonec vůbec nechápu, proč se obouváte do mě a to ještě ad hominem. Máte snad nějakou konkurenční představu, co by se mělo upravit v CSS, kde byste měl pocit, že můj postesk by mohl Vaši představu zpozdit? Vy nechcete esteticky dobře vypadající aplikace ve webovém prohlížeči s menším úsilím pro vývojáře? Znáte snad někoho osobně, kdo by cokoliv na webu standardizoval a koho jsem se podle Vás asi neoprávněně dotkl? Jakou kvalifikaci podle Vás musím mít, abych se mohl k něčemu vyjadřovat. Musím nejdřív sám něco standardizovat, abych jako mohl k tématu něco říkat?

  • 12. 11. 2020 9:14

    Filip Jirsák

    Webové standardy vytváří a schvalují konkrétní lidé, ne nikdo abstraktní.

    Nepřijde Vám, že když někdo chce něco standardizovat, že by asi měl být v odvětví expert a kromě toho mít ještě určitý nadhled, což je přesně smysl standardu?
    Přijde. A ono to tak také je. Jenže to, zda je někdo ve svém odvětví expert, nemůže poznat někdo, kdo zná tisícinu toho, co ti experti.

    názor na fyzikální animace a CSS není z mé hlavy
    Jenže tady se nebavíme o fyzikálních animacích v CSS. Bavíme se o tom, že nazýváte „omezencem“ někoho jenom proto, že nevidí jenom váš uzounký omezený na svět, ale vidí toho mnohem víc. Omezenec jste v tom případě vy.

    Nezamyslel jste se někdy na tím, že se možná jen věci tak nějak patlaly (a patlají) a že by ten web obecně mohl být úplně jinde, když jsme už před více než deseti lety pochopili, že se ve webovém prohlížeči bude dělat prakticky všechno?
    Zamyslel jsem se nad tím dávno. Jenže jsem v tom přemýšlení pokračoval, na rozdíl od vás. A zjistil jsem, že ty standardy musí někdo implementovat a sepsat, a pak je musí implementovat ostatní prohlížeče. Také jsem zjistil, že se za posledních 10 let posunuli prohlížeče obrovským způsobem dopředu, před deseti lety jsme si vůbec nedokázali představit, co všechno bude dnes v prohlížeči možné.
    Problém není v tom, že by se prohlížeče nevyvíjely. Problém je v tom, že vy to posuzujete podle jediného požadavku ze stovek jiných požadavků, z nichž jsou desítky požadavků podstatně důležitější, než ten váš.

    Možná se mohl pro začátek upravit JavaScript tak, aby uměl používat celá čísla.
    JavaScript se dnes v prohlížečích velmi agresivně optimalizuje. To, co vy píšete do zdrojového kódu, se dost liší od toho, co pak provádí procesor. A pokud má někdo skutečně problém s výkonem v celých číslech a JavaScriptový JIT mu nestačí, použije WebAssembly.

    nikdo nepřišel s konstruktivním návrhem
    Co přesně vám bránilo s takovým návrhem přijít?

    Nakonec vůbec nechápu, proč se obouváte do mě a to ještě ad hominem.
    Protože vy jste se jako první začal navážet do lidí, kterým nesaháte ani po kotníky. Pořád ve mně je maličká naděje, že pochopíte, že tím omezencem jste v tomto případě vy.

    Máte snad nějakou konkurenční představu, co by se mělo upravit v CSS, kde byste měl pocit, že můj postesk by mohl Vaši představu zpozdit?
    Ne, mám představu o dalších stovkách věcí, které by bylo vhodné do prohlížečů implementovat. A taky mám představu, že nový standard se nevylíhne sám od sebe, ale musí to někdo konkrétní navrhnout, implementovat a standardizovat.

    Vy nechcete esteticky dobře vypadající aplikace ve webovém prohlížeči s menším úsilím pro vývojáře?
    Chci. Jenom já osobně bych chtěl v prohlížeči desítky věcí. A vím, že existují další stovky požadavků, které mají jiní lidé. Na rozdíl od vás si totiž uvědomuju, že můj jediný požadavek není středobodem světa.

    Znáte snad někoho osobně, kdo by cokoliv na webu standardizoval a koho jsem se podle Vás asi neoprávněně dotkl?
    Proč bych je musel znát osobně?

    Jakou kvalifikaci podle Vás musím mít, abych se mohl k něčemu vyjadřovat. Musím nejdřív sám něco standardizovat, abych jako mohl k tématu něco říkat?
    Bylo by fajn, kdybyste měl alespoň trochu rozhled ve světě webových technologií. Zejména, když chcete hodnotit jiné lidi. Zatím nechtěně hodnotíte jenom sám sebe.

  • 12. 11. 2020 12:45

    kaliszad

    Uznávám, že oproti Vám jsem měl třeba 10 let méně času na to sbírat zkušenosti a rozhled v IT. Je ale dost možné a i pravděpodobné, že jsem za těch 10 let co se v IT pohybuji nasbíral poměrně rychle různé zkušenosti a poznání a že naopak zkušenosti a poznaní z let předtím už nejsou tak užitečná, jak si možná myslíte, protože se mezitím prostě technologie změnily a jsou už lepší přístupy. Třeba Clojure vznikl někdy kolem roku 2007 a stabilizoval se někdy kolem roku 2011-2012. ClojureScript je ještě pozdější počin. Ano, je fajn umět skvěle programovat v Javě nebo JavaScriptu, ale v Clojure nebo ClojureScriptu napíšete za stejnou dobu v 95% případů robustnější program, protože vám ten jazyk nehází klacky pod nohy (resp. přinejmenším nehází tolik jako Java nebo JavaScript). To taky není z mé hlavy. Btw. na těch 95% procent problémů potom všechny ty těžko získané zkušenosti z Javy nebo JavaScriptu mají mizivou hodnotu. Ano, na některé věci do terénu, hobby nebo romantiku je možná lepší kůň, ale na 95% transportu je lepší auto.

    Nevím, podle čeho soudíte, že mám nedostatečný rozhled ve webových technologiích konkrétně. Musím nejdřív vyjmenovat všechny jiné často mnohem složitější a na řešení nejspíš mnohem náročnější problémy, než se dostanu k tomu, který mi (kromě jiných lidí) přijde docela zásadní a přitom by jeho standardizace a implementace neměla být tak náročná?

    Btw. to, že se JavaScript někde optimalizuje je úplně k ničemu, když JIT nemůže poznat význam toho, co chcete sdělit a tedy to nemůže jednoznačně (a tedy bezchybně) přeložit do efektivnější podoby. Možná jsem se špatně vyjádřil, ale vývojář nemá možnost efektivně vyjádřit čísla někde mezi 2^53 až 2^63 aniž by využil BigInt, webassembly nebo různé triky, které ale podstatně zhorší výkon, právě protože se prohlížeč může jen dohadovat, co v jaké proměnné (resp. datové struktuře) může být. Ono tam není totiž nic jako dependent type nebo schéma, které by říkalo, že zapisuji vše jako BigInt, ale ve skutečnosti budu používat jen hodnoty do 2^63 a že to tedy může prohlížeč chápat jako jednoduchý 64bitový integer a namapovat to 1:1 na strojový kód pro konkrétní procesor. Podle mých vědomostí to hlavně nemůže JIT kompilátor "uhádnout", když mu tam za běhu můžou potenciálně přijít jakékoliv vstupy a programátor nikde neslíbil, že výsledek jakékoliv operace bude taky v rozsahu běžného 64bitového integeru a není tedy potřeba rozšiřování na BigInt.
    Webassembly je nejspíš fajn, ale je to úplně něco jiného než JavaScript a třeba ClojureScript zatím do WASM nekompiluje. Vím, to není chyba standardizačního výboru a už vůbec ne záležitost CSS.

    Nevím, podle čeho subjektivně (a tedy podle Vás asi taky omezeně) usuzujete, že jsou důležitější věci než standardizace fyzikálních animací v CSS. Které to jsou? Víte, že se může pracovat na více věcech zároveň, protože nejspíš lidé co pracují na CSS jsou jiní než ti co pracují na JavaScriptu nebo WebAssembly?

    Asi bych na tomto místě ze své strany diskuzi opustil. Pokud budete mít chuť, můžeme se k tématu vrátit někdy třeba osobně na konferenci nebo tak, až tomu bude situace nakloněná. Můžete mi potom třeba předat nějaké zkušenosti s webovými technologiemi, které postrádám a poslechnout si mé možná naivní, možná ale přesto zajímavé postřehy.

  • 12. 11. 2020 14:45

    Filip Jirsák

    Nebavíme se o mých zkušenostech, ale o zkušenostech spousty vývojářů, kteří se podílejí na tvorbě webových standardů.

    Nevím, podle čeho soudíte, že mám nedostatečný rozhled ve webových technologiích konkrétně.
    Z vašich předchozích komentářů v této diskusi.

    Btw. to, že se JavaScript někde optimalizuje je úplně k ničemu, když JIT nemůže poznat význam toho, co chcete sdělit a tedy to nemůže jednoznačně (a tedy bezchybně) přeložit do efektivnější podoby.
    To, že JIT podle vás něco dělat nemůže, ještě neznamená, že to ve skutečnosti nedělá. Exiszuje něco, čemu se říká spekulativní optimalizace, a JavaScriptové JIT to využívají. Kód je optimalizovaný jen pro jednu variantu (třeba datový typ) a na začátku se jen rychle ověří, zda datový typ opravdu sedí. Následně se provede rychlý kód optimalizovaný pro ten jeden typ. Pokud typ nesedí, optimalizace se zahodí a JIT se vrací k původnímu interpretovanému kódu.

    Podle mých vědomostí to hlavně nemůže JIT kompilátor "uhádnout", když mu tam za běhu můžou potenciálně přijít jakékoliv vstupy a programátor nikde neslíbil, že výsledek jakékoliv operace bude taky v rozsahu běžného 64bitového integeru a není tedy potřeba rozšiřování na BigInt.
    Vizte předchozí odstavec. Když nemáte moc velký přehled ve světě webových technologií, nevyplatí se spoléhat na vaše vědomosti.

    Webassembly je nejspíš fajn, ale je to úplně něco jiného než JavaScript a třeba ClojureScript zatím do WASM nekompiluje.
    Zase ten váš uzounký pohled na svět. Jeden jazyk se do WASM nekompiluje, tak jakoby WASM neexistovalo. Pokud v prohlížeči potřebujete vymáčknout maximum z práce s celými čísly a zvolil jste si jazyk, který nepodporuje WASM, zvolil jste si asi špatný jazyk.

    Nevím, podle čeho subjektivně (a tedy podle Vás asi taky omezeně) usuzujete, že jsou důležitější věci než standardizace fyzikálních animací v CSS. Které to jsou?
    Třeba věci, které musí řešit přímo prohlížeč, protože Web API k nim aktuálně nemá přístup. Je to spousta věcí týkajících se bezpečnosti – přihlašování a práce s hesly (FIDO2 je hezký pokus, ale nevěřím tomu, že hesla úplně nahradí) elektronický podpis a šifrování (pokud chceme brát e-2-e bezpečnost vážně, musí to podporovat prohlížeče, protože ty dnes tvoří rozhraní k většině služeb); ochrana proti různým cross-* útokům (v poslední době se v tom udělalo hodně, ale ještě je co zlepšovat); práce se souborovým systémem se posunula v posledních měsících, ale nevím, zda už je tam vše; úplně chybí HTML importy, které by výrazně redukovaly objem přenášených dat, a zatím to vypadá, že byly úplně odpískané. Vás asi víc zajímá CSS – tak tam třeba chybí úplně základní typografické věci jako práce s řádkovou osnovou nebo protékání textu různými bloky; pořád není správně vyřešený zoom; nejde používat variabilní rozměry obrázků (v HTML už to jde); příšerně se v CSS zachází s SVG (vykreslí se do paměti jako bitmapa a dál se s tím pracuje, jako kdyby to byl statický bitmapový obrázek). A spoustu dalších a dalších.

    Víte, že se může pracovat na více věcech zároveň, protože nejspíš lidé co pracují na CSS jsou jiní než ti co pracují na JavaScriptu nebo WebAssembly?
    Nemusíte soudit znalosti ostatních jen podle svých vlastních znalostí. Aby mohl vzniknout nový standard, musí být lidi, kteří mají zájem takový standard prosadit, musí se tomu věnovat, a pak se také všichni zúčastnění musí dohodnout, jak to udělat (naštěstí už se ve světě webových standardů nedělá to, že by existovaly dva různé standardy pro to samé). Na fyzikálních animacích by se měl mít největší zájem Apple, ale ten má teď se Safari asi úplně jiné starosti než to, jak posouvat dopředu webové standardy.

    Můžete mi potom třeba předat nějaké zkušenosti s webovými technologiemi, které postrádám a poslechnout si mé možná naivní, možná ale přesto zajímavé postřehy.
    Na naivních postřezích není nic špatného; ale nemyslím si, že by vaše postřehy byly naivní. Vadí mi, že někoho označíte za omezence jen na základě svého velmi omezeného pohledu na svět. A ještě v situaci, když ti „omezenci“ vám nejsou ničím zavázáni – pokud považujete fyzikální animace v CSS za tak důležité, chopte se iniciativy, aby ten standard vznikl. Nic vám v tom nebrání. Ale je dost hloupé sedět si pohodlně v křesle, nehnout prstem a nadávat lidem, kteří udělali spoustu práce, ze které těžíte, že toho udělali málo.

  • 12. 11. 2020 15:01

    kaliszad

    Asi nejzajímavější komentář od Vás v této diskuzi. Díky za něj. Jak jsem psal, někdy jindy se o tomto nebo jiných tématech můžeme pobavit ústně, pokud budete mít chuť.

  • 12. 11. 2020 0:53

    kaliszad

    Vážím si Vašeho přání i chvály. Snažíme se to posouvat jak jen to jde a jsme si vědomi zodpovědnosti, kterou máme vůči našim uživatelům. Kdyby byly jakékoliv dotazy, postřehy, zkušenosti atd. tak určitě napište na support@orgpad.com nebo použijte feedback formulář v menu nebo ikonku v pravém dolním rohu.

    Zrovna Apple je taková záludná platforma. Safari je celkem oříšek z pohledu adopce webových standardů a upřímně jej máme tak trochu na druhé až třetí koleji, nějak musíme holt priorizovat práci. Na druhou stranu aspoň na macOS lze nainstalovat Chrome, Chromium nebo Firefox a určitě i další a ty chodí mnohem lépe. Na iOS je to bohužel zapeklitá situace. Aspoň fotky by ale z iPhone/ iPadu mělo být možné do existující OrgPage nahrát a prohlížet OrgPage by taky mělo chodit bez větších obtíží.
    Výhoda Apple je, že obyčejně je jejich hardware spíše výkonnější, takže tam má platforma Apple určité výhody.

    Jinak jak jsem jinde v tomto threadu nastínil, máme jasnou představu, jak OrgPad dost výrazně zrychlit a zefektivnit. Nejdříve ale přepíšeme editor v rámci buňky. TinyMCE prostě není dostatečně dobrý. Náš nový editor bude psaný kompletně v ClojureScriptu, bude mnohem lépe integrován s Reactem a tedy stavem applikace a hlavně nám umožní současnou editaci ve více uživatelích i v rámci buňky trochu na způsob Google Docs, ale snad lépe a přehledněji. To nám taky umožní rozjet editaci na mobilních platformách a do budoucna další funkcionalitu, kterou nikde jinde nenajdete.

  • 12. 11. 2020 8:50

    PQK

    Orgpad.com je pěkný, ale mám připomínku k použitelnosti.

    Není vidět rozdíl mezi "obdélníčkem" který má další obsah a který ho nemá ...
    tzn. dvakrát kliknu na "obdélníček" a on se nerozbalí ... tak poklikám znovu jestli jsem se náhodou netrefil a teprve teď vím, že se "obdélníček" nerozbalí ...

    Zkuste dát do "obdélníčků s obsahem" jako poslední znak např "zobáček dolu"
    - signalizuje další obsah
    - může být aktivní
    -- ukážu na něj, obsah se ukáže bez překreslování grafu
    -- kliknu na něj, obsah se rozbalí a graf překreslí ...

  • 12. 11. 2020 11:40

    kaliszad

    Děkuji za zpětnou vazbu a návrh. Moc to ale nesouvisí s obsahem článku, pojďme se spíš bavit o detailech v OrgPadu, které se netýkají Apple nebo dohadů o výkonu na Apple M1 jinde. (Email, Reddit, Facebook, Twitter)

    Vaši připomínku skoro 1:1 nám už někdo navrhoval a máme ji poznamenanou. Jenom v rychlosti:
    - jednotky s obsahem rozlišitelné jsou, mají stín na rozdíl od těch, které obsah nemají. Je to trochu subtilní to ano. Jde o to, aby to nerušilo ve větších Orgpagích.
    - zobáček nejspíš nezapadá do našeho designu, ale rozhodně přemýšlíme, jak dělat věci lépe a něco už vymyslíme, aby to bylo jasnější :-)
    - s tím překreslováním/ nepřekreslováním je to dobrý nápad, ale musí se to hodně poladit, aby to nemělo nežádoucí vedlejší efekty.

  • 11. 11. 2020 0:29

    Calculon

    “Po přechodu od Motoroly k PowerPC a následně k x86 jde o třetí významnou architektonickou revoluci u Applu”

    K tomu snad jen, že na ARM Apple portoval svůj OS už pro první iPhone (a iPod touch), od jádra (Mach) přes většinu ovladačů a své BSD až po Foundation Kit (původem ještě z NextStepu). Jen UI si napsali znova jiné (UIKit) — výsledkem byl iOS (tehdy zvaný “iPhone OS”).

  • 11. 11. 2020 9:17

    mhi

    "Po přechodu od Motoroly k PowerPC a následně k x86 jde o třetí významnou architektonickou revoluci u Applu"

    Nezapomina se nahodou na MOS 6502? Jde sice o davnou historii, ale tento prechod byl myslim jeste vyznamnejsi nez nejake PPC->Intel->Apple-ARM, tady celou dobu bezi podobna architektura (Mach, XNU, na to navazane ObjC "Kity").

    Vite nekdo jaka verze XCode a macOS 11 Big Sur podporuje ten M1 ?

  • 11. 11. 2020 9:21

    David Ježek

    Nezapomíná, jen to z hlediska přenositelnosti celého "sw ekosystému" firmy myslím nebylo tak náročné a tak důležité jako dnes (myšleno z hlediska neschopnosti většinového zákazníka Apple cokoli technického sám řešit).

  • 12. 11. 2020 8:59

    PQK

    Nevíte jestli bude Apple řešit zpětnou binární kompatibilitu (alespoň na přechodnou dobu).

    To byl při přechodu vždy "majstrštyk" ... do nové architektury přepsali jen jádro a emulátor a zbytek postupně přidávali jako updaty ... zákazníci nepřišli o původní aplikace (pokud vývojář nestíhal překlad na novou platformu). V době přechodu na PPC to vypadalo jako zázrak.

  • 12. 11. 2020 10:43

    mhi

    Je tam "Rosetta 2", neni to emulator, ale binarni translator, maji tam "fat binaries", t.j. binarka ve ktere je Mach-O pro x86_64 i arm64. Nemam tuseni jak tam je udelane napojeni x86_64 kodu na arm64, do jake miry se pouzivaji ty nenativni knihovny, logika veci veli, ze by se mel co nejvice pouzivat ten arm64 kod.

    S binarnimi translatory se daji delat velmi zajimave veci vc. ruznych optimalizaci, kdy prelozeny kod nemusi byt vubec pomaly. Kdyz tupe prelozite x86(32) na arm(32bit) tak je narust kodu cca 3-4x, z toho muzete obratem vyhazet ale 1/3 az 1/2 kodu uplne jednoduchym optimalizatorem. Co jsem zatim ale videl, tak se JIT optimalizaci zase tak moc nevyuziva, od cloveka ktery ma na svedomi treba JIT do Javy mi bylo receno, ze se to ukazalo nerentabilni ... a ve vyvoji se nepokracovalo, i kdyz byla spousta cest ke zkoumani.

  • 11. 11. 2020 11:51

    BobTheBuilder

    Fakt neznáte pojem "fabless"? Výrobce čipů, který nemá vlastní fab, tedy linku, a musí si je nechat dělat jinde - např. AMD, na rozdíl od Intelu.
    Celý odstavec je o nezávislosti: Apple tedy tímto stále není nezávislý - sice má vlastní čipy, ale sám nemá technologie na výrobu. To má TMSC, který ale taky není nezávislý, protože si nedokáže udělat zdroj EUV světla. Geopolitické vlivy (hrozba Číny, která si dělá zuby na Taiwan) tady možná úplně neplatí, protože ten zatím jediný 5nm fab TMSC je v Texasu.
    No ale skoro to všechno v tom odstavci je a o zbytku se předpokládá, že čtenář ví, pokud něco o výrobě čipů tuší. Vzhledem k tomu, že to je pouze poznámka k Jobsově touze po soběstačnosti Applu, to není třeba víc vysvětlovat. Když nevíte, UTFG.

  • 11. 11. 2020 10:28

    K>

    "Paradoxně na tom je platforma IBM POWER dnes možná lépe než Intel x86, ale to je jedno."

    Když je to jedno, proč to je ve zprávičce? To je styl jak od dětí ze školy.

    Nemůžu si pomoct, ale ze všech článků p. Ježka je v poslední době příliš silně cítit, jak nemá rád Intel. Není článku, kde by autor neopomněl zmínit jak je na tom Intel špatně.

  • 11. 11. 2020 10:53

    mhi

    Kdyby IBM POWER na tom bylo lepe nez Intel, tak se myslim vcelku snadno prosadi, treba tak jak se prosazuje ARM, u Linuxu ci jinych Unixu to neni problem a je to celkem velky trh.

    Evidentne si Apple mysli, ze ARM (resp. vse co je v M1) je na tom nejlepe. A ono to dava smysl, kdyz maji kontrolu nad OS, tak si mohou dovolit delat spoustu "nestandardnosti", ktere jen zpristupni v nejakem frameworku.

  • 11. 11. 2020 12:16

    David Ježek

    Achjo...
    1) je to jedno v kontextu zprávičky, tedy toho, že Apple si vybral ARM a je tedy bezpředmětné rozjímat nad x86 × POWER
    2) nemám rád Intel? Tak proč to v těchto týdnech schytávám na diit za to, že hájím neobhajitelné procesory Intelu vůči AMD?
    3) Autor to neopomněl zmínit proto, že je to KLÍČOVÝ DŮVOD proč Apple přechází na vlastní CPU (čert vem, jestli je to ARM, RISC, POWER, ...)

  • 11. 11. 2020 13:00

    Miroslav Šilhavý

    Negativní reakce se najdou na každý článek.
    Intel nemá neobhajitelné procesory, prodeje o tom svědčí.
    AMD má našlápnuto, ale to měli v historii už několikrát - a vždy to prokoučovali.

    Podle mě má být článek co nejvíc neutrální, osobní postoj by měl být oddělený (všiml jsem si, že už to často píšete až na konec). Ve zprávě by měla být fakta, a to co nejpřesnější. Např. to, že velká část odborné veřejnosti považuje AMD procesory za technicky lepší, ale s menším obchodním úspěchem. Nebo se lze takové informaci zcela vyhnout, protože s tématem nesouvisí tak úzce, aby v článku musela být. Možností je víc.

  • 11. 11. 2020 13:22

    berk

    Nejsem příznivcem autocenzury. Článek má být tak jak to autor cítí. Ostatně, případně si to pak slízne v diskuzi :-)

  • 11. 11. 2020 13:43

    Miroslav Šilhavý

    To není autocenzura, ale čistota stylu zprávy. Názory a postoje autora patří do publicistiky a komentářů, ale ty zase vypadají úplně jinak. U nich nehraje roli sdělit něco nového, ale k něčemu už známému se vyjádřit.

    Novinařina není lehká, jak se někdy zdá. Autor si musí dávat pozor nejen na to, aby nedal informace jen jednostranné, ale taky na to, aby něco důležitého nevynechal. Oba "nešvary" ovlivňují vyznění článku. Od toho existují redakce, kdy článek čte víc lidí a navzájem tyto nuance korigují.

  • 11. 11. 2020 15:12

    Peter Fodrek

    Nikdy neboli tak vpredu, čo sa týka stratégie

    Architekt Zenu zmínil vývoj Zen 5
    11. 4. 2018 | no-X | Hardware, Novinky, Procesory
    Mike T. Clark, šéfarchitekt Zenu, v rozhovoru uvedl, že již pracuje na Zen 5. Jde vůbec o první zmínku o architektuře páté generace, která od AMD přišla…
    https://diit.cz/clanek/architekt-zenu-zminil-vyvoj-zen-5

    Návrh Zen 3 byl dokončen, pracuje se na Zen 4
    13. 8. 2019
    https://diit.cz/clanek/navrh-zen-3-byl-dokoncen-pracuje-se-na-zen-4

    Lisa Su odhalila Zen 3: o 19 % vyšší IPC, o 26 % lepší herní výkon
    9. 10. 2020
    https://diit.cz/clanek/lisa-su-odhalila-zen-3-o-19-vyssi-ipc-o-26-lepsi-herni-vykon

    A rozhodne nešlapali, ako tento rok-klvartál

    8. říjen 2020 - představení Zen 3 / Ryzen 5000
    28. říjen 2020 - představení RDNA 2 / Radeon RX 6000
    5. listopad 2020 - vydání Zen 3 / Ryzen 5000, BIOSy pro 500, vč. dostupnosti
    16. listopad 2020 - představení CDNA / Instinct MI100
    18. listopad 2020 - vydání Radeon RX 6800 a RX 6800 XT včetně dostupnosti
    12. prosinec 2020 - vydání Radeon RX 6900 včetně dostupnosti
    leden 2021 / CES 2021 - mobilní APU Cezanne / Ryzen 5000 (Zen 3 + Vega+)
    leden 2021 - BIOSy pro Zen 3 / Ryzen 5000 pro čipsety 400
    Q2 2021 - APU Cezanne pro desktop
    https://diit.cz/clanek/architektura-cdna-radeon-instinct-mi100-se-chystaji-na-polovinu-listopadu

  • 11. 11. 2020 13:14

    K>

    Ach jo....
    1, Což nic nemění na tom, že to je stylisticky hrozné.
    2, To já nevím. Na to si budete muset přijít sám. Možná to bude tím nevhodným stylem psani...
    3, Já myslel že klíčový důvod (KLÍČOVÝ) je ta snaha o samostatnost, jak se píše ve zprávičce. Kdyby KLÍČOVÝ byla snaha zbavit se Intelu, tak je tu ještě AMD, a nemusel by Apple předělat celý kód. Ale určitě máte lepší vhled do Applu než já, tak by bylo nejlépe to rozebrat v samostatném článku, a ne ve zprávičce.

    Zprávička: fakta, informace.
    Článek: rozbor problému.
    Blog, fejeton: názory, dohady.

  • 11. 11. 2020 14:21

    mhi

    Nechci, aby to vyznelo nejak kriticky, za Vasi novinku jsem rad, alespon jsem se podival jak ta M1ka vypada. Myslim, ze uz jen to ze jsem si novinku precetl je muj hlas pro to, ze neni tak spatna a dekuji za ni.

    Sam pisu clanky, do jineho oboru nez je IT, a clanek ve spojeni s komentari, hlavne p. Silhaveho, mne donutil zamyslet se nad tim, ze bych mel sam casteji pouzivat slova typu "Domnivam se" apod., protoze nekteri lide mohou muj nepodlozeny nazor vzit za fakt, uz jen proto ze mne berou jako autoritu :-). Jsem hodnotici clovek, mam spoustu nazoru, nejen ve forme kritiky, kazdopadne uz jsem se hodnekrat sekl.

    Nekdy si budu muset navrhnout vlastni procesor v FPGA abych si mohl udelat nazor na to co ma jake (ne)vyhody, treba proc je to PowerPC tak drahe ve srovnani s vykonem (tusim to, ale dokud neni nejaky byt mikrokodovy verilog na svete, je to spis jen dojem).

  • 11. 11. 2020 17:11

    bez přezdívky

    me tento styl psani s jemnymi narazkami a glosami velmi bavi. Co me nebavi, je cist v komentarich takovehle frfnani . Takze si priste nechme odlisny vkus pro sebe, a zkusme reagovat pouze k tematu, pokud opravdu budeme presvedceni, ze bude pro ostatni reakce prinosna ;)
    dekuji.

    11. 11. 2020, 17:13 editováno autorem komentáře

  • 11. 11. 2020 22:58

    Calculon

    Ano, tento styl je příjemné odlehčení, není si proč stěžovat. Pokud se někomu nelíbí, ať to nečte a debilní kecy si nechá pro sebe.

  • 12. 11. 2020 8:09

    K>

    Když se ti moje komentáře nelíbí, tak je nečti.

    (Hm, takže asi to tvoje řešení nebude to pravé ořechové. Nejprve je potřeba něco přečíst, abys mohl posoudit jestli se ti to nelíbí.)

  • 12. 11. 2020 8:17

    K>

    Novinařina (a každá jiná forma předávání informací) není jen o faktech či názorech, ale taky o způsobu podání, formě. A forma může velmi významně ovlivnit, jakým způsobem jsou fakta vnímána čtenářem.

    A přínos? Styl p. Ježka se od příchodu sem změníl. Začal více označovat své názory a zřetelněji je oddělovat. K tomu bezpochyby přispělo ono "frfňání" v diskuzích, a nejen moje.

    Tedy záporná kritika stylu a formy je k tématu, a je přínosná.

  • 12. 11. 2020 10:39

    Miroslav Šilhavý

    me tento styl psani s jemnymi narazkami a glosami velmi bavi

    Narážky a glosy by měly být oddělené od hlavního sdělení, a DJ to docela dobře respektuje. Bavíme se zde o drobné nuanci, která možná maličko tu profesionalitu narušila, ale nedělal bych z toho velkou vědu.

    Naopak, pokud se až příliš míchá do sebe, je z toho pak bulvár. A proč ne, root.cz může být klidně bulvární plátek ze světa IT - ale tomu zase neodpovídají další články.

    12. 11. 2020, 10:40 editováno autorem komentáře

  • 11. 11. 2020 15:18

    Martin P.

    -uvedený M1 CPU je lowend , proto startuje v Air , Mini a MBP13
    -celou prezentací jela mantra o efektivitě na Watty nikoliv výkonu za jednotku času

  • 11. 11. 2020 17:55

    kaliszad

    Myslím, že máte velmi špatné informace. Ty CPU jsou s velkou pravděpodobností efektivnější A výkonnější než co bylo dostupné dosud. V dnešních zařízeních je důležitá nejprve efektivita a potom absolutní výkon, který jistě musí být na určité úrovni. V datacentru výrobce a provozovatele zajímá kolik dostanou výkonu za dolar a kolik utratí za elektřinu a chlazení. V mobilních zařízeních je důležitý absolutní tepelný výkon a tedy maximální výpočetní výkon, který zvýšíte právě tím, že zvýšíte efektivitu. V laptopu buď můžete mít 10 W přímotop, nebo procesor. Pálit Vás bude obojí stejně, ale ten procesor Vám ještě i něco upočítá. Intel ve srovnáních Apple vypadá oproti M1 spíše jako ten přímotop. Anandtech zdá se vidí celou situaci tak, že Apple má spíše pravdu, viz můj komentář výše.

    Nezdá se mi, že by Apple montoval do MBP 13 lowend a hlavně by se potom nekasal s tím, kolikrát jsou které úkony rychlejší oproti předchozí generaci. Zde podtrhuji, že nepíšou něco o procentech, ale používají rovnou faktor.
    Nejsem nějaký fanoušek Apple, ale jsem rád, když Apple nabízí skok kupředu, protože ho dosud v tomto všichni se zpožděním kopírovali a to spíše prospívá i jiným platformám i když to lokálně může trochu bolet. (3,5 mm Jack)

  • 11. 11. 2020 20:14

    Martin P.

    M1 má podporu pouze 16GB RAM
    M1 nemá podporu dedikovaných grafik
    M1 má omezenou podporu počtu USB/TB portů
    M1 je z pohledu výkonného SMP jen čtyř jádro

    Máme rok 2020.....

    M1 je tak pri 10W zajisté výkonejši než i3/5/9 a okolik je výkonejši když i9 běží na 130W..... M1 je zajisté výkonejši při čtyřech vláknech a jak při 8 nebo x2 při HT ?

    Pochybuji že v hrubém výkonu to bude takový zázrak.

  • 11. 11. 2020 21:41

    kaliszad

    Ano, podpora "jen" 16 GB RAM může někoho omezovat. V MBP je to určitě limitující pro nezanedbatelné procento uživatelů. Zrovna u USB a TB si nemyslím, že je limitace zásadní. Reálně jsou dva TB porty opravdu dostatečné hlavně když uvážíme, že Apple zamýšlí připojení na displej, kde třeba bude i USB hub. Ano, mohl tam možná být aspoň jeden USB A port na druhou stranu, kdo ještě v době internetu všude používá USB flash? I tiskárny jsou dnes obyčejně nějakým způsobem síťové. A kdo má tak speciální požadavky, může mít adaptér/ rozbočovač/ dokovací stanici.

    Většina lidí nepotřebuje žravý procesor, pokud např. přehrávání videa ve 4K nebo nějaké efekty budou akcelerované GPU, DSP nebo TPU. Ti co ano, ti si pořídí jiný počítač, třeba MBP 16" nebo stolní počítač a nebo práci nasypou do nějaké cloudové služby, která to upočítá na serveru.

    Právě že máme rok 2020 a není nutné s sebou tahat několikakilový laptop a napájecí cihlu pro 98% činností. Výkon bude nejspíše se 4 jádry a 16 GB RAM u M1 dostatečný. Třeba stříhání videa může být díky GPU a TPU v M1 klidně i rychlejší, než na tom 130 W CPU, protože možná bude HW a SW na to dostatečně sladěný aby se používal tento efektivnější přístup. Nevím, nechme se překvapit.

    Jinak nemusíte se rozčilovat. Pořiďte si takový stroj, jaký Vám vyhovuje.

  • 11. 11. 2020 22:07

    David Ježek

    Argumentovat u 10W procesoru tím, "o kolik je výkonnější" než 130W CPU konkurence, je mimózní. 130W Core i9 (reálně spíše 250W) a 10W M1 jsou čipy pro zcela jiné segmenty.

    Zázrak to samozřejmě není, je to jednoduchý čip pro (ultra)mobilní zařízení, který je vyráběn první, nevyladěnou variantou 5nm procesu. Co jako čekáte? Výkony jako od reálně 250W Core i9-10900, které Intel umí hnát nad 5GHz, protože jeho reální spotřeba je 25× vyšší než u M1 a které za tímto účelem vyrobil k tomu vyladěnou variantou 14nm procesu?

    Buďte aspoň trochu fér, člověče.

  • 11. 11. 2020 22:47

    kaliszad

    Já jsem úplně fér. Uživatele zajímá, jestli sestříhá video nebo vyvolá/ upraví fotky a jak dlouho to bude trvat a jestli k tomu potřebuje počítač stolní nebo to jde dělat i na laptopu, který je lehoučký. Ten Core i9 může být výkonný jak chce, ale program využívající akcelerátory v M1 bude nejspíš na určité operace, jako třeba právě to stříhání videa prostě rychlejší a mnohem, mnohem efektivnější. Nemusí to tak být samozřejmě.

    Pokud chcete těžit kryptoměnu, tak taky nebudete používat procesor, ale specializovaný ASIC. To samé se šifrováním až na určité výjimky (Wireguard, kde aspoň využívají vektorové jednotky). Jenom bohužel u stříhání videa a dalších činností máme pořád nějak potřebu to počítat na něčem vhodném především pro obecné výpočty. Nemám pocit, že by ca. 1 Tflops u Vašeho CPU Intel Core i9-10900 konkurovalo 2,6 Tflops u GPU v Apple M1 na specializované úlohy. Uživateli je srdečně jedno, na čem se která úloha v rámci jeho počítače počítá dokud to bude rychlé a efektivní.
    Když si odmyslíte práci s grafikou (obrázky, práci se zvukem, video a to i videokonference, kreslení a animace) na kterou se nejspíš hodí více grafická jednotka nebo nějaké DSP, tak na co normální uživatel využije mnohajádrový procesor? Načte se mu s ním rychleji Facebook?

    Jediné, kde ten mnohojádrový procesor výrazněji pomůže (a kde to dává smysl) bude kompilace kódu nebo zpracování větších dat, což může být fajn třeba pro programátory nebo uživatele náročných aplikací napsaných v nějakém JIT kompilovaném (třeba JavaScript, Clojure, Java, C#) nebo interpretovaném jazyce (kde už v případě Pythonu a dalších zase narážíme na single thread výkon). Nebo když analyzujete spoustu dat ať už v Excelu nebo pomocí CLI skriptů. I tam ale nebude 4 jádrový procesor Apple M1 zrovna ořezávátko pokud nelžou informované predikce Anandtechu. Lidé strašně podceňují, co udělá slušná frekvence a výborné IPC. Vždyť to výkonné jádro v M1 je skoro dvakrát tak široké, než jádro v procesorech Intel! Myslím, že taky hodně podceňujete, co udělá s efektivitou práce fakt, že bude hodně dobrý výkon dostupný v lehčím formátu, který vydrží déle na baterku. Znám lidi, kterým se nejlépe pracuje na gauči, v posteli nebo dokonce na toaletě. Mají tam nejlepší nápady, kde je mnohem důležitější latence mezi nápadem a zformulováním nápadu kresbou, kódem, hledáním na webu než dlouhým počítáním něčeho. Tam jednoznačně dává smysl pouze srovnání s jinými mobilními zařízeními a tam může M1 být lepší volbou, hlavně pokud je uživatel zvyklý na macOS.

    Myslím, že je celkem jedno, jak moc je ten 5 nm proces vyladěný. Nejspíš dostatečně, aby se na tom udělal tape out extrémně komplexního čipu v nezanedbatelné kvantitě pro jednoho z největších zákazníků. Reálně ten 14 nm proces může být charakteristikou vyladěný bezvadně - oproti jiným 12-16 nm procesům s FinFET. V praxi ale srovnáváme nesrovnatelné. Vidíte, jak to AMD a jiní Intelu nandávají už s 7 nm procesem. Předpokládám, že o generaci a půl novější 5 nm proces a hlavně úplně nová architektura přeci jen bude ještě jiná liga.

  • 11. 11. 2020 20:24

    Jiří Eischmann

    Na druhou stranu, jakým procentem se dnes chipset při běžném využití podílí na celkové spotřebě notebooku? Ta spotřeba šla tak dolů, že zdaleka největším žroutem je dnes displej. Na těch inzerovaných 17 hodin brouzdání se dnes člověk dostane i s řadou jiných tenkých ultrabooků postavených na Intelu, jako je třeba XPS 13. Nicméně zajímavé na tom je, že to dokáží uchladit pasivně, to AFAIK ultrabooky s Intelem nezvládnou.

  • 11. 11. 2020 21:56

    kaliszad

    V reálu mám spíš zkušenost, že se dostanu na podstatně kratší dobu na baterii, když laptop skutečně používám a to i při "brouzdání". Ono totiž nemám otevřený jen jeden tab a nečtu jen text. Mám pocit, že CPU přeci jen něco žere a i když třeba není podíl CPU na spotřebě při lehčí práci už tak markantní, nejspíš se spotřeba CPU a jiných čipů snižuje lehčeji než u LCD. Celkem slušné zlepšení by mohl přinést OLED nebo microLED displej, ale to bude celkem jistě příplatková záležitost.

    Btw. ten větrák může taky být celkem slušný žrout energie. Zcela pasivní design je mi velmi sympatický, protože mi různé pazvuky z elektronických zařízení neuvěřitelně vadí a nejsem schopen pochopit, jak některé produkty může výrobce vůbec pustit k zákazníkovi.
    (Zde myslím třeba ThinkPad T470 kde větrák kvílí místo šustí. Nevím, proč takovou pitomost za tolik peněz vůbec musím řešit. Další takový adept je mikrovlnka Severin, která piští v sekundovém taktu nějakou cívkou nejspíš. To se fakt vyplatilo ušetřit pár centů za zalití těch pár cívek. Různé adaptéry od reproduktorů po telefony to samé. Za tohle by se měl zodpovědným inženýrům a kvalitářům, co to pustili ten zvuk pouštět neustále na 10x větší výkon dokud to neopraví. A přitom detekce, že to piští nebo nějak skřípe je triviální. Stačí to ukázat nějakému mladšímu hudebníkovi nebo použít i mikrofon lepšího mobilu se spektrografem.)

    11. 11. 2020, 21:59 editováno autorem komentáře

  • 11. 11. 2020 22:10

    David Ježek

    " Zcela pasivní design je mi velmi sympatický, protože mi různé pazvuky z elektronických zařízení neuvěřitelně vadí a nejsem schopen pochopit, jak některé produkty může výrobce vůbec pustit k zákazníkovi."

    Hele na to bacha. Mám kamaráda, který kdysi dávno řešil své hlučné PC. Nejdřív vyměnil chladič na CPU ze 40mm 5500rpm na 80mm 2500rpm. Pak slyšel HDD. I vyřešil jeho zavěšené ve skříni tak, aby nepřenášel hluk do těla skříně. Pak slyšel zdroj, i vyměnil zdroj s 80mm ventilátorem za lepší značku a se 120mm ventilátorem. A pak ... slyšel šumění vody v ústředním topení paneláku. A to ztišit už fakt bylo nad jeho síly :-)

  • 11. 11. 2020 23:36

    kaliszad

    Ano samozřejmě. Dobrá historka. Akorát u proudícího média je asi šum jaksi oprávněný a v mnoha případech nejspíše nerušivý nebo přinejmenším pochopitelný. Řešit to samozřejmě lze, třeba zapuštěním do podlahy, která hodně toho šumu utlumí a ještě bude teplo na nohy, ale tu investici si opravdu musíte rozmyslet.
    Já třeba přesunul svůj už tak nehlučný server za roh do chodby, takže jej pohodlně přehluší i (tichá) lednice, co občas sepne. Frézoval jsem kvůli tomu elektřinu, zěmění a datovou kabeláž :-) Teď je to ale pohoda i s otevřenými dveřmi do chodby, kdy je to slyšet jen při absolutním tichu a se zavřeným oknem. Jinak je ruch z ulice hlasitější.

    Obecně, lidé podceňují vliv neustálého a především zbytečného hluku nebo ruchů na zdraví. Rád si poslechnu pořádný koncert a ve filmech rád rozumím i dialogům, ale neustálý hluk bez důvodu (třeba protože se nějaký bezohledný člověk má potřebu projíždět na motorce pozdě v noci nebo někdo není schopen uznat, že by v noci obytnou čtvrtí nemusel jezdit jako šílenec) mi prostě pije krev. Kdyby se kdokoliv zamyslel, jestli jsou různé nepřirozené zvuky nezbytně nutné, tak by došel k tomu, že většina těch zvuků nemusela být jenom kdyby to nebylo především inženýrům, ale i uživatelům jedno. Začíná to hned ráno popeláři, dodávkami a auty ideálně ještě na děravé silnici nebo rovnou kostkách. Všechno úplně zbytečně hlučné. Potom máte věci jako tramvaje, které jsou často v přilehlých domech dokonce i cítit. V ten moment víte, že to tlumení kolejí neexistuje. Motorky se spalovacím motorem jsou kapitola sama pro sebe, vůbec nevím, jak to někdo může vůbec připustit k provozu (a to i ve dne). Autobusy a náklaďáky co vypouští přetlak stlačeného vzduchu, očividně bez jakéhokoliv ohledu na nějaké tlumení. Zvony kostelů se asi dají pochopit i když většinu lidí jaksi zvoněním v 7 ráno asi úplně nenadchnou. Pracovní stroje, které prostě musí mít extra hlasitý diesel i když nic zrovna nedělají. Venkovní práce se sbíječkou v obytné čtvrti (často taky od 7 hod. ráno) bez jakékoliv protihlukové (a mj. protiprachové) stěny. Já přece taky nedávám všem lidem v okolí 200 metrů najevo, že jako pracuju. Pokud dělám něco hlučného, tak se předem u lidí, které to postihuje omluvím a aspoň zhruba nastíním o co se jedná a v jakém rozsahu.

    A když jsme u těch počítačů, tak ty údaje výrobců o hlučnosti jsou úplně k ničemu, protože údaj v dB nezohledňuje, jestli to je takové ležérní vrnění nebo nervy drásající kvílení. V dnešní době je s podivem, že u profesionálních produktů jakým jistě Thinkpad má ambice být neposkytují nahrávky zvukového projevu v idle, medium a full power. Tak ale co by člověk chtěl po firmě, která ani nedokáže za 40 tisíc Kč vyrobit laptop, kterému se do displeje nebude obtiskovat klávesnice a ničit tak ostrost a barevné podání LCD.

  • 12. 11. 2020 11:18

    mprasil

    Display ma spotrebu niekde okolo 15W (neviem to presne, len som rychlo nieco pozrel, ale niekde tam sa to bude pohybovat), dalsie komponenty povedzme dalsich 5W. Ked to CPU znizi spotrebu z 20W na 10W, tak celkova spotreba sa znizi z 40W na 30W. Cize stlacenim spotreby CPU na polovicu uz dosiahnes len priblizne stvrtinovu usporu. Keby si opat stlacil spotrebu CPU na polovicu, tak sa celkova spotreba posunie z 30W na 25W, cize uz len osmina celkovej spotreby.

    Cim netvrdim ze nema zmysel tu spotrebu riesit, ale ze sa dostavame do fazy kedy CPU nie je zas taky zasadny komponent v tomto.

  • 11. 11. 2020 23:09

    Calculon

    Apple je s absolutním výkonem na špici už od A12(X), třeba takový SQ1 kulhá hodně daleko za ním (je to obyčejný přejmenovaný Qualcomm, nicméně i přesto je svižný i s Windows, na rozdíl od třeba Surface Go). Ten nový M1 je ještě o řád rychlejší (CPU, GPU i neural engine). To už je výkon stylu "Porsche Carrera jezdí rychlostí 289 km/h" - jo, je to oficiální maximum, ale kdo z nás tolik v životě pojede (nejen na parodii na dálnici D1).

  • 12. 11. 2020 14:59

    moon lizard

    Ked si pozriem web Apple, tak pri MacBook Air M1 vidim:
    FinalCutPro -> 3,9x faster ProRes transcode
    Xcode -> 3,6x faster project build
    Logic Pro -> 2,5x more Amp Designer plug-ins
    Adobe Lightroom -> 2,3x faster image export

    oproti predchadzajucej generacii MacBook Air.

    Takze tam dali konkretne ulohy, ktore vysli najlepsie pre M1 model MacBook Air. Urcite by sa nasli take ulohy, kde by tie rychlosti vysli velmi podobne a prinich by sme mohli napisat, ze novy Air je rovnako rychly ako predchadzajuca generacia. To je marketing.

    Na druhu stranu tu mame GeekBench, ktory ma tiez svoje chyby, ale aktualne je to najobjektivnejsie meranie ktore je k dispoziccii. A v tomto teste vysiel novy Air, rovnako alebo lepsie ako MacBook Pro. Viac faktov nemame.

  • 14. 11. 2020 12:04

    Calculon

    Na bláboly jabkofobů nemá smysl reagovat. M1 je prostě dělo (tím spíše, vezmeme-li v úvahu TDP). Snad se Qualcomm poučí, vylepší své ARMové procesory a třeba se pak dočkáme Surface, který také bude super rychlý. Současný Surface Pro X je ostatně už teď srovnatelný s lepšími intelími Surfacy. Víc než výkon, který je bez konkurence už od A12, je zajímavější cena — Macy s ARMem jsou překvapivě levné.

  • 11. 11. 2020 22:37

    bez přezdívky

    Zajímal by mě rozdíl mezi vlastním ARMem Applu a ARMem jako takovým, potom taky kam vlastně bude směřovat ARM po koupi Nvidií a jak na to asi reaguje Open-Source komunita