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.
Male jadra by nemali byt odlisnej mikroarchitektury ako v pripade Intelu, ale tej istej.
Uplne odlisna mikroarchitektura malych atomovych jadiet a velkych core jadier robi Intelu neskutocny mrdnik.
Male jadro by boli male, resp. male CCX by bolo male CCX preto, lebo by napr. nemalo mamutich 32 MiB L2 ale iba 8 ci 12 MiB. L2 by napr. tiez sla na polovicu alebo 3/4. Pripadne ine obmedzenia, ale nie take, ze by to bola ina mikroarchitektura.
>Male jadra by nemali byt odlisnej mikroarchitektury ako v pripade Intelu, ale tej istej.
Ale toto vyzerá na niečo úplne iné.Pripadá mi to ako "Skybridge II" s reminiscenciou na K5/am29000, kde AMD dala x86-kový dekóde inštrukcií na dve jadrá AMD am29030 (teraz by to mohla napáiť napr. ARM Cotrex A52) s doplnkovým ARM dekóderom pre jadrá Zen3...
K12 zahrnuje ARM i x86 moduly
6. 5. 2014
2015 - SkyBridge
Napřesrok totiž dojde ke sjednocení vývoje x86 a ARM architektur. Pod názvem projekt SkyBridge chystá společnost modulární design, který sjednotí podobu APU / SoC do té míry, aby bylo možné v rámci jednoho návrhu používat jak x86, tak ARM jádra (aby nedošlo k nedorozumění: buďto jedna, nebo druhá) jako hlavní výpočetní jednotky. Je sice pravda, že již nově uvedená generace SoC Beema a Mullins disponuje obojím (zároveň), ale ARM procesor slouží výhradně jako bezpečností koprocesor, ne jako univerzální výpočetní jednotka.
https://diit.cz/clanek/amd-k12-podporuje-x86-i-arm
Zen zvýší IPC o 40 %, K12 je posunutý na rok 2017 a SkyBridge zrušený
7. 5. 2015
https://diit.cz/clanek/zen-v-roce-2016-k12-v-roce-2017-skybridge-zrusen
AMD K5
The K5 was based upon an internal highly parallel 29k RISC processor architecture with an x86 decoding front-end.
https://en.wikipedia.org/wiki/AMD_K5
Skybridge je mrtve! Nejsou zadne indicie, ze by melo byt rezu-erektovano.
Zaroven nechapu, proc sem pletete ZEN/K12 narust vykonu.
Z obrazku je zrejme, ze o nejake dekodovani na ARMu, ci podobnou magii. Ty "low-feature" jadra by musela dekodovat a pak nacpat data do cache, ktera by to zreplikovala do cache "high-feature" jadra. To nedava vubec smysl.
To je možná implelmetácia. V patente nie je dekódovanie pre ARM. Len to tú možnosť prináša, Ale v patente je aj obrázok so zdieľanou sadou registrov
Fig2. na str 4
http://www.freepatentsonline.com/10698472.pdf
Edit:
Ale ja nehovorím a dokódovaní inštrukciíí na low jadrách, ale, že by v CPU boli dekóderi aj ARM aj x86 inštrukčnej sady do kódu pre veľké a kódu pre malá jadro, kde by boli Zeny a Cortexy
Sdileny registr je myslim dost mimo kvuli latencim. Navic i sdileny registr by resil data.
Udelat CPU takove, ze je to mix x86_64 a ARM architektury? Jak by to mohlo vubec fungovat? Co ja vim, tak neni OS ktery by byl schopen zaroven jet na x86 a ARM instrukcni sade. Napada me jedine ze by na na tom bezel nejaky VM jako x86host a slo by spustit masinu, ktera by mela dedikovane ARM jadro (a v te masine pak OS pro ten ARM). Ale znovu... jak by tohle mohlo byt obecneji pouzitelne, nez jen pro sileny okrajovy pripad?
nexituje, ale dá sa urobiť. Vyplniť NOP-mi miesta, aby boli virtuálne adresy pre obe architektúry rovnaké, mať duálnu binárku ako napr. oživením FATelf:
Ryan Gordon Brings Universal Binaries To Linux
Written by Michael Larabel in Linux Kernel on 22 October 2009 at 09:32 AM EDT.
One of the interesting features of Mac OS X is its "universal binaries" feature that allows a single binary file to run natively on both PowerPC and Intel x86 platforms
https://www.phoronix.com/scan.php?page=news_item&px=NzYyNQ
https://www.phoronix.com/scan.php?page=news_item&px=NzY3Mg
A mať dve tabuľky stránok jednu pre x86_64 a druhú pre ARM. A pri preplánovaní procesu- vrátane procesu jadra by sa len prepol CR3 (resp. jeho alternatíva na ARM) na spávnu base address..
To nestačilo AMD fiasko s Buldozerom?
Skvor sa mi zda že ZEN4 alebo ZEN5 budu mať viac vlakien na miesto 1-2 rovno 4 vlakna.
Vráť sa prosím na Pokec... :(
Ale on nie je úplne mimo, aj keď to podáva nekorektne
Buldozer bol SW kruto nezvládnutý. to bol aj Zen, Zen+ aj Zen2 a k náprave dôjde až v januári/lednu 2021 a Zen3 bude pravdepodobne prvé SW zvládnuté CPU od AMD od K8.
Len 17h family (Zen,Zen+,Zen2) slušne pracuje s neoptimálnym kódom, čo pri asymetrických CPU nie je možné dosiahnuť. A ted bude to vyžadovať nové verzie SW, alebo aspoň runtime knižníc.
Tento a minulý týždeň som o tom písal snáď 4-5 x na diit.cz, takže tam sú zdroje,,
P.S. Ja som Vám obodm dal +, aleb o ja nedávam - iba, ak je dôvod, +
Pokud SW znamena v tomhle kontextu software, pak je to spatne.
Bulldozer koncept teoreticky nebyl spatny, ale na software, specialne planovac ve Windows AMD nemelo vliv, takze byla chyba navrhu delat neco, u ceho nemuzu zarucit spravnou funkcnost. AMD nebyla schopna ten koncept zrealizovat v podobe, kdy by to pro OS bylo jako cerna krabka co se chova ocekavane ale uvnitr dela magii co zvysuje vykon. A rict ze to bylo SW je hledani obetniho beranka.
Bulldozer teoreticky mel na to, aby jel 3-4IPC na modul, ale fakticky na tom byl hure, nez K10 (ktera jestli se nepletu mela podle testu prumerne 2.1 IPC na jadro pri dlouhodobe zatezi). Problemy byly v predpovidani, dekodovani, zasobnikach, atp. napr penalizace pri spatne predpovedi byla oproti Sandy Bridge nebo Haswellu desiva.
SW je software
Ale je to dodnes
HWCAPS tu stále nie je a AMD beží na kóde pre Sandy Bridge (vrátane podporovaných inštrukcií) a teda v niektorých tzpoch úloh beži ZEN, Zen+ a Zen2 na 1/3 výkonu kódu, ktorý využíva len inštrukcie z roku 2013 a novšich (v knižnici jazyka) a niee je (v knižnici jazyka) optimalizovaný na Zen, Akrurát ten výkon je tak vysoký, že aj s penalizáciou 66% je konkurencie schopný, Ak AMD získa významný podiel na trhu, tak sa začnú používať riešenie s knižnicami, ktoré budú optimaliuzovať kód aj pre AMD. A najhoršie, čo sa môže stať, že budú optimalizovať kód len pre AMD, tak ako dnes optimaizujú len pre Intel a to blokuje rast podielu AMD, aj keď ten rast je obrovský, mohol by byť ešte väčší
1.
AMD Developers Looking At GNU C Library Platform Optimizations For Zen
Written by Michael Larabel in AMD on 25 March 2020
Stemming from Glibc semantics that effectively "cripple AMD" in just checking for Intel CPUs while AMD CPUs with Glibc are not even taking advantage of Haswell era CPU features
https://www.phoronix.com/scan.php?page=news_item&px=GNU-libc-Platform-Op...
2.
Glibc-HWCAPS To Help With AMD Zen Optimizations, Other Per-CPU Performance Bits
Written by Michael Larabel in GNU on 7 July 2020
https://www.phoronix.com/scan.php?page=news_item&px=glibc-hwcaps-RFC
3.
GNU C Library 2.32 Released
Written by Michael Larabel in GNU on 6 August 2020
Sadly not making it for this release is the restartable sequences support. Additionally, the hardware capabilities discussion is also still ongoing.
https://www.phoronix.com/scan.php?page=news_item&px=Glibc-2.32-Released
(Nová verzia vychádza v 1. a 8., mesiaci roka)
4.
Nov 18th, 2019 10:53
MATLAB is a popular math computing environment in use by engineering firms, universities, and other research institutes. Some of its operations can be made to leverage Intel MKL (Math Kernel Library), which is poorly optimized for, and notoriously slow on AMD Ryzen processors. Reddit user Nedflanders1976 devised a way to restore anywhere between 20 to 300 percent performance on Ryzen and Ryzen Threadripper processors, by forcing MATLAB to use advanced instruction-sets such as AVX2. By default, MKL queries your processor's vendor ID string, and if it sees anything other than "GenuineIntel...," it falls back to SSE, posing a significant performance disadvantage to "AuthenticAMD" Ryzen processors that have a full IA SSE4, AVX, and AVX2 implementation
https://www.techpowerup.com/261241/matlab-mkl-codepath-tweak-boosts-amd-...
Addition
How AMD Can Hit This Analyst's Bull-Case Price Target Of $135
BenzingaAugust 10, 2020
Mercury Research's data showed AMD's total server unit share climbed by 241 basis points year-over-year and 68 basis points from the previous quarter, Lipacis said in a Monday note.
AMD's unit share in notebook CPUs climbed 585 basis points year-over-year to 19% and revenue share increased 447 basis points, Lipacis said, citing Mercury Research data.
https://finance.yahoo.com/news/amd-hit-analysts-bull-case-175519439.html
Opakuji... nemuzete rict, ze Bulldozer byl kruto SW nezvladnuty.
SW na fail Bulldozeru nemel vliv. Jakakoli architektura od AMD musi resit to, ze priparne se optimalizovalo na Intel. A to jak architektury pred Bulldozerem, tak i architektury po nem, nebyl v tom nijak znevyhodnen.
Problem Bulldozeru byla exekuce.
>Jakakoli architektura od AMD musi resit to, ze
>priparne se optimalizovalo na Intel
Zatiaľ... Analytici tento mesiac tvrdia, že AMD získa 50% na desktope do 12-18 mesiacov a do 4-5 rok9v na serveroch. cca od 33% na desktope z 20% na serveroch sa začne masívne optimalizovať aj.na AMD..
A áno SW nezvládnutie je chybou AMD a je tradičnou u ATI
11. 12. 2017
Klíčovým problémem situace má být určitý rozpor mezi hardwarovou a softwarovou sekcí grafického oddělení. Hardwarová sekce sice vyvine požadovaný hardware, ale už nezohledňuje, jak složité bude v rámci dané architektury pro softwarový tým zprovoznit všechny její prvky. Výsledkem toho má být spor, podle něhož hardwarový tým z výsledného chování produktu viní softwarové oddělení a to zase poukazuje na komplikace ze strany hardwaru. Podle uvedeného zdroje chystá AMD na příští rok refresh produktů s architekturou Vega, který by měl upravit implementaci některých technologií tak, aby bylo pro softwarový tým možné jejich zprovoznění v širším spektru aktualizací.
https://diit.cz/clanek/vega-refresh-prijde-v-roce-2018
To s Vega je ako "cez kopirák" prípad Bulldozeru.
> před hodinou
>Zatímco Intel vydal mobilní procesor Lakefield využívající kombinace velkého a
>malých jader a chystá generaci Alder Lake, kde i těch velkých bude víc, u AMD
>došlo (teprve) na první patent…
Iste. Ten patent:
Podané 27.10.2017
Po formálnej kontrole zverejnené na podanie námietok a námeitok: 2.5.2019
Vydané ako platný patent: 30.6.2020
http://www.freepatentsonline.com/10698472.pdf
Edit:
A hlavne v tom patente ide o to, ako to urobiť optimálne, Zdieľaná sada registrov vyžaduje viacbránovú statickú RAM a o tom sa doteraz neuvažovalo..
Koncept Little.Big není nezajímavý. Při kancelářské práci (email, word, Skype...) by bylo supr, kdyby celý CPU žral pod 1 W (hlavně u notebooků, že). Při stávající neschopnosti scheduleru ve Win... I kdyby to malé jádro mělo stejně pokročilý branch prediktor jako velké jádro, pořád to nebude schopno udělat tolik instrukcí za takt jako velké jádro. U té kancelářiny to vadit nebude u náročných výpočtu ano.
Ono to casem do toho asi stejne sklouzne, uz jen z duvodu "technickeho modniho trendu". Bez tak casem podpori i "elektricky sporiva EU" nejakou svoji vyhlaskou :D
ALe jinak proc ne, i kdyz ja osobne v tom moc realny prinos nevidim ani u tech notasu.
ps: nejdriv ale bude muset vyjit Windows20 ;)
Já jsem troškař, stačily by Win 10.1 :)
A vy si obaja nepamätáte, že Windows 10 sú poslednými Windows..
Windows 10 jsou poslední Windows!
Datum: 8 května 2015
https://www.techbit.cz/2015/windows-10-jsou-posledni-windows/
Windows 10 jsou "poslední verzí Windows"
8.5.2015
Microsoft samozřejmě neplánuje poslat svůj hlavní produkt do důchodu a nahradit jej jiným. Sděluje nám ale, že po Windows 10 už nebude následovat pravidelné vydávání nových verzí, jako spíše postupné aktualizace podobně jako u aplikací.
https://www.svethardware.cz/windows-10-jsou-posledni-verzi-windows/40434
> A vy si obaja nepamätáte, že Windows 10 sú poslednými Windows..
Ano a ne, pane ministre. Jinak receno, je to marketingovy blabol. Tech verzi je ve skutecnosti vic nez kdykoliv predtim, protoze kazdej "velkej update" je vlastni verze, ktera 2) nema problem udelat nekompatibilni zmenu, a 2) ma vlastni dobu podpory, kdy dostava updaty.
Staci se podivat treba na nektere GPU drivery - verze pro win10 z 2015/16 treba na win10 z roku 2019 nenainstalujete, a verze driveru z poslednich dvou let zase nenainstalujete na ty starsi win10.
Takze defacto Microsoft muze vydat o tri roky uplne jinou verzi woken a porad ji oznacovat "windows 10".
Samozrejme, Viem ,aký je problém so sieťovými tlačiarnami od HP.
na Windows 10 build 1903 idú, na build 1909 nejdú a na build 2004 idú, A HP len minulý týždeň začalo dovoľovať na svoje PC urobiť upgrade na build 2004
Len Windows 20, nebudú , ale bude to Windows 10 build abcd.
https://www.youtube.com/watch?v=sLib5QX9qMw
Takových konceptů už bylo... a spousta z nich se projevila jako neživotaschopná. x86 arch není ARM arch, kde se takové vylomeniny dají páchat poměrně snadno, protože architektura je o dost jednodušší a hlavně historicky nezatížená.
Navíc tvůj požadavek je splnitelný i u "žravých" jader x86, stačí je přece podtaktovat a nedovolit, aby navyšovaly frekvence (což je BTW standardní režim u notebooků, když je přepneš do ecomode.) Výhodou je to, že používáš stále tentýž křemík, není tam režie "zrovna vypnutých" jader a hlavně je zajištěna konzistence instrukční sady a obsahu cache, dokonce není třeba dělat ani context switch.
Navíc zrovna ta kancelařina je v poslední době všechno, jen ne nenáročná. Minimálně Outlook, Skype a můj "oblíbený" nástupce Teams jsou nechutně žravé a starší 2C Intely U-řady dokáží velmi dobře potrápit. U Wordu zase záleží, jak velké dokumenty zpracováváš.
Máš vlastně recht, moderní SW do kanclu je už taky mor. Nám vnutili Teams taky, jede v 8 procesech a žere typicky 1 GB RAM. Zlatý dobrý Lync, než ho MS zprasil na Skype a ted ta Teams sra**a. O Wordu raději nemluvě, nechápu, co tam najednou žere tolik prostředků, když tomu dřív stačilo sotva 100 MB RAM (MSO 2003). Přijde mi, že se zcela přestalo šetřit s pamětí a všechno bobtná a do toho ten bílo-šedý design s občasným jednobarevným orámováním...
Vi nekdo co se presne stane na architekture kde malym jadrum chybi rekneme AVX-512.
Pokud se spusti SW ktery AVX-512 podporuje
1, AVX-512 nebude vyuzivano
2, AVX-512 bude vyuzivano, ale nebudou vyuzivana mala jadra pro dany proces
3, nastane jina situace nez 1,2,
To už záleží na konkrétní implementaci u konkrétního produktu z hlediska jeho výrobce a operačního systému. Zatím to vypadá tak, že pokud budou malá jádra zapnutá, nebude se podpora pokročilého AVX hlásit a tudíž nebude využito. Až pokud dokud dojde k jejich vypnutí, bude možné pokročilé AVX využít. Chtít, aby scheduler Windows uměl rozlišovat mezi jádry s různou výbavou instrukčními sety, je utopie. Jediné co umí, je rozlišovat podle jader na základ dosažitelné taktovací frekvence. Dokud Microsoft nepřijde s novým schedulerem, tak se automatické rozhazování zátěže podle výbavy jader imho očekávat nedá.
> Jediné co umí, je rozlišovat podle jader na základ dosažitelné taktovací frekvence
Tak rozlisovat procesory je trivialni. Akorat vam to pridava "constrainty" na prehazovani mezi jadry - proces ktery pouziva AVX512 nelze prehodit na mala jadra, procesy ktere ho nepouzivaji jde prehazovat libovolne.
Mnohem vetsi problem je, jak zjistite kterej program potrebuje (nebo spis profituje z) AVX 1 / 2 / AVX 512 - tohle neni nikde v binarce zapsano. Sice 1) nektere programy maji natvrdo AVX instrukce nekde v instrukcnim streamu (jenomze by jste musel dekodovat binarku aby jste to zjistil), ale pak jsou 2) dynamicke programy ktere se za behu zeptaji CPU schopnosti a pak pouzijou patricnou dostupnou verzi SSE / AVX / 2 / 512, a pak jsou 3) programy ktere za behu generuji kod (JIT) - tady nezjistite nic ani dekodovanim binarky... a rekl bych ze 99% programu spada do kategorie 2. Treba samotne glibc dnes dela detekci CPU featur hned jak se program spusti.
> Dokud Microsoft nepřijde s novým schedulerem, tak se automatické rozhazování zátěže podle výbavy jader imho očekávat nedá.
Pokud mate ruzne instrukcni sady, tak vam sebelepsi scheduler nepomuze. Jak jsem psal v 2) neexistuje zadnej spolehlivej zpusob jak zjistit co program potrebuje. Takze tenhle zazracny scheduler bych neocekaval vubec.
Celej tenhle problem ma mnohem jednodussi reseni, zrovna to ktere pripravuje Intel, a ktere udelalo AMD u prvnich Ryzenu: implementovat "vyssi" AVX pomoci "nizsich". Sice by pak to "vyssi" AVX bezelo na malych jadrech mnohem pomaleji, ale problemy s instrukcni sadou jsou fuc.
> implementovat "vyssi" AVX pomoci "nizsich". Sice by pak to "vyssi" AVX bezelo na
> malych jadrech mnohem pomaleji, ale problemy s instrukcni sadou jsou fuc.
Tohle by ale podle me zpusobilo uplny shitstorm negativnich recenzi a prisernou PR nocni muru pro AMD. Dotazy jako: "proc mi najednou program temer zamrzl" by byly bezne.
tak beh AVX512 na pomalšom AVX2 je stále rýchlejší ako bez AVX...
Co který proces potřebuje, se dá zjistit relativně snadno. Pokud dojde k invalid opcode exception, tak se stačí podívat na to, která instrukce to způsobila, a poznačit si u toho procesu, že tyhle instrukce potřebuje, a přeplánovat ho na správné jádro. :-)
Problém je, že třeba glibc používá i pro běžné funkce jako memcpy/memmove nejvyšší dostupnou verzi AVX, takže by pak na těch malých jádrech asi nemělo co běžet.
v dobach DOSu pokud neco bylo zkompilovano treba pro 80486-ku, tak to na 386 jednoduse spadlo.
Dnes programy obsahuji nekolik bloku a >predpokladam< behem natazeni do pameti se prenastavi pointery na exekucni bloky tak, aby to behalo na danem systemu.
Nejaky aktivni C++ programator by mozna mohl neco o tom rict vice.
Dale propokladam, ze tohle prenastaveni probiha na zaklade nejakeho syscallu ktery vrati ktere instrukcni sady jsou podporovane na danem systemu.
Pokud ten syscall je vubec schopen vratit protichudne informace (AVX512 je, AVX512 zaroven neni) - tj. info pro kazde jadro zvlast, pak program ma 2 moznosti a pokud zacne pouzivat instrukce s AVX512, tak to pravdepodobne povede k padu pokud se ten kod dostane na male jadro ktere AVX512 (nebo cokoliv jineho) nema.
Mam pocit ze je pekna "can of worms", ale zaroven se mi nechce verit, ze by to neko implementoval, aniz by to bylo osetrene/domyslene.
Pokud program jednoduse pojede bez AVX512 i na velkych jadrech, protoze >se muze< dostat na jadro ktere to nepodporuje, pak tedy Hi5 a strcte si to za klobouk.
Proste to ve mne vzbuzuje maximalni neduveru..
Bohužiaľ to nejde
"Dale propokladam, ze tohle prenastaveni probiha na zaklade nejakeho syscallu ktery vrati ktere instrukcni sady jsou podporovane na danem systemu."
ale podľa cpuid, a len podľa toho, čo daná knižnica podporuje intel MKL podporuje len Intel CPU a konkurenciu degraduje na in3trukcie pre Sandy Bridge , glibc, zatiaľ, rovnako.. viď môj príspevok so slovom Matlab vyššie
A ak by sa nastavila afinita?
Nevím (nechce se mi číst), jestli to tu někdo už nepsal, ale procesor jako celek bude inzerovat veškeré svoje schopnosti do OS, nebude to dělat po jádru. A bude na jeho triku (tričku), co potom s těmi voláními udělá. Např. pokud na malém jádře zavolá proces AVX-512 v nějaké větší opakující se míře, scheduler toho jádra dá interní událost "toto vlákno po mně chce moc AVX-512, prosím kdo má čas z velkejch bráchů, vemte si ten proces". Jinými slovy, nepředpokládám, že ve firmě vyrábějící procesory jsou větší idioti než v Microsoftu. A to je jen jedna z možností, jak to řešit.
Pokud resime kombo procesor, kde velka jadra AVX-512 umi a mala neumi. Takovy procesor by pri zapnutych malych jadrech mel aplikaci hlasit, ze AVX-512 vubec neumi.
V aplikaci pak muze nastat:
1 ) aplikace AVX-512 podporuje, ale umi zit bez nej. Osaha si co procesor podporuje, zjisti ze AVX-512 tam neni a tak pobezi kod bez jeho podpory.
2 ) aplikace AVX-512 vyzaduje. pokud je spravne napsana, tak nahlasi ze procesor neumi vyzadovane instrukce, nahlasi to uzivateli a ukonci se. pokud neni spravne napsana, tak padne na hubu diky volani neexistujicich instrukci.
Tím říkáte, že celý procesor degradujete a zahodíte AVX. Řešení to sice je, ale tím zahodíte i znatelnou část výkonu a z toho uživatelé nebudou nadšení.
Ja se vsadim, ze to tak intel u toho sveho procesoru vyresil. On by jakykoliv jiny zpusob vyzadoval aktivni spolupraci operacniho systemu. No a jelikoz se nic takoveho neobjevilo ani tam, kde si to intel muze napsat sam...
Tenhle koncept je pěkná nepoužitelná kravina. Když s tím přišel Qualcomm, zkoušel jsem 820 a 835 a ta 820 prostě byla plynulejší a na baterce se to nijak nepodepsalo. Stejně tak u 810 jsem pozoroval, jak je to příšerně línej ten mobil, tehdy jsem tam měl root, tak jsem tomu vypnul všechny ty malý jádra až na jedno a celej mobil se podstatně zrychlil, výdrž byla stejná. Jak už padlo výš, chápal bych, kdyby udělali X jader, z toho Y by mělo menší cache, to dává smysl. Ale dávat tam naprosto jiný obvody na všechno, to je nonsense a fungovat to nebude, nemluvě o tom, že Win scheduler má doteď ve všem pořád chaos. Nicméně kdo ví, třeba ta malá jádra nebudou nic jinýho, než 16xALU, to potom bude fičák a velký jádra nebudou stíhat.
Diky za podeleni se o prakticky zazitek. Papir snese vsechno, ale rozhodujici je jak se to prakticky chova..
ono taky záleží na tom, jak se s daným zařízením pracuje. Pokud na něm běží od rána do večera nějaká komunikující aplikace, pak budou úspory mizivé, protože nejvíc stejně sežere rádio a displej a CPU bude vytížený tak jako tak.
Pokud se ale bude používat jako hloupý telefon (a UI bude úporně kleštit všechny na pozadí běžící appky), tak by provoz/využití malých jader smysl dávalo... je to tak trochu hodně jde proti filozofii smartphonu. U PC si to ale představit moc nedokážu, protože tam toho typicky už na úrovni Windows běhá neskutečně mnoho, k tomu navíc jde o náročnější a komplexnější aplikace, takže nízký výkon bude znamenat jediné - delší dobu běhu a energie se tak spotřebuje +/- stejně jako kdyby výkonnější CPU běžel sice s vyšší spotřebou, ale po kratší dobu.
:-D
V podstatě empirické potvrzení toho, co píšu výše. :-D
> Nicméně kdo ví, třeba ta malá jádra nebudou nic jinýho, než 16xALU, to potom bude
> fičák a velký jádra nebudou stíhat.
ALU zerou hodne. A 16xALU by bylo hodne plnotucne jadro. Aby se tech 16ALU rozumne nakrmilo, byl by potreba hoooodne velikej frontend pred nima.
Na cem by se dala usetrit plocha je IMHO cache. Napr. ulohy ktere profituji z operace nad registry a malokdy vyuziji velkou cache by bezeli na mensich jadrech a zbytek na vetsich.
Spíš je to tak, že všechny úlohy běží přes registry CPU, ale některé vyžadují přístup k velkému objemu dat a dostatečně velká cache jim umožňuje, aby nebyly až tolik brzděny pomalou RAM. Menší cache způsobuje nutnost častějších přístupů do RAM a častější prostoje procesoru (starving). Obchází se to vykonáváním instrukcí mimo pořadí a spekulativním vykonáváním, ale i ty mají své limity a výrazně profitují z instrukční cache.
Paměťových sběrnic je velmi omezený počet daný počtem paměťových řadičů, kanálů a osazených DIMM modulů, a jsou sdíleny všemi jádry (nebo komplexy jader). Čím víc jader si nevystačí s vlastními cachemi, tím větší boj o přístup do RAM nastává a tím pomaleji jedou.
Vypni/zakaž všechny cache v procesoru a výkon ti spadne na jednotky procent...
To je taková kravina. Musíme šetřit každý mm plochy křemíku? Tak můžeme začít u cache, která narostla nechutně a v APU není tolik potřeba. A u chipletů je její potřeba v případě použití big-little taky diskutabilní. Takže jen přiblblý marketing pro idioty.
Ať se soustředí na GPU a malá jádra nechají v PS4.
Velikost cache je důsledek rozdělení na čiplety. AMD může cache zmenšit a vrátit se k monolitům, ale bude na tom jako Intel nyní. Možná nemám ten správný pohled na věc, ale nepřijde mi to jako žádoucí cesta.
Za to můžou lidi a i tady jich je spousta.
Intel tvrdí 10+ let že 4 velká jádra na 80 W TDP stačí každému a pak ho donutíte udělat 10 jader na 250 W TDP a brečíte že je to moc. Tak to zase někdo přijde zachránit malými jádry. Pak se zjistí, že to nedělá dobrotu a budou se zase dělat jen velká.
Je to přesně toto: “A tak se pan Šustr z Ronova nad Doubravou zamyslel a spočítal, že normální konev má 117 otvorů v tom kropítku, a že je to škoda, a udělal do něho pouze 13 otvorů..Už to funguje na té konvi, konev šetří vodou..“
Cest řešení je několik:
A. s podporou OS, ale bez podpory uživatelského SW
- malá jádra budou mít stejné vybavení, ale budou jen jednovláknová (ušetřím trochu prostoru vypuštěním podpory druhého vlákna včetně zmenšení všech vyrovnávacích pamětí), poběží na fixní frekvenci v optimu výkon/spotřeba a řízení spotřeby bude zjednodušeno jen na stav aktivní/neaktivní (tedy i bez řízení napětí jádra) ... odhadovaná úspora plochy cca 30%; všechny procesy poběží primárně na těchto výkonově optimalizovaných jádrech, ale uživatel je bude moci v rámci nastavitelného výkonnostního profilu přesunout na velká jádra (profil by měl být přenositelný a může obsahovat seznam standardních aplikací s nastavením); ještě lepší by bylo doplnění ovládacího prvku do rámu okna aplikace
B. s podporou OS i uživatelského SW
B.1. shodně jako varianta A., ale s podporou v API pro přesun vlákna aplikace na velké jádro a zpět
B.2. API s podporou pro alokaci zdrojů, ale nejen paměti (a případně i periferií), ale i specializovaných jednotek CPU (případně i GPU); starší verze programů by pracovali jen se základními jednotkami (případně by se dalo v profilu nastavit, jaké SKU bude aplikaci prezentováno s ohledem k dostupným zdrojům; jejich alokaci i dealokaci by pak musel dělat OS)
...a asi by se našly i další
Já bych řekl, že ta úspora křemíku/snížení nákladů platí jenom do určité velikosti čipu. Pokud totiž máte čip se stejnou instrukční sadou, tak jsou prostě určité části, které tam být musí, jsou kritické pro fungování a jakákoliv chyba v nich znamená, že je procesor nefunkční. A u méně komplexních návrhů zabírají tyto části procentuálně větší plochu čipu. A protože chyby se vyskytují náhodně na celé ploše wafferu, tak s menším procesorem roste riziko, že bude v některé z těch kritických částí a čip bude na vyhození celý. I pokud je chyba v nekritické části čipu, tak u komplexnějšího návrhu máte možnost poškozenou část vypnout a čip stále použít do levnějšího výrobku. Třeba u osmijádrového čipletu i při chybě ve dvou jádrech máte pořád šestijádrový křemík, u dvojádrového máte smůlu. Navíc dle starších údajů mělo AMD na tehdy relativně novém 7nm procesu 80% plně funkčních čipletů z wafferu. Velká část z těch zbylých 20% šla určitě použít, plně nefunkčních čipů muselo být strašně málo. Je otázka, jestli by další zmenšování čipletu stále za tu výkonovou penalizaci, kterou by to přineslo..
Vezmime si koncept jadier 8 + 8, ktoré dokážu spolu na dosiahnuť efektívne kooperovať pokiaľ pracujú s rovnakou SIMD a potom je výkon / efektivita veľkého + malého jadra vyššia (rozumej úplne niekde inde) ako pôvodný koncept veľkého jadra s HT.
A to nehorovriac, že pôjde samozrejme (hlavne) aj pri rôznych možných kombináciach šetriacich režimov a vypínania veľkých / malých jadier.
Ak sa to Intelu naozaj podarí, v spolupráci s Microsoft Windows schedulerom môže to byť zásadný prielom vo výkone / efektivita aj na horšom výrobnom procese (litografii) nie to ešte na zrovnateľnej alebo lepšej.
Osobně nevěřím, že je toto schůdná cesta pro cokoli jiného, než mobilní zařízení s minimální spotřebou (a minimálním výkonem, jak se podle výsledků existujícího Lakefieldu zdá).
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.