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.
vazeni, tak takto vypada import big-MidDle-LITTE idei z ARM do sveta x86 v podobe 5-jadroveho intel paskvilu, skratka iba dalsi mega-fail
LOL, i moje retro kousky Ivy Bridge na 22nm a AMD FX na 32nm umí aspoň to AVX. Absenci AVX-512 a blbého HT bych u podobných mrzáků (kdyby byli aspoń za hubičku) v pohodě přešel, ale tohle je další flusanec do tváře co i ze starého šrotu dělá pořád dost dobrý kus HW. Jsem rád, že AMD malá jádra zařízlo a ARM se na podobnou úroveň nesnížil. Nejblbější produkt roku o kousek před desetijádry s reálnou spotřebou 250W.
pozor, iba 230W :)
můj retro to taky má
Intel® SSE4.2, Intel® AVX
i7-4820K
To moc retro není zatím :D
i7-4820K je furt v klidu, i na RdR2.
swan: proc jsou velky jadra lepsi..
vyvoj: protoze zvladaj vetsi takty, pokrocily instrukcni sady a podporujou ht..
swan: a co potrebujete abyste je mohli dat do supermobilnich 7w chipu?
vyvoj: snizit takty, vypnout pokrocily instrukcni sady a vypnout ht..
swan: makes sense, schvaluju prachy na vyvoj a vyrobu, dete do toho..
ked pred Vianocami 2022 pride Zen4 s USB4, 5nm EUV TSMC, DDR5, PCIe5 a AVX512 (+ opat o par % vyssie IPC ako chystany Zen3 a mozno viac jadier ale to neni iste), skutocne netusim co musi vytiahnut Intel, aby to uplne prevalcoval (aj ked ono pravdu povediac Intel uz 3 a 1/4 roka na poli CPU nevalcuje nikoho a nic, prave naopak) ...
napr. tie slajdy si nerobili srandu a hovorili jasne: najvykonnejsi "desktopovy/HEDT" 1-socketovy x86 CPU na platene pre rok 2020 (TR3 3990X), i ked mozno bude uz v 2020 existovat vykonnejsi 1-socketovy Epyc CPU Zen3
Pokud Tiger Lake dopadne alespoň zčásti tak, jak se tváří (pokud tedy nejde o řízené leaky v aplikacích, kde se mu nadprůměrně daří a v testovací platformě chlazené kilem mědi), tak na tom Intel není zdaleka tak špatně, jak by se mohlo zdát.
jo tigrovite jazero je fajn - zislo by sa aby nieco nove uz vystriedalo v desktopoch nebove jazero z roku pana 2015
Až na to, že to nepoedal Swan(labuť), ale Greylish(šedé čosi)
Software needs meaty cores, not thin, stringy ARMs, says Intel
By Simon Sharwood, 26 Feb 2014
“The world has a big issue around vectorisation and parallelisation of code,” Graylish said. “99% of code isn't written that way.” Graylish also feels “defining a workload that can run in 1000 cores is hard.”
Most software, Graylish added, “still requires a big meaty core” and Intel is happy to provide them.
https://www.theregister.com/2014/02/26/software_needs_meaty_cores_not_th...
Clovece, ty si fakt robot :D
Nedokazal si pochopit tak jednoduchou vec. Ty bys ani Turingovym testem neprosel.
Čo konkrétne máte ns mysli. S tou paralelizáciou, a ktorú ide sme sa veľmi dodnes nepohli. S to bola teoreticky dopracovaná Dijkstrom roku 1965.
Edit: To, že ste použili nadsázku som pochopil.
A ARMy AVX už umí když mají být tou zářnou budoucností co x86 nahradí?
Samozřejmě, a to včetně AVX-640 a 8x ALU, již brzy v Apple A14XT
Mohl by někdo to AVX převést například na rychlost Fabie ? Nějak si to neumím představit :)
Na tak to je veľmi jednoduché prirovnanie - AVX je podmnožinou tzv. SIMD (Single Instruction Multiple Data) inštrukcíí, čiže pri klasickej inštrukcii vykoná jeden vodič jednu cestu jednou Fabiou za jednotku času. Pri použití AVX vykoná ten jeden vodič viacero ciest viacerými Fabiami za tú istú jednotku času.
Úplne zrozumiteľné a dobre predstaviteľné! Alebo žeby nie? :-)
spíše jde o to, že "polovodič" nenaloží do Fabie 4 pasažéry, ale 8 a cestu Praha-Blava jede jen jednou, místo aby jel 2x, pokaždé jen se 4 pasažéry. Celková rychlost přepravy 8 lidí je tak poloviční, i když maximálka Fabie překročena nebyla. :o)
Ten dotaz byl spis vtipek, necekal jsem, ze na to nekdo reaguje.
Kazdopadne diky, pobavilo :)
A pri AVX-512 je tých pasažierov 16?
Ježišmarjá, začínám panikařit a prodávat akcie...
A treba ich?
AMD Zen,Zen+(Zen1.5) ani Zen2 ich poriadne SW nevyužívajú, aj keď AMD na tom pracuje
Ja viem, pre danú architekúru neoptimálny kód znižuje výkon aj o 50% (AMD K8 optimized kód na Inteloch) alebo o 12% (Intel optimized code na AMDK8)
https://www.pgroup.com/lit/presentations/pgisc06.pdf
A AMD v glibc (Linux aplikácie a iné OSS aplikácie) ide stále na kóde bez AVX2 aj pre Zen2.
A tak zle urobená vec ako glibc(podľa citátov, efektívne kriplí výkon AMD) je stále o 10% rýchlejšia ako knižnice a plánovače MS Windows
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...
AMD Working With GNU Developers To Provide More Robust Runtime Detection For Better Performance
Written by Michael Larabel in AMD on 4 May 2020
The patches from AMD in March provided better run-time detection for CPU features like AVX2 and could allow making use of more optimized code-paths at run-time when run on such hardware, similar to Intel Glibc optimizations for Haswell and newer.
https://www.phoronix.com/scan.php?page=news_item&px=AMD-GNU-Discussing-B...
Glibc-HWCAPS To Help With AMD Zen Optimizations, Other Per-CPU Performance Bits
Written by Michael Larabel in GNU on 7 July 2020
Experimental patches under discussion for the GNU C Library (glibc) would make it easier to dynamically load optimized libraries (shared objects) on systems depending upon the CPU in use and its hardware capabilities. This glibc-hwcaps work stems from the desired work on being able to better leverage Linux performance optimizations on AMD Zen-based system
He began this patch series stemming from the work on the bug/issue around providing better optimized AMD Zen support by potentially following Haswell optimizations rather than a more generic target.
https://www.phoronix.com/scan.php?page=news_item&px=glibc-hwcaps-RFC
Aktuální verze Windows 10 doznala zlepšení výkonu Threadripperů
3. 12. 2019
U minulé generace Threadripperů s 24-32 jádry klesal výkon pod Windows v důsledku scheduleru, který neuměl s procesorem správně zacházet, až na polovinu výkonu, kterého bylo možné dosahovat v Linuxu. Testy ale ukázaly, že v případě Threadripperů 3000 už Windows 10 za Linuxem nezaostávají tak výrazně, jako u předchozí generace
Pokud zprůměrujeme výsledky z grafu, vyšlo by nám, že s aktuální verzí Windows je výkon v průměru o 5 % vyšší, což není k zahození (není to tak dlouho, co 5 % procesorového výkonu navíc bylo považováno za mezigenerační posun).
Čistý Linux zůstává pro nové Threadrippery o 10 % rychlejší
https://diit.cz/clanek/aktualni-verze-windows-10-doznala-urciteho-zlepse...
AMD: Nejlepší jádra v Ryzen Master nemusejí být nejlepší pro scheduler Windows
22. 11. 2019
Pouze tímto způsobem totiž může AMD přimět scheduler Windows k tomu, aby v rámci možností využíval primárně jádra v jednom CCX (aby nedocházelo ke ztrátě výkonu v důsledku přesouvání dat mezi jádrem v jednom CCX a segmentem L3 v jiném CCX). To totiž z důvodu přehazování zátěže schedulerem Windows musí mít vyšší prioritu než použití skutečně nejlepšího jádra.
Scheduler Linuxu zátěž nepřehazuje (pokud o to vysloveně není požádán), takže žádné z výše popsaných krkolomností není potřeba provádět a při jednojádrové zátěži lze kontinuálně využívat skutečně nejlepší jádro v procesoru a výkonnostně a/nebo energeticky z toho profitovat.
https://diit.cz/clanek/nejlepsi-jadra-v-ryzen-master-nemuseji-byt-nejlep...
Situace se bude měnit, já bych si nové CPU bez AVX nekoupil ani před 3 roky. CPU má vydržet co nejdéle (i když to třeba já osobně nevyužiji) a stát co nejméně, takže tenhle převléklý Atom je čistý odpad. Jeho kupci dělají jednoznačně chybu.
A ARMy AVX už umí když mají být tou zářnou budoucností co x86 nahradí?
ARM má něco lepšího než AVX. RISC-V taky.
ARM má Neon nebo SVE, možná je toho ještě víc.
Když to takto zpětně popisujete dává to smysl. Jen mě překvapuje, že toto nikoho v Intelu nenapadlo už při samotném nápadu na tento produkt, že by to nemuselo překonat ani jejich starší mobilní čipy. Drahá zbytečnost, asi exponát do muzea kuriozit.
Oni by Intel (tak isto AMD) musel na trh niečo uviesť, aj keby vedel, že je to nepodarok.
Vývoj x86 CPU trvá približne 4,5 roka to je 20 kvartálov. naraz sa teda vyvíja 5 architektúr. Takže do vývoja toho dali asi 4 kvartálov nákladov na vývoj.
AMD dávalo zhruba 500 mil. USD/kvartál na vývoj. To sú 2 mld. USD na vývoj čipu.
Ak máte nepodarok, tak máte 2 možnosti
1. Neuvediete ho a odpíšete 100% ceny za vývoj
2. Uvediete ho, predaj bude relatívne malý, ale aspoň časť nákladov na vývoj si uhradíte a teda minimalizujte finančné straty na úkor goodwillu.
Jde o to, že tuhle základní vlastnost museli vědět už na začátku vývoje. Je to tak blbá chyba, že tomu ještě úplně nevěřím.
Tak aj AMD muselo vedieť, že potrebuje optimalizáciu kódu pre asymetrické Bulldozéry a Toto začal Intel vyvíjať pred žalobou na AMD za Bulldozer (obávama sa, že Intel hrozí niečo podobné) Ak by Intel urobil online glibc.HWCAPS, nemusel by toto riešiť.
https://en.wikipedia.org/wiki/Bulldozer_(microarchitecture)#/media/File:AMD_Bulldozer_block_diagram_(CPU_core_block).png
AMD čelí žalobě: Bulldozer prý není osmijádrový procesor
9. 11. 2015
AMD stojí před obviněním z nekalé reklamy, když procesory FX-8000 generace Bulldozer propagovala jako osmijádrové. Žalující strana totiž tvrdí, že osmijádrové nejsou.
https://diit.cz/clanek/amd-zazalovana-za-osmijadrovy-bulldozer
Glibc-HWCAPS To Help With AMD Zen Optimizations, Other Per-CPU Performance Bits
Written by Michael Larabel in GNU on 7 July 2020
Experimental patches under discussion for the GNU C Library (glibc) would make it easier to dynamically load optimized libraries (shared objects) on systems depending upon the CPU in use and its hardware capabilities. This glibc-hwcaps work stems from the desired work on being able to better leverage Linux performance optimizations on AMD Zen-based system
He began this patch series stemming from the work on the bug/issue around providing better optimized AMD Zen support by potentially following Haswell optimizations rather than a more generic target.
https://www.phoronix.com/scan.php?page=news_item&px=glibc-hwcaps-RFC
Tenhle produkt je urcite nejaky blaznivy pohrobek mobilni divize, ktery nekdo omylem zapomnel zrusit a usetrit tak miliardu USD ;-). Nebo vazne vsem v Intelu uplne preskocilo.
Kdyby to mělo odpovídající cenovku, bylo by to pro androidí sra*ky dobré, tam o AVX taky ještě neslyšeli. Jinak když Atomy nemají AVX, tak to jinak asi nešlo. Zajímavé je, že právě bokovka Intelích inženýrů v open source "divizi" si loni pohrávali s aktualizací Androidu na chrombooku pro AVX2 a výsledky byly zajímavé. Jenže tam šlo o využití plného potenciálu už existujících procesorů, se kterými Android neuměl pořádně pracovat.
https://www.phoronix.com/scan.php?page=news_item&px=Intel-AVX2-Chromeboo...
https://01.org/blogs/2019/improving-android-application-performance-chro...
Já bych si i tipnul, že to velké jádro tyto instrukce mít bude, jen o nich CPUID prostě neinformuje (nebo jsou úplně vypnuté). A i kdyby informoval, z principu preemptivních OS by to bylo kontraproduktivní. Člověk by si mohl říct, ať Intel dovolí SW běžícímu na velkém jádře AVX použít, a na malých jádrech ne, to ale není tak jednoduché.
Žádný software nevolá CPUID pro každé HW vlákno/jádro zvlášť. A jsou-li AVX(2) instrukce k dispozici, pak v běžném kódu kdejaká blbá funkce, která potřebuje zkopírovat pár bajtů odněkud někam, použije raději jednu AVX než dvě SSE (či hromadu MOV, etc). Pokud je malé jádra, Atomy, nemají, řešením, pokud by tedy CPUID informoval o instrukcích dostupných na velkém jádře, by mohlo být, že OS na Illegal Opcode přerušení přesune vlákno na ono velké jádro ...ale sama taková operace zabere tisíce cyklů, děla by se neustále, a prakticky by vymazala (či hůř) jakýkoliv přínos, který provádění operací na pozadí na malých jádrech má.
Apropo, někde jsem četl poznámku, že tohle CPU nakonec různé CPUID na různých jádrech vrací, jen ne jak bychom si představovali, a opět, nelze je spolehlivě užít v usermode. A moc si nedovedu představit, jak by se měl v takovém případě OS vlastně chovat.
Ono by to stačilo volať ako obslužnú funkciu SIGCONT resp., aby to volal plánovač pri obnovovaní stavy procesu pri prechode do stavu RUNNING
Souhlasím, dát dohromady více jader s různými instrukčními sadami by mohlo dělat spoustě SW potíže, tak to Intel prostě vyřešil takhle. Dost možná to bude v budoucnu softwarově vyřešitelné i na tomhle hardware.
Ja neverim, ze tohle bude mit reseni.
Pro OS by to muselo byt transparentni, cili nejaky specialni radic/planovac primo v cipu (mozna neco podobneho jako wave scheduler/command procesor u AMD grafik), ktery by zaridil, ze pro konkretni instrukce se to prehodi na jadro schopne je obslouzit. Neco jako tedka kdyz se vybere konkretni ALU, ktera dokaze obslouzit specifickou instrukci.
Ale zaroven verim, ze tohle by otevrelo neuveritelne velkou branu pro skodlivy kod.
Jsem si docela jistý, že Linux už různá jádra s různými instrukcemi zvládá teď. Na Heterogeneous Multicore Processor mi Google najde s Linuxem spoustu výsledků.
U Widlí je to daleko horší, tam si výrobce nějakého obskurního big.LITTLE procesoru (což kdysi dávno u ARMu tak bylo) těžko podporu dodělá.
Zajimave.
Ja dotedka myslel, ze big.LITTLE ma porad jednu a tu samou instrukcni sadu pres vsechny jadra, akorat navrh pocita s tim (napr. delka pipeline, specialni cache aby se vyporady s frekvencnima domenama, ...), ze ty male pobezi na mnohem mensich taktech a tedy nebudou tak zrave.
Tohle už tu bylo, to měl Buldozer od AMD, ale pak mu neuznali, že to jsou dvě jádra.
Bulldozer mel neco jineho.
Bulldozer mel podobne reseni jako nektere Power procaky od IBM scheduler vytahnuty pred minijaderka. Ale fakticky ten modul byl jadro. Choval se tak, nemel jine instrukcni sety, choval se navenek uplne stejne jako jadro od Intelu. Proto je zazalovali.
AMD tvrdilo, ze "jadro" muze byt i jen nekolik ALU, nebo FPU bez jakekoli dalsi ridici logiky (ta byla vytazena prave pred ne do toho modulu), takze AMD tvrdilo, ze ma 1 modul, 2 Int jadra. A v jedne konkretni konfiguraci (top model) 4 moduly -> 8 jader, takze jsou super-duper pred Intelem, zatimco Intel mel tehda 4 jadra s HT.
V každém případě měl logiku, která musela poznat, které vlákno potřebuje FPU instrukce a poslat je tam. Tady by to muselo být stejně. Jeden scheduler, který by všechno obsluhoval.
Nic nebrani tomu OS si zapamatovat, ze pro dany thread/proces ma pouzivat velke jadro, protoze je to AVX. Prakticky by to znamenalo pak jen nejake prechodne obdobi se snizenou vydrzi na baterii, nez se tvurci mixovanych aplikaci nauci delit sve thready na lowpower(avx-free) a highpower (avx++).
No jak by se řeklo, ještě horší než jsme čekali...
Opravdu má smysl, aby vůbec něco takového vzniklo? Nebylo by lepší vzít nějaké ULV úsporné dvoujádro s HT na nižší frekvenci + jedno jádro s jinou technologií umožňující brutální maximální frekvenci pro kratší jednovláknové úlohy, něco na způsob BIG.little u ARMu? Teď se totiž opět ukazuje, že celý Atom ve všech variantách byl a je k ničemu. Kromě známého umírání např. v NASech tak ve všech ostatních případech přináší uživateli v každé inkarnaci jen další problémy.
Intel to ukrutně zmatlal o tom není pochyb. A o tom co se psalo o tehdejším jejich řiditeli - soustředili se evidentně pouze a jen na ždímání peněz z vyžilé Core architektury.
Takže AMD po určitém úsilí je za hvězdu. Přitom ten vývoj od počátku mohl probíhat mnohem zdravěji nebýt faktického výpadku AMD v úloze konkurence - kdyby spolkli hrdost tak nemuseli mít ztracená léta a utíkat doslova hrobníkovi z lopaty. Jenže pustit Jensena ke kormidlu společného podniku to ani náhodou. Nyní se ukazuje že ti co viděli budoucnost ve spojení s NV měli pravdu - viz poslední finanční údaje kdy Nvidia překonala Intel. Zároveň by se zachovala identita ATi která dřív byla velice progresivní v implementaci nových DX.
No nějak se zapomnělo na to, že Intel zkur*** trh porušováním hospodářské soutěže (a odsouzen), nicméně škody byly napáchány a žádná ex post pokuta už nic nespraví...
wow, tak to teda nechápu jaká je cílovka. Asi nějakej podmáznutej nákupčí s iq rozzuřeného rotvajlera.... protože jinak nevim kdo by o tohle vůbec měl zájem.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.