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.
10nm intelu je cca 7nm TSMC.
Tak to hodně CCA.
TSMC má nyni výrazně lepší takty. Uvidíme kam se intelovských 10nm podaří vyladit.
ja bych s komentarem "10nm intelu je cca 7nm TSMC" celkem i souhlasil. Neni identicky, ale blizky celkem je.
I ty frekvence jsou celkem podobne. Intel byl zvykly na velke marze. Proto se soustredi na vyteznost. U techto procesu je vyteznost nejvysssi u malych chipu (stejne jako u jinych procesu). Doslo proto k nasazeni zatim hlavne u mobilnich aplikaci. Tam je zase dulezita nizka spotreba a je proto i frekvence drzena celkem nizko. Urcite se to od pasu neda srovnavat s desktopovym CPU a jejich frekvencemi.
Co jsem videl vykonostni parametry, tak to skutecne vypada, ze Intel 10nm ~ 7nm TSMC.
Intel okopíroval Apple M1 procesor, který obsahuje 4 výkonná jádra a 4 úsporná jádra.
Apple M1 je už ale na 5nm, zatím co Intel na zastaralých 10nm a zřejmě opět svelkou spotřebou oproti konkurenci Applea AMD.
Neblabol.
Apple připravuje nový revoluční procesor Apple M2, který už bude pravděpodobně na 3nm a má mít 6 výkonných jader a 6 úsporných jader.
Intel Alder Lake na neefektivních zastaralých 10nm s mnohem vyšší spotřebou a velkým zahříváním to bude mít těžké, jak proti AMD, tak proti Apple a Qualcommu, který také připravuje výkonný PC procesor.
Tyhle zvasty si nech od cesty. Cely tenhle koncept neni zadny vynalez Apple, jak se fanboyove ted snazi tvrdit. Prvni mainstreamove pouziji je big.LITTLE, ktere tu bylo davno pred M1.
Qualcomm spojovat s Apple fanboys? No ty máš fantazii :))
Bavíme se o PC segmentu a v něm byl Apple M1 s big/little první.
Coz ale v nicem nedokazuje to, ze se Intel jimi nechal inspirovat popleto :)
Na big.LITTLE armech už dost dlouho frčí Chromebooky a pár generací notebooků s Qualcommem na Windows ARM už taky vzniklo před Applem. Apple je první akorát v tom, že začal na zelené louce a postavil nejfunkčnější řešení i pro mainstream.
Apple v podstatě nebyl v ničem první. Jen dokázal nejlépe odhadnout na trhu již existující technologie a spojit je v plně funkční celek. To znamená vzal cizí myšlenky a implementoval je lépe. Dokonce i název iPad musel koupit :-)
Microsoft zase "získal" Wokna od Apple. To se děje všude.
a Apple zase "okopčil" (bol inšpirovaný) mašinu menom "Xerox Alto (1973)", či "Xerox Star Workstation (1983)" rovno aj s GUI (s oknami) a myšou. Prvý Apple Macintosh s GUI a myšou prišiel až v roku 1984. Microsoft o rok nato vydal svoj prvý Windows (1985).
https://www.google.com/search?q=apple+vs+braun
big.LITTLE je tu trochu déle, než M1 ... Takže kdo byl první s touto architekturou ?
A nebyl náhodou první procák BIG/little od Qualcommu? Nevím, ale Apple první IMO nebyl. Navíc To, že dobré nápady se opisují a vylepšůjí je podstatou rozvoje. Jinak bychom tu všichni otročili s klacky pod nadvládou kmene se sekeromlaty :D
Lidi, kteri umyslne, dobrovolne a s takovou vervou lzou by meli - stejne jako sexualni predatori - mit povinnost byt viditelne oznaceni.
Intel pouzil koncept znamy z roku 2011, davno predtim, nez se Apple vubec rozhodl udelat si vlastni CPU.
„TSMC má nyni výrazně lepší takty.“
Jak se to projevuje?
Ryzen 9 5950X - 4,9 GHz
Core i7-11375H / i9-11980HK - 5,0 GHz
Mozna myslel takt vuci spotrebe v zatezi :)
Možná, ale tam stejně nevíme, zda je spotřeba 10nm produktů Intelu daná daná procesem, nebo architekturou, nebo kombinací obojího.
Byt mas potencialne pravdu, tak ze by ta jejich jadra byla o tolik zravejsi nez AMD se moc nechce verit, zvlaste pokud tam nemaji ani chiplet. Osobne bych sazel porad na horsi parametry jejich 10nm. Podle mne je to hezky videt na srovnani mobilniho vykonu 15W vs 25(28)W TigerLake-U. U AMD tak propastne rozdily ve vykonu nejsou.
Ale to stále nedokazuje, že nemůže jít o vlastnost architektury.
Podle starších roadmap měly být 10nm produtky nejdříve šestijádrové, poté snad osmijádrové. To se týkalo nejvýkonnějších procesorů pro desktop, nikoli pro mobilní segment. Intel při vývoji těchto architektur vůbec nemusel počítat s tím, že bude potřebovat dostat osm takových jader do běžného notebooku. Intel hodně řeší spotřebu v idle a v klidu. To ale neznamená, že musel řešit spotřebu v zátěži, kterou možná jen nepovažoval z tehdejšího hlediska za problém: Intel neočekával, že by konkurence, která v začátcích vývoje Sunny Cove a Willow Cove vydávala 220W procesory s výkonem 65W Core i5, začala do 15W žiletek (bez problémů) cpát výkonná osmijádra. Stačí si vzpomenout - až zhruba do Zenu dával Intel do Ultrabooků Core i7 v podobě dvoujádra. Kdo ví, možná u toho plánoval zůstat i s 10nm generací.
Ale to stále nedokazuje, že nemůže jít o vlastnost architektury.
.. ano nedokazuje, je to porad jen hypoteza :)
Marketingově příhodně upravené parametry boostu pro jedno jádro, za cenu velmi nadměrné spotřeby. Jinými slovy. leštěnej prd. Kromě 28/56s "testy výkonu" je to téměř k ničemu.
ano, o turbeni PL2/TAU a vyuzivani intelom na odrbkavanie v kratkych benchmarkoch, ktore dovtedy stihnu skoncit - vieme svoje
ALE: vypovednu hodnotu to ma aj tak, staci si spomenut na desktopovy Broadwell, prve pionierske 14 nm pokusy v desktope z rokov pana 2013/2014, ked vysli DVA desktopove modely intel (A)CPU i7 5000 so silnejsou grafikou, ale o 1/4 slabsou CPU castou oproti 22 nm Hasswelu i7 4000, lebo CPU frekvencie toho 14 nm Broadwel zazraku boli brtutalne nizsie ... podobnu srandu sme videli v 2019 mobilnom segmente s gen.10 Ice Lake, ktore sice pridalo 18% IPC, ale v celom modelovom portfoliu mobilnych CPU aj o tolko klesli frekvencie oproti 14 nm gen. 8/9. kde boli frekv. v hrubom priemere o 700-1000 MHz vyssie (zaklady, 1T boosty, mutliT boosty ... proste VSETKY frekvencie) ... proste +18% IPC intel "uspesne vykompenzoval" cca o tolko znizenym frekvenciami, takze Ice Lake mobilny vykonovy zazrak sa nekonal ...
toto sa pri mobilnej gen. 11 intelu podarilo odstranit a frekvencie 10 nm (nazyvaju to SuperFin) su konecne take ako maju byt - a preto aj vykon.
Bude, bude, bude.... Jak známe Intel, bude leda zpoždění a horší výsledek všech snah, než se teď tvrdí.
Až to uvidím (v nezávislých testech), tak tomu uvěřím.
Som zvedavý, ako si poradia so slabinou číslo 3. Buď budú používať AVX 512 a potom nebude ten procesor úsporný a bude sa prehrievať, alebo AVX512 nepoužijú a potom to bude predražený Coffee lake refresh.
IPC velkých jader Alder Lake (Golden Cove) jen >50 % nad Skylake, takže „Coffee Lake-refresh“ bych se nebál. Blíž Skylake co do IPC budou ty malé Atomy Gracemont.
Už se ví jaké instrukční sady ten nový Atom podporuje?
zevraj svetko "bezne" (t.j. aj avx/avx2) okrem avx512
Já bych soudil, až to budeme mít fyzicky v ruce a až bude třeba dodatečně doladěno chování scheduleru. Ani tak moc mě nezajímají Windows (vzpomeňte, jak se scheduler řešil v době Bulldozerů tuším), jako spíš Linux.
" 3. Malá jádra nepodporují všechny instrukční sady jako velká jádra. Pokud aplikace umožňuje využití takové instrukční sady, pak buďto může Intel malá jádra odstavit "
.... ja to vidim tak, ze bude cely procesor hlasit jenom ty sady, ktere podporuji vsechna jadra.
Intel nemuze "mala jadra odstavit". Totiz tohle neni vec Intelu, tohle je vec CPU scheduleru v OS. Zasadni problem s myslenkou "mixovanych" instrukcnich sad je to, ze ani CPU ani scheduler dopredu nevi, jake instrukcni sady nejaky program pouziva. Oficialni cesta jak se program muze "zeptat" jestli CPU podporuje treba AVX512, je CPUID instrukce - jenomze ta vraci cele hejno bitu, CPU netusi na kterej bit se program ptal. Pokud vim, neni zadna instrukce ani flag v binarkach, kterym by binarka rikala "poslusne hlasim pane ministre, ja budu pouzivat AVX512". Umim si predstavit nejaka reseni, treba 1) udrzovat seznam programu se vsim co pouzivaji (dost nerealne), 2) hazet vsechno na libovolne procesory a hlasit vsude "full" podporu, pak kdyz program vygeneruje "illegal instruction" hodit ho na velka jadra (riskantni - teoreticky mohou vsechny programy skoncit na velkych jadrach), pripadne 3) pri spusteni programu nahodne hlasit nebo nehlasit podporu v CPUID. Vsechna reseni jsou dost naprd.
Jeste muze intel udelat jednu vec - to co AMD se Zen1, tj rozlozit AVX512 na polovicni AVX2-like instrukce uvnitr malych jader. Tohle je asi nejmene naprd reseni... ale porad naprd.
Kazdopadne to vidim tak, ze celej tenhle big.LITTLE v desktopu je docasna obezlicka, ktera ma resit prusvihy ve vyrobe. Az se vyroba vyresi, hodi to do kose. Ta relativni "uspornost" malych jader je pochybna (staci se podivat na Ryzeny 8C vs 16C - rozdil v base freq 400mhz, pricemz dvounasobek jader - ta efektivita stoupa naprosto brutalne s klesajici freq) a ty komplikace za to nestoji (IMO).
„Intel nemuze "mala jadra odstavit". Totiz tohle neni vec Intelu, tohle je vec CPU scheduleru v OS.“
Díváš se na to moc úzce. Intel klidně může dostat speciální zakázku od nějakého partnera, který bude systémy s Alder Lake objednávat kvůli AVX-512 a to bude i jeho podmínka. Intel pak samozřejmě může Atomy vypnout a nechat aktivní jen Golden Cove, aby AVX-512 běželo vždy. Proč by nemohl?
Toto platí za předpokladu, že scheduler zůstane, jak je nyní. Jenže se proslýchá, že přinejmenším část scheduleru bude přenesena na úroveň procesoru (hardwaru), takže Intel bude mít alespoň jednu ruku na volantu a bude schopný volit i elegantnější řešení než výše popsané.
> Atomy vypnout a nechat aktivní jen Golden Cove, aby AVX-512 běželo vždy. Proč by nemohl?
To samozrejme muze... tohle ma ale drobny problem - defacto to problem neresi, jen to hazi celej big.LITTLE koncept do kose :)
"Jenže se proslýchá, že přinejmenším část scheduleru přenesena na úroveň procesoru"
To je sice hezka teorie (o niz silne pochybuji), akorat mi neni vubec jasne, jak to resi problem ktery jsem nastinil. Tj na zaklade ceho bude ten scheduler (at v OS nebo v CPU) rozhodovat, co kam hodi. Vetsina programu si totiz "ocheckuje" CPU jednou, na zacatku, pak si to ulozi a ridi se podle toho. Jinak receno, scheduler musi udelat rozhodnuti "hlasit nebo nehlasit podporu AVX512" v dobe kdyz program sotva vykonal par instrukci. No necham se prekvapit.
Jedno reseni co mi napada je: hlasit u vsech jader podporu AVX512, s tim ze na Atomech budou vykonany ve dvou "AVX2-like" uops, a pak mit v kazdem jadre counter na to, kolik takovych instrukci vykonal bezici kod (podobne countery existuji uz dnes na jine veci). Scheduler by se pak jenom obcas podival na ty countery, a pokud nektery program vykonava moc tech instrukci, prehodi ho na velke jadro. Porad pomerne prasacky pristup, ale fungovalo by to. No, necham spekulaci konovi, ale moc me zatim tenhle koncept v desktopu neoslovuje.
Pochybujem, ze ide kazdu AVX512 instrukciu jednoducho rozlozit na dve AVX2-like. Nie je to len o "zdvojeni" AVX2.
No tak nekde to to budou 4 nebo 8 nebo x AVX2 instrukci - proste kazdou AVX512 instrukci lze vzdy rozlozit na posloupost jinych instrukci. Jen vykon jde v tom pripade do kytek.
Jenze to neni jen o tom vykonat instrukci a pripadne s tim, ze malemu jadru bude trvat X-krat dele.
To je o tom, ze ta instrukce musi byt pro to jadro znama, musi byt dekodovatelna a rozlozitelna tak, ze ji exekucni jednotky dokazou zpracovat. Coz vlastne je cela ta "podpora instrukce".
Tedy aby gracemont jadro bylo schopne ji vykonat, musi ji jako takovou celou podporovat. A to znamena mit silnejsi dekodery, prefetche, buffery, atp. A to je prave to, co by to male jadro velmi priblizilo velkemu a rozdil by byl uz jenom v poctu exekucnich jednotek a jejich taktu.
A nemohl by CPUID hlásit AVX-512 na všech jádrech a OS scheduler pak točit thready s AVX-512 instrukcemi jen na big jádrech?
Program by stále žil v domnění, že běźí třeba na 24-thread (8HT+8ST) CPU, ale Scheduler by AVX-512 zátěž točil pouze v 16 threadech na tom, co má k dispozici.
Nehovořilo se u Intelu, že si udělá hw scheduler v CPU? Nevím, jestli se to týkalo (už) Alder Lake, ale byla by to jistě zajímavá cesta (zejména pokud by to bylo na bázi Altera FGPA části).
Ano, ty zvěsti se týkaly právě Alder Lake.
Jsem skepticky z nekolika duvodu.
IBM tohle tak nejak ma v ramci Power arch ale nedostal se k tomu jednoduse, iteroval pres nekolik navrhu.
Kdyz by se to presunulo na HW, musel by k tomu byt podle me dobry ovladac, a Intel ovladace moc neumi.
Intel (a i AMD) jsou - po krachu ARM pokusu - dvorni dodavatele Microsoftu. Tedy zainvestovat pro poradny planovac se mi zda jako rozumejsi volba. Dotedka na ty zmeny v planovaci nebylo ze strany MS moc vule, ale Intel ma rozhodne dost silnou mrkev aby MS pobidl ;)
Přesně tak. Do x86_64 světa to přináší kupu problémů, ani by to k něčemu bylo a něco to řešilo, jako v ULW světě mobilních aplikací, kde Big-Little na ARMu je OK. Copak o to, kdyby to Intel dokázal vyladit (hahahaha), tak by to pro ultramobilní použití bylo skvělé, ale nikam jinam to nepatří.
Budu reagovat jen na toto:
Zasadni problem s myslenkou "mixovanych" instrukcnich sad je to, ze ani CPU ani scheduler dopredu nevi, jake instrukcni sady nejaky program pouziva.
Prakticky to je uplne jednoduse resitelny problem, protoze na takovem (malem) cpu nastane hw vyjimka zvana "Invalid opcode", na ktery se jadro muze zachovat klidne i tak, ze proces oznaci flagem ze uz se vi, ze vyzaduje AVX512, takze se uz nikdy nebude planovat na malej cpu. Az se priste tento proces zacne vykonavat (uz na velkem jadru), tak prvni instrukci po aktivaci procesu bude ona predtim selhavajici instrukce (instruction pointer se nezmenil).
Cele je to jen otazka Invalid opcode handleru, ktery namisto klasickeho zabiti procesu, zkusi zmigrovat proces na jiny typ jadra (velke, plnohodnotne).
Přesně to jsem chtěl napsat, píšu velké zanedbatelné "+". :-)
Jinak je možné, že tento "HW fallback" první úniky nazvaly "HW scheduler". On by to byl spíš takový "přicmrndávač" OS scheduleru (s určitou podporou u SW částí OS a driveru) .
To by sice teoreticky slo, ale neresi to jeden zasadni problem - vetsina aplikaci by skoncila jen na velkych jadrech. Stacila by jedina AVX512 instrukce nekde v nejake knihovne a sup na velke jadro. A pro aplikace s dobrym skalovanim by urcite bylo mnohem lepsi jet napr. na 14 jadrech s AVX2, nez na 6 s AVX512 (obzvlaste kdyz consumer cipy zcela urcite nebudou mit druhou FMA jednotku). Takze tohle by v podstate celou koncepci zabilo...
Pokud aplikaci neprinese AVX512 zadny vykon navic, protoze ta instrukce se pouziva jenom zridka, tak nema byt kompilovana s avx512. Protoze:
Zapnuti AVX512 trva nejakou dobu - radove do 1ms (nez nabehnou regulatory, hodiny). Proto vykonne aplikace maji instrukci hodne predem, ktera sice nic nedela, ale zaridi zapnuti one AVX jednotky.
AVX512 kvuli temto jednotkam, ktere pak musi byt krmeny zvysuji i tak vysoky TDP procesoru. Ten, po nejake dobe, co prestanete AVX512 pouzivat zas tuto jednotku vypne.
Takze prakticky dusledek nevhodneho pouzivani AVX512 ma jiz momentalne mnoho problemu, ktere zvysuji spotrebu a omezuji vykon.. a neverim ze tvurci aplikaci si toho nejsou vedomi - pokud jsou, tak tyhle instrukce nepouzivaj dokud nemusi.
Ono to je cele slozitejsi:
https://lemire.me/blog/2018/09/07/avx-512-when-and-how-to-use-these-new-...
Nejde o kompilaci, ale o rucne psany kod v knihovnach s detekci pres cpuid. Napr. systemove knihovny Win10 automaticky pouzivaji AVX512 pro sifrovani, hashovani atp. A pokud se nepouziji 512b registry a nasobeni (coz sifrovani nepotrebuje), tak ani nedojde k vyse uvedenym negativnim efektum. Ja to tak delam i ve svem kodu. AVX512 prinasi spoustu dalsich featur, nez jen 512b vektory.
Jenže to není jenom o AVX512, ISA rozdílů mezi velkými a malými jádry je o dost více.
Také - co se týče scheduleru - je plánování na úsporných platformách s Big-Little mnohem sofistikovanější, ovšem k tomu musí být speciálně "otagovaný" a "profilovaný" software, nedá se to řešit jenom nějakou "ychtělygencí" scheduleru - například je jasné, že energeticky výhodnější než se pomaloučku prasit s určitými výpočetními operacemi na malém jádru dlouhou dobu, je výhodnější to udělat na velkém, kde to má sice větší odběr, ale trvá to nepoměrně kratší dobu. Dtto jde o časově náročné záležitosti - např. v programu se musí něco "stihnout včas", třeba v rámci nějakého síťového nebo audio/video protokolu/zobrazení. A to všechno musí běžící software nějak zohledňovat, nejde to udělat "samo", musí to programátor analyzovat, zvolit, příslušně takové úseky kódu označit atd. aby explicitně vynutil přehození procesu na velké jádro, dokud nebude takový úsek kódu dokončen. Jinak je Big-Little provozně k ničemu, pokud se tyto speciální práce neudělají. Výsledkem bývají programy, které na Big-Little dělají psí kusy (z důvodů časů) nebo prostě zvyšují odběr více, než kdyby běžely pořád jenom na velkých jádrech.
Není to prostě až tak jednoduché, a Big-Little platformě musí odpovídat nasazený software. A pokud neodpovídá, tak holt bude problém - který se snadno "vyřeší" jen explicitní afinitou k velkým jádrům. Takže z Big-Little bude zase jenom Big.
K tomu všemu, infrastruktura x86_64 k tomu není nijak vybavena - třeba executable formáty (exe, COFF, ELF, ...) nemají žádné takové příznaky v hlavičkách, kde co pouštět, nejsou linkované s žádným start-up kódem/runtimemem, který by tyto věci nějak zohledňoval, kolem výpočetních částí nejsou žádné wrappery, které by vynucovaly afinitu... prostě je toho hodně, co je na Big-Little ARMech normální a na x86_64 to není.
Apple si tohle všechno může dovolit, protože má uzavřený systém, certifikační programy co jo a co ne, a prostě takové neudělané programy zakáže a nechá autory předělat, jinak je do systému nepustí.
afinitu si muzete resit prislusnym volanim do jadra ne? A neni to jenom o tom, udrzet svuj proces na jadru cislo X, ale ze to volani ma i formu - udrzet proces na skupine jader Y (kde Y je bud CCX, nebo proste numa node, aby nemigroval). Podobne si myslim ze existuje neco jako setaffinity(big) / setaffinity(little) - neni treba to resit v ramci statickeho linkovani nad obj souborama.. protoze runtime volani maji vetsi flexibilitu.
Takze staci kdyz k bigLittle pribude prislusne API v OS. At uz je tim win/lin/osx.
Tak jistě, jde to už teď, ale někdo to do programu holt musí napsat, na správné místo, samo se to neudělá... Takže přepsat všechy x86/x86_64 programy, kterých by se ty problémy mohly týkat? Jenom kvůli kvalitnímu chodu na Alder Lake bazmeku? Který stejně za chvilku půjde do křemíkového pekla... kam patří.
Uvažoval někdy diit o tom, umožnit čtenářům podpořit web pravidelným měsíčním příspěvkem ? Myslím, že na rootu jsou pak přispěvatelé označeni. Připadá mi to jako vhodná varianta jak podpořit web a nikoho do toho nenutit.
Pokud vím, tato možnost byla už v minulosti zavedena a přes výzvy v diskuzích byl nakonec zájem tak mizivý, že redakce po určité době peníze lidem vrátila a příspěvky (tehdy tuším pod názvem „předplatné“ zrušila). Fundovaněji by tehdejší situaci asi popsal WIFT.
Nemám informace o tom, že by se něco podobného plánovalo v blízké době zavést, ale podnět předám.
Myslím, že by nebylo špatné něco podobného rozjet, přes špatné zkušenosti z minulosti.
Doba se postupně mění a spoustu periodik tlačí svoje čtenáře k tomu, aby přispěli na obsah. Také se tu začíná objevovat nová generace, která už je zvyklá za obsah platit (twitch, patreon).
Za papírový časopis byli lidé zvyklí platit třeba 100 Kč měsíčně, klidně bych podobnou částku platil.
Je tu vidět spoustu dobré práce a rád bych, aby to tak zůstalo. Už začínám být alergický na povrchní weby, mnohdy placené firmami. Stačí se podívat, jakým směrem se vydávají hlavní zpravodajské weby na netu, jsou schopni vydat 100 - 200 článků za den s naprosto pochybnou kvalitou. Raději si přečtu, jeden a kvalitní.
Nojo, ale svět nás se všemi těmi smartphony a jůtubem nastavil na povrchní hltání stovek dílčích balíčků informací denně. Málo lidí už ocení pořádné, do hloubky dělané periodikum (viz moje oblíbená vzpomínka na to jak WIFT psal 14 dní superboží článek o ECMA normě na holografický disky a čtenost mizerná, přičemž já ve stejné době za 10 minut napsal nějakej vejšplecht o (tehdy) Windows Vista a čtenost snad desetinásobná). To bylo už před mnohem více než 10 lety.
Jinak já osobně nikde žádné předplatné na žádném webu nemám a mít nechci. Představa jak tu platím 150Kč za netflix, tu 100Kč za spotify, tu 80Kč za roota, tu 80Kč za diit, tu XY Kč za další službu a v součtu to je 1000Kč+ měsíčně, tedy ceny nové bezzrcadlovky každý rok, případně řekněme polovina ceny auta za 10-15let, tak jsem já vychován nebyl. Ale souvisí to s tím, že prostě nemám potřebu platit za do češtiny přežvejkané informace, které jsou na původním zdroji zadarmo, takže mě žádný článek schovaný za paywall nezajímá. Výjimek bylo zatím asi 5 za posledních 10 let, ale vždy šlo o nějakou původní tvorbu daného periodika. Čili vlastně pro jinak řadového čtenáře rootu, pokud by měl zajímaly témata o kterých píše třeba Pavel Tišnovský, bych v předplatném problém neviděl.
Vysielajte na Twitchi a hneď bude väčší záujem. Odkedy u vás nerobí Swift, nemali ste jediné video. Pri recenzii HW by som to uvítal. Neviem si predstaviť Swiftov článok o magnetooptickej mechanike bez videa.
Karas uz mal video ;)
Jen historické připomenutí: DIIT o tom alespoň za mé éry neuvažoval, protože předplatné pro čtenáře jsme měli v éře CDR a naopak s přechodem na nový redakční systém skončilo. Tehdy jste si dokonce mohli předplácet tak, že vícestránkové články byly na 1str, nula reklam, tričko CDR atd. Ale nefungovalo to, předplatitelů bylo marginální minimum. Za root tu hovořit nebudu.
Díky za info, jsem přesvědčený o tom, že doba se mění. Více viz příspěvek výše.
Však se na rootu podívejte, kolik tam těch předplatitelů je. Z toho si pak odhadnete, kolik jim to tak vynáší.
A je to fakt málo.
Zvlášť, když si vezmu třeba články pana Tišnovského. Pokud ten by za to chtěl odpovídajícím způsobem zaplatit, myslím, že by se všichni platící čtenáři by za měsíc nesložili ani na jeden.
No, z toho co máme uvedeno mezi předplatiteli, mi to dává cca 12k měsíčně. To je samozřejmě málo na nějaké živobytí celého serveru nezávislé na reklamách. Ale já si stejně myslím, že Pavel Tišnovský je mimozemšťan z jiné galaxie, kterého efektivita převodu osobního času na autorské honoráře netrápí :-D.
Lépe bych to neřekl. Skoro až nechápu, jak někdo může mít tak obsáhlý a odborný přehled v toliko různých kategoriích. Jeho články o herní historii a historii HW (včetně obsáhlých technických a funkčních detailů) mne inspirovaly k tomu mému amatérismu, který teď na root smolím sám. :-) Ale tam technické detaily beru jen zlehka po povrchu, ostatně když tam hned vedle existují jeho články, tak nějaký můj pokus o detailní rozbor problematiky by byl jen...směšným v porovnání...
S tím naprosto souhlasím. Pan Tišnovský to musí dělat z jiných důvodů než finanční zisk :-)
Chtěl jsem spíš ukázat na to, že to placení toho zase tolik nepřinese. Root.cz asi nemá kdovíjak moc čtenářů, zato si myslím, že to budou lidé, pro které těch pár desetikorun nebude tolik, a uvědomují si nutnost přispívat na projekty takového typu.
Na Živě zkusili Premium, i tam si myslím, že to nebude žádná láce. Tady na diit.cz, který je (dle mých odhadů) mnohem menší na počet čtenářů, to snad ani nemá smysl, pokud by se nenašlo něco dalšího k tomu.
Tak co nejake porno video s HW rekvizitami v cene preplatneho jednou mesicne/tydne? :-))
Anebo kalendář s geeky? (seriál The IT Crowd, S03 ep. 6). :-)
Excellent idea!
:-D
Porno a promo Intelu, už je to tady :)
"Silné stránky Alder Lake:
3. Umožňuje to Intelu vydat novou architekturu i na starším procesu. Zatímco AMD se Zen 4 čeká na novou generaci procesu (5nm TSMC), Intel může novinku vydat na 10nm procesu (cca ekvivalent 7nm TSMC), protože velkých jader, které zabírají většinu plochy a generují většinu tepla, je polovina oproti procesorům AMD."
Tady poznávám PR odd. Intelu.Tohle normálně nikdo nevymyslí:
10nm není 10nm, ale 7nm...protože Intel ... :)
Přidáme balast Atom a hned je polovina ztrátového tepla cpu pryč .... :)
Vis o tom, ze jsi nemocny?
Marketingová sdělení Intelu jsou v posledních letech horší než hlášení Rádia Jerevan za bolševika. Takže je to nutné uvést na pravou míru: Alder Lake nebude v druhé polovici roku, ale bude paper launch v prosinci, mobilní verze bude pár demonstrativních kousků v červnu 2022, desktopová na podzim 2022. V procesoru bude hafo chyb, atomová jádra budou chcípat kvůli chybám v návrhu jako to rády dělají poslední generace Atomů. Koncept Big-Little je pro x86_64 svět rána do vazu, protože dřevní historický software, kterého je plno, nebo i nový software, který je přeložený na moderní instrukční sady, prostě pojede blbě - všechny programy se budou muset hodně přepsat, aby neustále testovaly kapability jader, zda to náhodou scheduler nepřehodil na vykriplené atomové ISA, nebo holt bude muset být u všeho natvrdo zapnutá procesorová afinita na velká jádra. Stejné potíže jsou samozřejmě u Big-Little na ARMu, ale tam se pro to píše spešl soft "from the scratch", zrovna tak jako u jablečné církve. Přináší to značné množství dost palčivých problémů, takže nevěřím, že v komponentově/multithreadově psaných systémech jako jsou Wokenice (jádro systému a utils jsou pořád dělané starým dobrým DCOM+ jen maskované v novější implementaci), kdy je všechno rozjebané do kvadrilionů tasků, to bude chodit. O uživatelském softu, který je šitý skoro všechen horkou jehlou, to bude interesantní. V x86_64 světě totiž neexistuje žádný zažitý přístup, či dokonce podpůrný mechanismus, nástroje, knihovny, ... na komplexní testování kapability jader, není na to ani "zvyklost" a "norma" už vůbec ne. Jen se podívejte na AMD, jak dlouho jim trvalo alespoň záplatovat libc/glibc základní knihovny, aby používaly moderní instrukce na Ryzenech nebo EPYCech. Frameworky ani toolkity nic takového nepodporují, na rozdíl od ARM Big-Little scény. Takže je předem jasné, jak to skončí: blbě. Intel to při své zhovadilé liknavosti nedokázal vyřešit za celá léta ani na mnohem jednodušším poli AVX512: těch je v samotném Intel světě hafo, a naprogramovat soft, aby poznal a optimálně použil "to pravé AVX512" je úkol pro specialistu. Dtto to bude s tímhle asymetrickým čudem. Pokud mohu predikovat, nakonec to dopadne tak, že scheduler bude pačnutý, aby na vykriplená atomová jádra s*al jak na placatej šutr, s explicitními výjimkami některých programů a "services", které budou naprogramované, aby na tom zázračném čudu jely OK, aby ta malá jádra nebyla úplně idle. Absolutně skvěle a bezchybně na tom pojedou akorát benchmarky, aby marketing Intelu mohl jásat a vyšly hezké (přeplacené) recenze.
Pekne zhodnoceni budouci architektury Intelu. :-)
Dodam jeste jednu vec, ktera z toho jaksi vyplyva sama. Kdyz budu mit 8 velkych jader a nic vic (treba u AMD), tak na ne spotrebuju presne X kremiku. Kdyz bude u Intelu 8 velkych jader a 8 malych nevyuzitelnych, tak pokud no-X pise, ze 4 mala jadra jsou objemove jako 1 velke, tak u Intelu plocha zabere X+2 kremiku. Tudiz, aby procesor Intelu byl jen co se tyka vyroby za stejnou cenu jako procesor AMD, tak to jaksi nejde, snad jen za cenu, ze by si Intel kratil marze. (Posledni vetu berte jako vtip.) :-)
Kvolaa to opravdu zhodnotil a shrnul velmi dobře.
Jen technická k tomu výpočtu: myslím si, že lépe by se to dalo vyjádřit přes X = 1 tlusté core.
Pak: starý 8C Intel má 8X
Alder bude mít cca: 8X+2X = 10X, je to tedy růst o 25%.
To může, ale taky nemusí být problém, už proto, že Intelovy mm2 a TSMCkovy mm2 nejsou úplně srovnatelné, jak hustotou, tak cenou za mm2.
Jasne, byl jsem tlacen casem, tak jsem to nenapsal uplne logicky spravne. Slo mi hlavne o to, ze cena za 8 velkych jader bude vzdy mensi nez za 8 velkych a 8 malych jader. Samozrejme, neni to u obou spolecnosti uplne stejne a nakonec to neni jen o tom kremiku, stejne tak vyvoj velkych jader bude stat mene nez vyvoj velkych a malych jader vzhledem k tomu, ze se jedna o ruzne architektury. Proste si nemohu pomoct, ale i z financniho hlediska mi to biglittle do PC prijde jako dalsi velke fopa Intelu. Technicke hledisko nesmyslnosti pocinani Intelu uz popsal opravdu perfektne kvolaa.
Srovnání Apple M1 a Alder Lake by bylo zajímavé. Jak se velká/malá jádra chovají v aplikacích a co to přináší.
Qualcomm rovněž připravuje výkonný SoS procesor pro PC, Samsung také, tak vyhýbat se srovnání s těmito moderními, výkonnými a úspornými architekturami by byla velká škoda.
Problem je, ze se to blbe srovnava, protoze kazdy ma svuj vlastni rybnicek a kazda z tech architektur je jinak orientovana. Coz ty a tobe podobni nejak nechteji pochopit chteji mit ze vsecho jeden velky vonavy gulas ;)
Intel hraje předem prohraný boj v consumer segmentu a proti moderním, úsporným a vysoce výkonným SoC procesorům nemá nejmenší naději prosadit se v blízké budoucnosti na trhu. Kupující rybníček Intel nezajímá, chtějí výkon a úspornost.
Srovněj archaickou desku PC Intel a desku Apple M1. Přichází high-tech ze segmentu nositele současného vývoje - mobilů.
Qualcomm a Samsung následují se svými procesory pro PC..
AMD by to měla rychle pochopit, jinak také uvízne v bahně Intel Lake.
Intel ani AMD proti Apple rozhodně neprohrává, protože "všichni nemůžou být jako Apple", zrovna tak jako všichni nemůžou mít Tesla elektročudo místo pravého auta, protože nejsou elektrárny, nejsou silové rozvody, nejsou nabíječky, a skryté dotace toho čuda by rychle vyběhly na světlo, pokud by to mělo více než 1% uživatelů - analogie je to samozřejmě povrchní, ale ukázková.
Apple si takovéto optimalizační brikule může dovolit především proto, že má naprosto rigidní a uzavřený systém, jeho kompletní prostředí (environment) od návrhu, vývoje, nástrojů, frameworků, programátorů, distribučního modelu... je centralizovaný a tvrdě a absolutně řízený.
Takže ho netrápí, že si zavede Big-Little třeba. Protože pro to vydá všechny přepsané a překompilované programy nebo upraví dynamické knihovny, centrálně a pro všechny opačuje systém, následně upraví frameworky a celé to jablečné obludárium.
To v rozháraném světě x86/x86_64 zkrátka nejde. Jenže na rozdíl od Apple to nabízí flexibilitu a historické vazby, kontinuitu atd. Na všechny tyhle věci Apple může kašlat, prostě staré programy od určitého data zakáže a hotovo, polibte si. Jako s jejich servisem, prodejem, ...
Oba přístupy mají své výhody a četné nevýhody...
Svět ICT prostě nejsou jenom vyglančené módní čuda od vznešeného Apple, ale mraky a mraky různých x86/MIPS/SPARC/ARM/... vykopávek, všude v provozu celá léta.
To máš jako ve vědě. Výpočetní programy, knihovny, jsou ještě dneska používané ve Fortranu, ačkoliv jinak jde o dokonale mrtvý jazyk. Není lidské síly se na to vrhnout a komplet to přepsat do něčeho normálního... takže programy ve Fortran90 (nebo 2040) budou furt...
"Takže ho netrápí, že si zavede Big-Little třeba. Protože pro to vydá všechny přepsané a překompilované programy nebo upraví dynamické knihovny, centrálně a pro všechny opačuje systém, následně upraví frameworky a celé to jablečné obludárium."
Alder Lake také zavádí po vzoru Apple/Qualcomm Big-Little. AMD dosud ne :(
Dnes je výkon moderních SoC cpu tak vysoký a zárověň jsou tak úsporné, že minimální ztráta výkonu emulaci Windows a čehokoliv, je oproti získaným výhodám akceptovatelná.
spíš díky bohu, že amd to nezavádí, to vůbec nedává smysl, v PC/server/WS sféře, možná ještě tak pro zařízení s baterií by se to dalo jakš takš pochopit
arm je jasné proč to udělal tam se bojuje o každou hodinu výdrže navíc
a hrozně rád bych chtěl bejt u toho když se rozhodovalo o tom co alder lake bude, si to dovedu představit, nějakého externího konzultanta jak tam bleje svoje moudra, jak arm to válcuje a je potřeba udělat to samé, aby neujel vlak, přitom se mohli inspirovat amd a udělat čiplety protože to evidentně funguje na výbornou
nechceš psát pro diit :D
Dáš mi nějaký námět článku?
Na jaké téma bys mě odhadnul?
tebe jsem nemyslel,
to byla reakce na kvolaa který evidentně má co říct
ty bys mohl mít nějaký honimírský článek na téma M1 proč změní svět k lepšímu nebo něco takového :)
To říkal Limonádový Joe John Sculley o Steve Jobsovi také.
A podívej co z Apple Jobs nakonec udělal, nejcennější firmu světa. :)
Za Jobse nikdy Apple nejcennější firmou nebylo, stalo se jím až těsně po jeho smrti
to přece nic neznamená, nevypovídá to nic o tom, jestli byl dobrý člověk, nebo apple je firma, kterou má cenu "následovat", protože to dává smysl
co jobs vycítil dobře je potřeba víry, dnes se věří víc muskovi a korporacím, než třeba selskému rozumu, že cryptoměny v téhle podobě je fakt zvěrstvo
Nějaké pro duševně choré?
.
Doufám, že Atom jádra půjdou vypnout. Popravdě toto moc nefunguje ani u ARM. Ostatně není se co divit, že Apple M1 dal jen do nejlehčích strojů a u výkonnějších se čeká na výkonnější verzi, kde bude dostatek výkonných jader.
V mobilu mám Qualcomm SD855 v konfiguraci 1+3+4 a u aplikací, které mají více nárazových a zároveň hladových úloh je to dost vidět.
Probíhá tam intenzivni race o to nejvýkonnější jádro, a výsledkem je trhaný běh aplikace. Byl bych raději, kdyby ta konfigurace byla alespoň 4 + 4 s tím, že ty slabé jádra běží jen v případě klidu. Pokud je požadovaný výkon na úrovni nižší, než je limit těch 3 jader méně taktovaných jader z výkonnějšího clusteru, tak k problému nedochází. Je to optimalizované na nějakou střední zátěž.
Paradoxně u výrazně pomalejšího SD636 k sekundovým zásekům nedochází právě proto, že má konfiguraci 8 + 0 jader a tak se úlohy nemusí přehazovat mezi jádry. Jede to sice pomaleji, ale plynuleji.
Bojím se, že u tohoto slepence od Intelu to bude podobné. Jsem zvědavý, jak si s tím poradí virtualizace. Doufám, že to nějak odladí. Ovšem sranda bude, až budu zase vysvětlovat okolí při koupi nového stroje , že toto není 12 jádro ale 8 + něco co nechceš.
Tak ono se tu míchá více věcí; a) koncept b) konkrétní provedení c) podpora/připravenost systému. On ten koncept big.LITTLE je zajímavý a může fungovat, ale třeba SD855 (resp. SoC s takovou konfigurací) mi přijde dost překombinovaný. K tomu se váže ten systém; on zrovna Android je dost hnus i na jednodušších konfiguracích. Bohužel si teď moc nic jiného vybrat nejde...
Naopak u toho Applu se zdá, že se jim to celkem povedlo. (I když teda ten marketing okolo toho je fakt přehnaný.)
Divím se, že Intel nepřidá HT na Atom jádra. To by teprve marketingové oddělení slintalo. By pak mohli prodávat 10/20 až 16/32 konfigurace které by ve skutečnosti byly pořád jen 8 jádro. Už vidím ty popisky v eshopech ... "16 jader, bla bla dlouho bla bla a pak 8 ultra rychlých jader a 8 super rychlých jader dává k dispozici neomezený výkon bla bla bla", no hnus. Aplikace poběží natvrdo na velkých a Windows služby na malých aby se neřeklo. V reálu pak BFU stejně nic nepozná a je spokojený že má stejně chlívečků("procesorů") v taskmanageru jako kamarád s Řízkem. Protože která aplikace pro BFU musí běžet na víc jak 8 fyzických jádrech, že?! Ne, HandBrake není apka pro BFU :-)
Ja mam ten 8C/8T atom C2000-series (2750?) .. a -j9 kompilace kernelu na tom bezi tedy hodne marne (v porovnani s beznym, plnohodnotnym 4C/4T, ktere taky ze ma ale cca 2x vetsi TDP)
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.