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.
Pak se nemusíme divit, že je Intel ochoten HT vypnout, aby se systém/program nezbláznil z rozdílných schopností P(ower)-cores a E(conomy)-cores. Nejspíš to bude něco podobného i s AVX512...
jenže Intel SMT je uspornější než AMD, které sice více přidává výkonu, ale zároveň i o dost zvyšuje spotřebu
https://www.hardwaretimes.com/hyper-threading-on-intel-is-more-efficient...
ke smůle Intelu, jsou díky jejich výrobnímu procesu a frekvencím hnaným na krev jejich CPU zravější než AMD a tak se ten rozdíl v SMT smazává ...
To je nepochopení situace. Pokud je spotřeba Intelu s HT i bez HT prakticky stejná, pak to ukazuje, že Intel není schopný šetřit energii na nevytížených jednotkách. Spotřeba u AMD je totiž proti Intelu bez HT třetinová a s HT méně než poloviční.
@No-X: a jaké jednotky přesně ten Intel procesor nevypíná nebo na kterých neumí šetřit?
Z toho co vím jak funguje hyper threading (SMT) je jasné že se pouze stará o lepší utilizaci všech dostupných prostředků, které vlivem "bublin" v pipeline při zpracování x86 kódu vznikají, ale to neznamená že jsou vypnuté, pouze nejsou využité naplno. SMT dělá to, že se snaží tyhle "bubliny" eliminovat a chytře rozdělovat zátěž na další "virtuální" vlákno. Vypnutím SMT jen přestane docházet k tomu "extra" přerozdělování, ale jinak se v CPU zpracovává vše stejně.
IMHO ta vyšší spotřeba Intelu rozhodně není daná tím, že by neuměl šetřit energii nebo měl horší power.management než AMD, problém je jak jsem už napsal v použitém výrobním procesu a v tom, jak jsou ty CPU hnané na krev, tz.rvou tam větší napětí a tím stoupá i spotřeba ( ale také dosažitelná frekvence a výkon)
„které vlivem "bublin" v pipeline při zpracování x86 kódu vznikají, ale to neznamená že jsou vypnuté“
Bubliny jsou jeden případ, ale stejně tak mohu mít kód, který třeba vůbec nevyužívá FPU. A pokud během bublin (nebo kontinuálního nevyužití) dokážu FPU poslat do režimu se sníženou spotřebou, ušetřím energii. V okamžiku, kdy dojde na HT/SMT a druhé vlákno FPU vytíží, je FPU aktivována a spotřeba se zvýší. Pokud je spotřeba stejná bez ohledu na to, zda je HT/SMT zapnuté, pak jasně vyplývá, že Intel není při jednovláknové zátěži schopný šetřit energii na nevyužitých částech jádra.
A to nehovoríte o tom, že FPU nie je v jadre jediná ale sú ich tam, 3-5 kusov. A Pokiaľ nie som schopný vyťažiť viac ak 3, tak si 2 vypnem.
NO-X: a proč si myslíš že Intel neumí uspat FPU a AMD ano ?
Myslím, že už jsem to napsal v článku i v diskuzi, ale zopakuju to. Nejde konkrétně o FPU, ale obecně o úsporu energie při nevyužití částí jádra (FPU byl příklad) a vyplývá to z toho, že Intelu téměř neklesá spotřeba, pokud z vyššího vytížení jádra (HT) přejdeme na nižší (bez HT), kdy jsou vytížené jen některé části jádra a většinou ještě ne kontinuálně (=ony bubliny).
a já se ptám, které části to jsou a jak konkrétně se vypinají, odpoveď jsem nedostal.
A tohle vypínání nevyužitých části soc sama AMD označila za budoucí prioritu pro zlepšení architektury, které byl při vydání power managment nejvíc vyčítán. Od Zenu 1, kdy položili týhle architektuře základ, tak měli představu kam jí směřovat, nejspíš už na to předem mysleli když jí vyvíjeli, a je hezký vidět že to byla šťastná volba. Přidali spousty čidel už i u Zen1+ a tehdá už ladili i 3D cache, což je v tý době s prostředkama co měla AMD, v tý době skoro neuvěřitelný, museli tomu produktu hrozně věřit a vsadili na to všechno. Celý to vlastně financovala grafická divize AMD, která v tý době byla jediná zisková. Na to spousta lidí zapomíná, když na ní teď nadávají. A obrovská odvaha Lízy která to nechala projít. Místo aby ždímala co bylo (konzole, grafiky a pár embbed strojů, a zakázky pro Saúdskou vládu), což je méně rizikové, tak tomuhle nevídanýmu projektu dala zelenou. Je vidět že měli koncept a drží se ho. Chtěl bych vidět nadšení inženýrů, když se jim po době FX podařil nakopnou první vzorek Zen a poprvý mohli změřit, jak se jim to povedlo.
Stačilo by málo, a AMD by bylo dnes něco jako jejich bejvalý továrny kterejch se zbavili přesně za v času, a díky tomu zahájili restrukturalizaci, a začali tlačit HSA, tohle sou plody toho rozhodnutí, i když ze začátku nebylo využití a nechytlo se to jako celek, nejvíce to skončilo na software kterej nebyl připraven na "ZMĚNU PARADIGMATU" v programování využití prostředků a optimalizace pro širší HSA APU, místo toho se přistupovalo stejně jako kdyby to bylo sólo CPU a GPU a nevyužívali výhody, naopak nutili to běhat jinak než to bylo navrženo, což vedlo k propadům výkonu.
Díky jednomu rozhodnutí neohrožené bojovnice (ano je to Xena), která v době útlaku a příkoří od silnějších, zlých a malicherných bohů, zavěrila prostému inženýrskému lidu, neb z něj vzsešla, a zahájila novou éru, kde chudí nemusí poslouchat bohaté a i obyčejní lidé najdou zastání.
By byl dobrej film.
Zaplať si prémium a nespamum v diskuzi.
Jasně se v článku píše:
"v procesu se energetická efektivita liší v řádu pár desítek (nikoli stovek) procent."
Clovece nestastna preboha ty to po sebe citas !??!??!?!? SMT/HT sa stara o to, aby bolo MAXIMALIZOVANE vyuzitie VSETKYCH vypoctovych jednotiek v jednom fyzickom jadre CPU v kazdom takte. Wono div sa svete 1 vlakno nevyuzije potencial kremika jedneho fyzickeho jadra na 100% = nie vsetky jednotky nie su v kazdom takte zatazene (to su tie tvoje bubliny). Tento problem vznikol uz pred vyse dvoma dekadami, ked jednotlive jadra zacali byt komplikovanejsie. Preto Intel nasadil HT.
Bez SMT/HT logicky kremik fyzickeho jadra (vsetky vypoctove jednotky) nie su vyuzivane na 100%, ale v pripade Intelu v hrubom priemere na 81% a v pripade AMD na 74%. A aj to je zjednodusene, mozno tretie vlakno by este vyuzilo dalsie 3% potencialu kremika jedneho fyzickeho jadra a stvrte vlakno este 0,5%. Avsak ako vidno s pridavanym tretim a stvrtym vlaknom by percento vyuzitia bolo stale mensie a mensie az kontraproduktivne male, preto sa nikto v x86 architekture nehrnie do 3- 4-vlaknovych jadier.
A celkom logicky (v pripoade AMD) ked potencial kremika jedneho fyzickeho jadra je vyuzity v hrubom priemere iba na 74% (bez SMT), ocakavam nizsiu spotrebu fyzickeho jadra ako ked je jeho potencial vyuzity na 100% (s SMT).
Je to mnohem starší, na předchůdci HT pracovali v IBM od 50. let.
Vzdyt ten AMD mel vyssi frekvenci nez Intel.... A ciste teoreticky AMD muze docasne vypnout casti, ktere docasne nepotrebuje. Pri SMT je pouzije vice, tak adekvatne stoupne spotreba.
Vzdyt ty tabulky ukazuji, ze u AMD spotreba stoupa adekvatne prinosu SMT v dane uloze.
Presne, nepochopenie situacie: tak woni tie najnovsie skodovky maju ACT (system odstavenia dvoch valcov) + navyse eletronika by sa mala postarat o to, ze ked idem s hodenym kvaltom dole kopcom, spotreba na novych autach je 0.0 (absolut nula) - na rozdiel od 50-rocnej MBcky 100 kupenej roku pana 1973 a zerucej iba hnusny olovnaty benzin, absolutne bez akejkolvek riadiacej elektroniky 8-8,5 l/100 km s kvaltom ci bez, hore ci dole kopcom ... A div sa svete, ona by ta spotreba aj na najnovsich skodofkach nebola nula, ale dajme tomu 4.0 miesto 5.5 - to by niekde bola strasna chyba.
Nie nie...aj stará škodovka s karburátorom pri brzdení motorom, zatvorenou škrtiacou klapkou žerie minimum. Síce nie úplne 0.0 lebo nevypína vstrekovanie, stále si cez voľnobežný okruh vyťahuje minimum benzínu. Niektoré verzie karburátorov majú elektromagnet s ihlou ktorá zatvára prívod paliva po vypnutí zapaľovania (aby sa z horúceho karburátora neodparoval benzín, prípadne aby ešte nechytil pár samozápalov prehriaty motor). Videl som schémy na prerobenie tohoto ventilku na odpájanie paliva pri brzdení motorom....takže aj na starej škodovke môžeš mať 0.0 dolu kopcom so zaradeným kvaltom ;-)
iste sa v tom vyznas viac ako ja, ale objektivny fakt je ze 1/2 storocna mbcka s kvaltom dole kopcom a spotreba 0.0, nejdu k sebe
Sme prudko OT, ale karburatorove motory pri zatvorenej skrtiacej klapke a brzdeni motorom stahuju pomerne vyznamne mnozstvo paliva, pretoze volnobezny system je stavany na nejaky podtlak pod klapkou, ktory tam je na volnobehu. Pri deceleracii je ten podtlak vyssi a taha odtial pomerne viac paliva.
Tie schemy som videl tiez, zalezi od fyzickej konstrukcie karburatora, ci budu fungovat. Napr. karburatory v skodovkach mali ihlu umiestnenu tak, ze ked sa pri deceleracii zavrela, elektromagnet uz nemal dost sily ju otvorit. Starsie karburatory ju mali inde, ale tam zas bol problem s tym, ze pod ihlou bol benzinovy kanal, u ktoreho nejaku dobu trvalo, kym sa znova zaplnil benzinom. Takze auto mohlo kludne zdochnut po vyradeni do neutralu.
A aby sme boli este viac OT, tak *niektore* nove (maloobjemove benziny s filtrami pevnych castic, zhruba 2018+) pri deceleracii vstrekovanie nevypinaju. Dovod je ten, ze sa tym udrzuje katalyzator nahriaty.
"Pri deceleracii je ten podtlak vyssi a taha odtial pomerne viac paliva"
Ne. Nemusí. Klapka je zavřená úplně stejně jak při brzdění, tak při volnoběhu. Protože plynový pedál je ve stejné poloze. Podtlak se tvoří tím jak se otáčí motor a písty saji vzduch.
Takže Podtlak je přímo úměrný otáčkám motoru. Otáčky na volnoběh jsou cca 1000.
Při brzdění motorem budou většinou větší, ale stačí přibrzdit brzdou a můžou být i menší než 1000.
No a když máme ostré váčky a nízké otáčky, tak to saje jen když je otevřený sací ventil. Takže podtlak bude stejný. Jen bude častěji skákat mezi nulou a hodnotou kterou dokáže vyrobit jeden válec. Obrácená hodnota (Komprese) se měřila tak, že se místo svíčky namontoval tlakoměr. Předpokládám že bude stejně velká jen opačná.
A co je podstatné, ta plynová klapka má v sobě díru kvůli volnoběhu. Není těsná! Volnoběžná tryska je blíž ke klapce než k ventilu. Takže ten podtlak bude zase menší.
Viděl jste někdy akcelerační trysku v chodu?
Jak tam stříkne benzín když seslapnete plyn?
Nevím jak škoda 100, ale tyhle starý karburátory fakt ušetřili hodně při brzdění motorem.
Důležitý bylo neslapat na plyn. Ale nastavit požadované otáčky a držet nohu bez prohnutí.
Proč Slováci vždycky začnou žvatlat vo starejch škodovkách na IT webu? To nemáte opravdu jiný přirovnání k podpoře vašeho tvrzení o pokročilých integrovaných obvodech, než nějakej motor auta kterej funguje úplně jinak a je ještě 100 let starej? Prosím kohokoliv ať mi to vysvětlí, co má spolu společnýho po funkční stránce auto a integrovaný obvod, a jak se dají na příkladu z jednoho potvrzovat názory na to druhé?Děkuji
PS. V případě že někdo bude mít vysvětlení, tak bych prosil myšlenkový pochod který k tomu vedl. Rád se příručím něčemu novému, čemu sem dosud nerozuměl.
Co se v mládí naučíš, je ti ke stáru na ***, ale můžeš na to vzpomínat.
Par lidi zheblo, kdyz z kopce vypli motor a zamkli si volant....
No někdy to nemusel být ani zamknutý volant, ale stačilo že přestal fungovat posilovač brzd...
To sa ale nestane, kym clovek zaroven aj nevyradi :)
Ci je posilovac klasicky podtlakovy, alebo hydraulicky (niektore exotickejsie dizle), tak je to hlupe a kym sa motor toci, (pod)tlak to robi.
Brzdy su safety relevant komponent a strata brzd pocas jazdy je ASIL D a to pri vyvoji auta nechces.
No, ale ti sikulove samozrejme i vyradili, aby motor nebrzdil. Prece, ne? A asi to vyradilo i posilovac volantu.
No, ja to nikdy nezkousel vypinat z kopce motor, fotrik mi uz od deseti tloukl do hlavy, at tohle opravdu, ale opravdu nezkousim, jinak mne vlastnorucne zabije.
Az niekto dole kopcom zhasne motor a vyradi, je len dobre ked sa na konci tej zakruty vysype a ocisti genofond.
Je to na Darwinovu cenu, aj ked trocha nudne.
stejne je ht ficura co za par tranzistoru navic zvysuje intelu o 20% vicejadrovej vykon, takze je blbost ji vypoustet.. spis to vypada, ze na ty architekture neco tezce posrali.. prej zkouseli implementovat smt4 a je to tak zvorany, ze jim nebezi ani smt2..
Ne. Intel určitě chystá stejnou revoluci jako byl přechod z Netburstu na Core, tak se taky na HT vyprdne. Vývojové náklady a problémy navíc jsou v dnešní době atomových jader těžko zdůvodnitelné. SMT4 je sci-fi, nad tím asi ani dlouho neuvažovali.
Kde přesně se ta revoluce koná?
https://diit.cz/sites/default/files/intel_arrow_lake_projection_01.jpg
S podporou SMT4 experimentuje AMD i Intel už několik let.
Intel nezklame, odkaz je podvrh.
Experimentují asi jako já s myšlenkou, že se opásám výbušninami a odpálím se na schůzi pětikoalice. I bez SMT4 mají Zen4 CCD čiplety o skoro 60 % víc tranzistorů než Zen3 a Intel má problémy i s blbým AVX-512, přičemž SMT4 je o dva řády větší výzva. Přirozenější je, se na to vykašlat, jako to udělal ARM. V jednoduchosti je krása, geniální věci bývají jednoduché.
Ten SMT nemusí mít přínos jen ve využití aktuálně nevyužívaných jednotek jiným vláknem, ale i v udržení contextu při obsluze většího počtu vláken. Například SUN SPARC T4 měl před více než deseti lety osm vláken/core. Nakonec Zen chiplety jsou navrhovány s výhledem serverového+desktopového nasazení.
https://en.wikipedia.org/wiki/SPARC_T4
Kdyby to bylo tak skvělé, lehké a bez mínusů, tak proč by to už nenasadili?
Od uvedení Core až po uvedení Zen1 měl Intel prasečí časy a mohl si dovolit i riskovat. Místo toho se počet transistorů na velké jádro zvětšil určitě víc jak 4x a pořád nic - naopak se uvažuje o vypnutí i toho klasického dvojitého HT a ARM plány na HT zrušil. Asi to opravdu má zmíněné podstatné mínusy.
Tento měsí byla publikovaná zpráva o nových ARM CPU od nového výrobce.
A hádej co? S SMT.
Zpráv vydám třeba 50 denně. Až se to prosadí trochu víc, tak mě probuď. Cortex A76AE je IMHO takový fake SMT a tohle nové asi nebude jiné. ARM je ohledně toho tajemný, takže asi nechce přiznat, že prostě vzal základ dvou jader a udělal z toho 1C/2T. To že to je pro použití v automotiv, kde záleží na bezpečnosti, mě v této teorii utvrzuje. Revoluce nepřichází u produktových řad s prioritou v bezpečnosti.
Opravdu tiskové zprávy?
Anebo jen nějaké osobní cancy a slinty?
Tiskovou zprávu si přečtu.
Vaše osobní názory mne nezajímají, dokud se nesnažíte je vnucovat ostatním jako "Víru svatou".
Intel mel SMT4 v atomech tak pred deseti lety - jakepak scifi.
Sci-fi je využitelnost v reálných aplikacích.
Ten "atom" s SMT4 mám jako relikvii k testování paralelismu na stole, a zapojení 3. a 4. vlákna vyždímá navíc tak možná 5 % výkonu. Deset když se hodně snažím při návrhu algoritmu.
Co víc, často všemožný overhead OS, aplikace, až po pressure dekodéru a dalších zdrojů jádra, znamená naopak snížení výkonu.
10% vyždímat optimalizací kódu je super. Je to víc než průměrný mezigenerační nárůst běžně měřeného výkonu u největšího výrobce CPU na světě.
Ale tam nešlo o běžné CPU. Larabee měla být původně grafika.
Původní Larabee ano ...ale socketové Phi 72XX tak nepůsobí ani náhodou; je to vyloženě mesh atomů na steroidech.
na steroidech. a kokainu :)
".. to vypada, ze na ty architekture neco tezce posrali .."
Podle spotřeby ... ženout ten Intel 7 hodně za sweetpot.
To je to nahánění výkonu frekvencemi.
"ztráta až 9,5 %"
Kecy
Běžně to je 50%
Když běží víc úloh najednou a potkají se na jednom jádru.
Takže na intelu HT vypínám. Nemá žádný přínos a ztráty jsou ohromné.
(kromě těžkého MT, ale ten na intelu snad nikdo neprovozuje)
SMT na AMD stojí za úvahu.
To je prudke nepochopenie situacie.
Ak sa vsetky ulohy stretnu na jednom jadre, nie je to problem SMT/HT, ale problem planovaca. A SMT ani HT s tym nic moc nema.
Preco sa tak deje? Ak mam nejaky pocet beziacich a nejaky pocet uspanych jadier, tak v zavislosti od procesora moze byt lepsi pomer latencia / energia proste nechat vsetky tie ulohy na jednom jadre a hoc zvysit jeho frekvenciu, nez pri malej frekvencii cakat na to, nez sa mi zobudi potrebny pocet jadier (ktory navyse dopredu uplne presne neviem) a potom ich na tie jadra rozhodit.
Ono migracia threadu z jadra na jadro nieco stoji aj na strane HW aj na strane SW.
Tohle chování CPU lze do jisté míry ovlinit pomocí Power Plane.
Viz. serverové Rapid Xeony
Vysoké latence (Power save mode)
nebo vysoká spotřeba i v Idle (Performance mode)
To se furt necháme.
1)Potkají se dvě úlohy. Ne všechny.
2)" pomer latencia / energia"
k čemu ti je, když CPU (2C/4T) bude mít poloviční spotřebu(běží jen jedno jádro a dva thready)
ALE čas na dokončení bude dvojnásobný než když každá úloha bude mít vlastní jádro pro sebe?
3) "migracia threadu nieco stoji aj na strane HW aj na strane SW."
Řádově to jsou milisekundy. Přehození jednou za vteřinu nemá vliv na výkon.
Zato přepínání mezi dvěma úlohama na jednom jádru se děje mnohem častěji. Protože CPU se snaží o realtime pocit.
A to je brzda.
4)Co je strana HW a SW?
5)Ano je to to problém plánovače. Stejně tak E-Cores.
Ale když je vypnu, tak plánovač má ménš práce a celý PC běží rychleji.
(kromě těžkého MT)
3) migrace vlákna na jiné jádro už z principu stojí dvojnásobek přepnutí kontextu
A když se povede, tak i flush a re-load cache.
Scheduler windows má pocit, že se to děla musí, aby se "neošoupala" jádra.
A bavíme se o L1 nebo L2 nebo L3?
L3 je zdílená mezi jádra, takže se flushnout nemusí.
L2 má cca 1MB. Tak se hold 1MB natáhne znovu z RAM a nebo z L3.
L1 má 32kB...
Proč by to měl být dvojnásobek přepnutí kontextu?
A i když by to byl dvojnásobek, tak to je furt lineární složitost.
Což nevadí. Nebo nás to na hodinách prgramování učili špatně?
Sheduler to ale dělá mnohem méně často než jádro které se snaží zpracovat dvě úlohy.
Kdyby to dělal sheduler moc často, tak ho snad upraví tak, aby to nemělo vliv.
Jo. Jsou rozdíli ve výkonu mezi Win a Linux. Hlavně díky sheduleru. Ale většinou to je do 10% výkonu. Viz ta lineární složitost.
Mě se děje že sheduler hodí dvě ST úlohy na jedno jádro (každá má svůj thread! žádné migrace ani přepnutí kontextu neřeším!) a ostatní jádra uspí. Což je hodně špatně. Výkon klesá na polovinu.
Po vypnutí HT se to chová korektně.
Jenže tohle nikdo netestuje. Všechny testy jsou dělané tak že běží jedna úloha a ostatní (Antivir, FW, Outlook, Teams, FF, Adobe...) se vůbec nezapínají.
"L3 je zdílená mezi jádra, takže se flushnout nemusí."
To snad platí pouze pokud není obsluha vlákna předána jádru z jiného chipletu.
Bavíme se o HT, takže o intelu, a ten žádný chiplety nemá.
No jo. Intel má dlaždice.
A vyšší latence P-jader i v rámci jedné dlaždice resp. monolitu.
Ono ale loadovanie cachi nie je take jednoduche. Nefunguje to tak, ze OS prehodi lopatou thread na ine jadro / hart (hardwareovy thread, RISC-V terminologia) a ten hart dostane od stareho hart-u nejaky zoznam dat, ktore si ma v bulk-u nacitat. Ani sa data nepresypaju z jednej L2 cache do druhej. Cache sa proste flushne (s tym, ze ak nieco este nebolo zapisane, moze to znamenat nejake latencie) a novy hart si potrebne data bude nacitat.
Diabol v detailoch je tu v tom, ze to nacitanie sa neudeje hromadne, ale kusok po kusku. jedna cacheline za druhou, ked dojde ku cache miss. A tych bude po prehodeni threadu na novy hart potencialne viac, nez ked thread bezi tam, kde uz bezal. A kazdy cache miss znamena, ze thread stoji. Jedno cislo - dost extremne, pretoze je to L3 miss - co som za 30 sekund googlenia nasiel hovori o L3 miss znamenajucom latenciu 70 taktov. To je potencialne 70+ vykonanych instrukcii (v optimistickom pripade, ze ma dekoder a scheduler dobry den), kedy procesor stoji a nic nerobi (ak to reordering neuhasil).
"70 taktov"
Kolik to je vteřin?
Když CPU má dnes cca 5GHz.
I kdyby těch cache miss byl milion, tak to je zanedbatelný čas.
No, pri tom zalezi, ako vela cache miss sa udeje, co vo vysledku zalezi od toho, co za program tam bezi. Ale je trivialne jednoduche napisat algoritmus, ktory bude cache-friendly a algoritmus, ktory cache-friendly nebude a demonstrovat, ze taketo 70-taktove stally, ktore nic netrvaju mozu znamenat pripastny rozdiel vo vykone.
Ucebnicovy priklad je spracovanie obrazu po riadkoch vs. po stpcoch (napr. tu: https://onestepcode.com/array-reference-performance-row-major-vs-column-...) kde je vidno, ze nechcene cache load s prehladom spomalia rovnaky algoritmus aj 3x.
Samozrejme, cislo z tohto clanku nema ziadnu vypovednu hodnotu ku cache stallom pri bootovani uspateho jadra a plneni jeho cache. Len to demonstruje to, ze cim menej cache missov a cim menej casto k nim dojde, tym lepsie.
"spomalia rovnaky algoritmus aj 3x."
3N je stále lineární složitost.
Jo vliv to může mít. Lagy při práci se zvukem nebo hraní her. Ale ani jedno nedělám.
A jestli se to zopakuje 100x za vteřinu, tak věřím že to zabrzdi i rychlé PC.
Sežeňte si nějaké Intel CPU, které zvládá AVX512.
Seřeňte si nějakou aplikaci, která to AVX512 používá.
A pak změřte kolik ms trvá než jádro přejde z obecného režímu do AVX512 když poprvé přijde k AVX512 instrukci.
1) "Potkají se dvě úlohy. Ne všechny."
A toto viete akym sposobom takto presne urcit? Typicka frekvencia prepinania uloh v dnesnom operacnom systeme je 1000x za sekundu.
2) "k čemu ti je, když CPU (2C/4T) bude mít poloviční spotřebu(běží jen jedno jádro a dva thready)
ALE čas na dokončení bude dvojnásobný než když každá úloha bude mít vlastní jádro pro sebe?"
Bude to k tomu, ze toto nie je hra s nulovymi suctami. Zobudenie a nasledne uspanie dalsieho jadra sa nedeje okamzite a tiez stoji nejaku energiu. Takze to nie je dvojnasobna spotreba vs. dvojnasobny cas, ale spotreba X (vsetko bezi na jednom jadre) vs. spotreba Y (zobudi sa dalsie jadro, ulohy sa zmigruju, vsetko sa spocita a dalsie jadro sa nasledne uspi).
Ak by sa toto malo diat stovky krat za sekundu (1000 prepnuti kontextu / sekundu, takze pri stovkach zobudeni procesora sa bavime len o nejakych radovo 10% pripadov, kedy k migracii ulohy na ine jadro naozaj dojde). Tak sa kludne mozeme bavit o 10% navyseni spotreby, ktore je uplne jalove (energia sa spali, ale nic navyse sa za to nedostane, pretoze uloha sa este/uz nepocita).
Navyse, HT/ne-HT neznamena dvojnasobny cas. To HT jadro nejaku pracu spravi. Aku, to zalezi od charakteru uloh. Cize skratenie casu na polovicu v tomto pripade je nezmysel.
3) "Řádově to jsou milisekundy. Přehození jednou za vteřinu nemá vliv na výkon. ... Protože CPU se snaží o realtime pocit."
Pri zobudeni jadra kvoli migracii ulohy nie je cely proces len o tom, ze presuniem ulohu v OS z jedneho jadra na druhe. Zaroven sa to jadro musi aj zobudit a po skonceni prace sa musi aj uspat. Power management musi do vypoctu, ci dalsie jadro zobudit alebo radsej nie, zaratat aj tieto energeticke naroky.
Jedine reprezentativne udaje, ktore som nasiel uvadzaju, ze pre nejake Xeony trva zobudenie zo spanku C6 (to uz je pomerne tuho spiace jadro) zhruba 0,1ms. Pri armoch znovuzapnutie celeho clustera moze znamenat latenciu az 5ms.
Clovek si povie, no hej, co je to 5ms, alebo co je to 0,1ms. Treba si uvedomit, ze 0,1ms je 10% casu, ktore je typicky pridelene ulohe kym sa prepne. 5ms je potom 5 celych takych casovych usekov. A jedna milisekunda behu procesora taktovaneho na 1GHz znamena +- jeden milion (u modernych CPU s vysokym IPC kludne aj nasobne viac) vykonanych instrukcii. A to je sakra vela vypoctoveho vykonu. Ak sa to spravi len pri 10% prepnuti kontextu (radovo stovky krat za sekundu), tak sa to pekne nascita na nejake % casu, ktore jadro travi v zapinani, alebo vypinani. A to znamena o tych par % nizsi vykon, alebo naopak vyssiu spotrebu.
CPU sa o ziaden realtime pocit nestazi, snazi sa onho operacny system. CPU je +- lautr sumafuk, co sa na nom pocita.
4) "Co je strana HW a SW?"
Strana HW pri migracii je o tom, ze jadro ako take musi nabehnut. Na rozumne modernom procesore ma kazde jadro vlastne hodiny, tie sa musia rozbehnut a to nie je hned, dalej musia ponabiehat a zastabilizovat sa obvody. Ked je ten stav spanku hlbsi, tak zobudenie jadra je v podstate rovnaka robota, ako jeho prvotny start. Pretoze mam prazdne cache, vypratane registre, branch predictory a ktohovie co vsetko v tom jadre este je, hole pipeliny. Proste panenske jadro. Takze tych 0,1 ms hore je len cas, ktory zozral procesor na to, aby od pokynu k zapnutiu zacal pocitat prvu instrukciu.
Tam sa dostane k slovu SW strana, kde OS musi spracovat frontu threadov, ktore su prijate na zaradenie k behu na danom jadre. V zavislosti od implementacie moze byt thread nespustitelny, kym v tej fronte visi. Ako dlho to trva, to zalezi od operacneho systemu.
A potom az sa OS rozhodne ze teda fakt ten thread premigruje, vyriesi si interne alokacie roznych zdrojov k threadom (napriklad filesystem) a thread sa zacne execovat, sa znova dostane k slovu HW, pretoze sa musia naplnit cache, prediktory, ... Takze take jadro este nejaky kratky cas nebezi na optimalnej rychlosti porovnatelnej s plne beziacim jadrom.
5) "Ano je to to problém plánovače."
Problem je ten, ze toto nie je exaktna veda. Ani ta dojmologia, ktoru z toho vy pri sledovani pomaly sa aktualizujuceho spravcu uloh varite nema s realitou vela spolocneho (dokonca pre spravcu uloh moze byt neviditelne, ze sa medzitym nejake jadro stihlo zobudit a potom uspat). Operacny system totizto nikto dopredu neinformuje, ze ide robit velke mnozstvo vypoctov. Operacny system si to moze zistit az dodatocne na zaklade toho, ze si pri kazdom procese/threade vedie statistiku. Z principu veci ma statistika znacne latencie, ak ma byt jej vystup aspon trocha stabilny.
Takze napr. zistit zo statistiky, ze nejaky proces teda asi zacal zrat hodne vela procesoroveho casu, moze kludne trvat aj 100ms. Lenze to nehovori nic o tom, kedy sa ta uloha dokonci. Moze bezat dalsich 20 sekund, ale kludne moze o 5ms skoncit. Ak chcem statistiku skratit, aby som znizil latencie, paradoxne to moze viest k opaku a/alebo k zvyseniu spotreby, pretoze procesor uspavam/zobudzam prilis agresivne a jednotlive jadra travia svoj mizerny zivot v jalovej faze zobudzania / uspavania, kedy nic nepocitaju, len zeru energiu. Vypocet sa tak nezrychli, latencie mozu aj stupnut, ale spotreba stupne.
Dalsia vec je, ze programy potrebuju na to, aby mohli pocitat, niekde ziskat data. To ide bud z disku, zo siete, z periferii alebo od pouzivatela. Latencie pevnych diskov (HDD aj SSD) sa pohybuju radovo niekde okolo 1ms, takze uz pri nacitani z disku moze mat zmysel thread proste zastavit, kym data nie su k dispozicii. Cokolvek ine trva z pohladu OS nekonecne dlho a thread, ktory cita taky vstup sa bezpecne zastavuje. Toto tiez dost krivi statistiku.
Ad1)
Zpracovávám .TIFF. koukám kolik operací dělá za vteřinu. Vytíží to jedno jádro na 5 minut.
Najednou padne rychlost na polovinu a odhadovaný čas skočí na 10 minut.
Kouknu do zpravce úloh a antivir na pozadí aktualizuje databázi. Po aktualizaci běží ještě kontrola souborů po startu. Antivir běží na T0 a moje aplikace na T1.
CPU je 4C/8T. Takže T0 a T1 = Core0
T2 až T7 tedy Core1 až Core3 mají vytížení cca 1%. Nějaké programy na liště.
Neudělá to vždy. Nevím jak to zopakovat.
Po vypnutí HT se to chová normálně. Antivir na C0 a moje úloha na C1.
Váš post jsou možná pěkný teorie. Ale praxe je něco jiného.
Například:
"To HT jadro nejaku pracu spravi. "
Prakticky:
"Průměrný přínos u Intelu je 18,8 %,"
Ale to je pro MT úlohy.
Přínos pro všechny ST úlohy je 0% v lepším případě. V horším případě 50% ztráta výkonu. Takže reálně jsem vždy v mínusu. A těch 18% při MT úlohách za to nestojí. Si raději koupím AMD který má víc velkých fyzických jader. A Lepší SMT. Žádný podvody na zákazníka jako HT nebo E-Core. Bohužel benchmarky nehraju. A hold chci od PC aby dělalo víc úloh naráz. Než jen jeden test.
„U AMD znamená zapnutí SMT procentuálně výraznější zvýšení energetických nároků (nižší desítky procent) než u Intelu (většinou jednotky procent), ale v absolutních číslech je spotřeba Intelu podstatně horší.“
Existuje vůbec aspoň nějaká činnost, u které mají lepší spotřebu?
Intel si vede velice dobre v IDLE, coz prinasi uzivatelum pohodlnost a klidny spanek - muzete komp s rozdelanou praci nechat zaplej (jen widle do toho hazou widle, kdyz se rozhodnou restartovat kvuli aktualizacim) a pokracovat kdy chcete.
U kompu s AMD je vypinani nutnost.
Toto slo na vrub chipsetov a uz ten rozdiel spotreby v idle davno nie je taky priepastny. Je kludne mozne, ze zostavy postavene na AMD budu menej zrave, nez Intelacke.
Netreba sirit FUD :)
Spotřeba v Idle je pro někoho důležitý parametr.
Umístění 2 jader do Soc a možnost vypnutí dlaždice s CPU jádry to umožní ještě o něco snížit.
Teoreticky. Záleží na tom, jak se toho ujme plánovač ve Windows.
Už v lehké zátěži (2~4 vláken) je ale energeticky efektivnější AMD.
Ja som reagoval hlavne na to kombo: "Intel si vede velice dobre v IDLE" vs. "U kompu s AMD je vypinani nutnost."
Bejvavalo za cias Phenomov a podobnych zverstiev, ze Intelia masina v idle ako celok zrala <20W a podobne skonfigurovane AMD blizko k 100W. Tam ten procesor bud zral vela, alebo sakra vela. Dnes su tie spotreby porovnatelne, pripadne AMD podlezie Intel (napr. tu https://diit.cz/clanek/recenze-amd-ryzen-7-5800x3d-aneb-s-krizkem-po-fun... je u oboch spotreba +-70W).
Já když nedávno řešil co nejúspornější SSD do notebooku, kde šlo o každý watt, tak jsem skončil s pci-e 3. Takže to bude i dalšíma věcma a jen doufám, že pci-e 6 už bude jiná technologie nebo s tím nárůstem spotřeby něco udělají jinou cestou. Celkově je směr vývoje diskutabilní, protože některé starší Intely jsou v idle s nejmenší spotřebou rekordmany (v desktopu určitě).
Tak v laptopu jsou to i 3W. To ve finale může snížit vydrz dost výrazně. Je rozdíl jestli stroj jako celek zere treba 8 nebo 11W. Při maličké 50Wh baterii se bavit treba o 6 vs 4.5h vydrzi v nizke/žádné zatezi
Ja bych se na to nedival tak cerne.. Intel zere v idle nic, v zatezi nejake max dle specifikace. HT pridava hodne vypocetniho vykonu pro me navic zdarma (rozumej - spotrea se uz nezmeni).
V metrice kterou mam (kernel compiles per kwh) to pak procesory s HT posouva na vyssi pricky, a ty co HT nemaj (starsi i3/i5, lowend xeon modely) se propadaj v efektivite. Ta situace je celkem smesna, protoze je tam stejnej kremik - a HT/neHT je ciste marketingova segmentace kvuli cene. A o te se muzeme hadat podobne jako ohledne clanku:
Je cpu s HT predrazenej, nebo je cpu bez HT prodavan pod cenu? :D
Souhlas.
To že je přístup Intelu a AMD k HT (SMT) jiný, neříká vůbec nic o tom, který je lepší.
AMD části procesoru vypíná bez využití SMT a tak šetří energii, rozuměj ze 170W se dostane při nevyužití na +-130W, Intel se z 253W energeticky posune na +-240W.
Napsáno takto to působí jinak než při hře na procenta, zjevně Intelův problém není vypínání částí procesorů v době jejich nevyužívání, ale přílišné žraní energie, kdykoli ho zatížíme jakýmkoli způsobem. Mezi úsporným momentem Intelu a plným energetickým vytížením AMD je stále propastných 70W rozdílu, tam je hlavní problém!
já SMT vypnul u obojího, nad 8 fyzických jader je výkonu dost. Ovšem podle toho mi vychází že použití SMT u AMD čipletům víc přitopí což se shoduje i s praktickým pozorováním.
Ty testy jsou velice podnetne - preklad ciste vykon single CPU bez spotreby:
PERL (system - interpret - OS/shell rutiny) = +17% Intel nad AMD
GCC (system - prekladac prog. jazyka) = +18% Intel nad AMD
MCF (app - routing) = EQUAL
OMNETPP (app - stream/events) = +45% Intel nad AMD
XALANC (app - DOM) = -8% Intel pod AMD
X264 (app - multimedia) = -9% Intel pod AMD
DEEPSJANG (app - neural) = -21% Intel pod AMD
LEELA (app - go - tree search) = -27% Intel pod AMD
EXCHANGE2 (app - messaging) = -45% Intel pod AMD
XZ (app - compress) = EQUAL
Co z toho plyne?
Intel ma vyssi datovou propustnost. Linux vam bude bootovat na Intelu rychleji, stejne tak skripty vam budou bezet na Intelu rychleji. Operacni system bude na Intelu vzdy sviznejsi. Intel vam rychleji zparsuje JSON a vse co souvisi a pocita se v bytech. Ma paradni streamovou propustnost, stream je vyhradne single thread technologie, tzn. modularni skalovany vyvoj sw. Docker, Java, prenosy dat (import/export), eventove nebo streamove aplikace by mely bezet na Intelu svizneji, predevsim aplikace bez frontendu.
Naopak AMD by melo mit vyssi objektovou propustnost. Vse co souvisi s praci se stromy bude bezet rychleji na AMD. Tzn. tezke komplexni prasacke aplikace, ktere nejsou optimalizovane, jsou spatne napsane navic postavene na nejakem tezkem frameworku, workflow by melo probihat svizneji na AMD. Spring, XMLDOM, UX, Kafka, ElasticSearch, AI a vse bez optimalizace by melo bezet na AMD rychleji.
Pokud moc vyvoji sw neumim a delam hodne s tezkymi frameworky, optimalizace je pro me nezname slovo, jsem vyvojar prasecak, prikazovy radek je pro mne nezname slovo - vsechno naklikavam, ux rozhrani je pro mne nedilnou soucasti sw bez ktereho bych neprezil, vsechno co naimplementuji je pomale at se snazim sebevice koupim si AMD. Nebo naopak pokud hodne pracuji s AI, vyhledavanim koupim si take AMD.
Pokud vyvoji sw rozumim a casto optimalizuji svuj sw, tak aby bezel svizne, hodne pracuji primo v Linuxu nebo s prikazovym radkem, koupim si Intel.
Zde je videt docela pekna alegorie, vetsina linuxaku jsou velci fandove AMD, pritom by udelali lepe, pokud by si koupili Intel.
Jako firemni server pro nasazovani webovych aplikaci mi subjektivne prijde lepsi Intel. Zde ma ovsem nevyhodu vyssi spotreby.
Urcite neni AMD vykonejsi nez Intel - v zadnem pripade to neni pravda. Takove veci tvrdi jednostranne herni casopisy, ktere testuji pocesory pro herni uziti.
Takze sve tvrzeni aktualizuji - AMD je procesor pro hrace pocitacovych her a grafiky.
Tahle úvaha má ale jednu zásadní vadu, a sice tu, že platí pouze v případě, že zatěžujete pouze jedno jádro. Třeba u toho GCC je celkem jedno, že Intel je o 18% rychlejší než AMD na jednom jádře, protože člověk stejně použije make -j<N> (kde N je počet logických procesorů, který máte k dispozici). No a pokud Intel, který pro těch +18% výkonu spotřebuje u GCC +165% energie, narazí na příkonová omezení dříve, tak silně pochybuji, že bude i v takovém případě o 18% rychlejší.
Prave Intel podporuje neomezene tdp, takze na prikonove omezeni pokud vam jde o vykon nemusite nikdy narazit.
To je porad to same forum plne socialistickych mamanku, nesmi se rici nic proti amd - jjnak beda kladivu a srpu.
"Neomezené TDP" je ve světě poplatném reálné fyzice pustá fantazie.
Dobrá úvaha.
Úplně se to otočí. AMD vyhraje o 82%.
https://www.anandtech.com/show/17601/intel-core-i9-13900k-and-i5-13600k-...
Tato recenze je o 14900K vs 7950x a vy odkazujete na test 13900K predesle generace. Jste uplne mimo obsah diskuse. Hlavne ze mne flamujes jako spambota, frajere.
Chcete říct, že nějakých průměrných +8% zvrátí ten výsledek, kde Intel ztrácí 70+% ?
Úplně mimo je tady někdo jiný.
Nepotřebuji být frajer.
Ovšem už jen výskyt některých spamerů a botů v diskusi za mne frajera dělá, bez toho, že bych pro to něco dělal.
Spustte si JIT compiler na 16 vlaknech. Java by mela bezet svizneji na Intelu.
".. v zadnem pripade to neni pravda .."
Využijte dar pochybnosti.
Protože jediný přehlédnutý detail může Vaši pevnou víru rozbít na padrť.
Rikam forum plne socialistickych mamanku, kteri odmitaji vest vecnou diskusi. Mate uz doma nad hlavnimi dvermi kladivo a srp?
Ne.
Mám je dílně.
Používám je jako pracovní nástroje.
Patřím ke generaci, která umí používat ruce i k jiným věcem, než patlání po smrtfounu.
Náš SpamBOT vyplodil příspěvek nad kterým jsem se zamyslel.
Chválím.
A dokonce odpovídá v diskuzi. Ale ještě stará verze. Bohužel.
"OMNETPP (app - stream/events) = +45% Intel nad AMD"
Opravdu?
Anandtech naměřil plichtu.
Stejně jak v PERL.
https://www.anandtech.com/show/17601/intel-core-i9-13900k-and-i5-13600k-...
Takže z 10 testů intel vyhraje v jediném a to jen o 18 % v GCC.
SpamBOT z toho udělá velké hurá.
Takhle to dopadne, když se z normalizovaných výsledků (stejné takty) někdo snaží udělat závěr o celkovém výkonu CPU.
Odkazujete na test intelu 13900K, clanek na diit je o 14900K.
To si neumite ani precist obsah clanku, na ktery odkazujete?
Vite vubec o cem hovorite, prijdete mi nepritomny mistem nejmene?
".. To si neumite ani precist obsah clanku .."
Titulek článku je .. "SMT Zen 4 více zvyšuje výkon než HT Raptor Lake .."
Kde tam vidíte 14900K?
To ani neumíte přečíst název článku, pod kterým diskutujete?
Vy ocividne patrite do skupiny b vyvojaru cuniku a ani po 10 letech nevidite dale nez do sady frameworku.
Je uplne jedno zda gcc nebo javac anebo JIT. Zkuste si JIT compiler spustit na 16 vlaknech.
Vy jste takovy chytrolin, ktery umi jen socializovat sve okoli. Ale jo, nekdo musi pomahat manazerum.
Me zavery jsou spravne.
Psal jsem to na jinem miste, dnes neni problem poridit vymenik pro vodni okruh s odvodem 2000w tdp. 250 w ve svete serverovych cpu neni nic.
Vaše tvrzení
".. Me zavery jsou spravne .."
jste popřel vlastními slovy
".. v zadnem pripade to neni pravda .."
Chovate se jak rozmazleny socialisticky fracek s odpustenim.
Rikam forum plne socialistickych mamanku, kteri odmitaji vest vecnou diskusi. Mate uz doma nad hlavnimi dvermi kladivo a srp?
"kteri odmitaji vest vecnou diskusi."
Naprosto přesně.
Odmítám vést diskuzi se SpamBOTem.
Osobne vas odhaduji tak na 120-135 bodu iq. Na skole si z vas nadelali do kalhot a tak svym chytractvim obstastnujete sve okoli. Podobnych zmetku technicke univerzity vychrli kazdorocne stovky mozna tisice.
Ale někdy to je docela sranda.
Robot který nechápe ironii se snaží někoho urazit. :-D
Dost mi připomíná Sheldna Coopera :-DD
".. Podobnych zmetku technicke univerzity vychrli kazdorocne stovky mozna tisice .."
Jak říct, že nemáte technické vzdělání bez toho, abyste to řekl otevřeně.
"Lunar Lake (Lion Cove), což bude později vydaná mobilní varianta Arrow Lake" <= Ne, že bych se v tom neztrácel už dřív, ale může mi někdo pomoc pochopit tu větu výše? Oni mají jiný "Lake" název pro mobilní variantu a pro desktop ... nebo co to znamená (jak to máme chápat) ... ?
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.