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.
Ako sorry, ale iba idiotska SW firma moze mat produkt, ktory renderuje naraz napevno bud 220 dlazdic alebo napevno 9416 dlazdic.
1) Nic medzi tym !!!!!! Aky by bol problem pridat konfiguraciu pre dalsie a dalsie stovky dlazdic? No strasny, asi by to bolo treba doprogramovat.
2) pocet max. subezne generovanych dlaznic (teda rozdelenie obrazku sceny na dlazdice) by mal by generovany dynamicky !!! Pre 8-vlaknovy CPU staci nejakych 32 dlazdic, pre 32-vlaknovy CPU je tych 220 dlaznic povedzme OK. Pre 256-vlaknovy by bolo vhodne napr. iba 1024 dlazdic ...
Nerovnaka (dynamicky generovana) velkost dlazdic je predsa presne pricina problemu opisaneho v clanku. Rozne velke dlazdice -> rozne zatazenie CPU a jeho cache -> neporovnatelne vysledky.
Niekedy sa divim, preco nam teraz vacsinu informacii tlacia vo videach, ale ked vidim ake problemy maju ludia porozumiet informaciam z textu, asi to chapem. Ale je to smutne.
Nebuď na něj tak ošklivý.
Čtení s porozumněním je řazeno do kategorie Superschopnost a není souzeno všem ji zvládnout.
Koukám, že se tady usilovně diskutuje, ale řada lidí si neuvědomuje, že celý problém je poněkud složitější, protože nejde jen o počet nějakých hypotetických dlaždic.
Nejpodstatnější zádrhel je, že se bez ohledu na počet dlaždic se generuje pořád TEN SAMÝ OBRAZ zobrazující ten samý kus virtuálního světa. Pokud se obraz rozkrájí na LIBOVOLNĚ JINÝ POČET dlaždic, změní se VŽDY charakter zátěže a výsledky jsou NESROVNATELNÉ.
Nejde totiž jen o nějaké počty pixelů, ale i o vnitřní souvislosti v modelovaném kusu světa a jejich využití při generování obrazu. Pro srovnatelnost je tedy nutné, aby byl počet dlaždic vždy stejný, bez ohledu na počet jader/vláken procesoru.
Navíc je otázka, jestli a jak výpočet skóre zohledňuje vliv konce obrazu, kdy ještě není hotovo, ale pracuje už jen menší počet jader, protože pro ostatní už není práce. Pokud by se počítal reálný čas na dokončení celého obrazu, budou procesory znevýhodněny tím víc, čím víc mají vláken. Jejich málo aktivní ocas bude totiž delší.
Vliv ocasu se dá potlačit, pokud bude počet dlaždic výrazně (násobně) větší, než počet vláken. Ale lepší by bylo místo času do dokončení počítat součet časů běhu všech vláken a dělit ho počtem vláken.
aby bol rendering jednotlivych dlazdic porovnatelny z hladiska "kusu virtuálního světa", musi byt pocet dlazdic co najmensi (nizke desiatky, alebo dokonca jednotky)
to za predpokladu ze rendering kazdej rovnako velkej dlazdice ma inu narocnsot
aby renderig netrpel onim "ocasem", pri vysoko-vlaknovych CPU musi byt zase naopak pocet dlazdic vysoky
no a ted bábo raď
Zbytecne rozjimani.. velikost dlazdic nema realny vliv na RT.
Ale pokud bychom chteli jit do extremu, nic nebrani tomu, aby byla velikost dlazdice 1x1, takze kazdy dalsi pixel by pripadl novemu vlaknu - to se bohuzel nedela, protoze:
1/ vicero behu vygeneruje ruzne vysledky podle toho jak se jadra vyspi a nastanou synchronicity
2/ synchronizacni primitivy na uzamykani dat maji nezanedbatelnou rezii
Takze reseni je udelat ulohu, ktera bude mit PD >> NC (pocet dlazdic mnohonasobne vetsi nez pocet jader), tj. 16x16 dlazdice napr, anebo naopak, obraz delit vzdy na tolik dlazdic, kolik je jader a pak do vysledku zapocitat exaktni cas po ktery dane vlakno bezelo.
Ad ukolovani.. proc to jsou pitome dlazdice a ne treba interlaced radky? Nejspis jen kvuli efektu vykreslovani.
Nerozumiem reci tvojho kmena. Ty si absolutne, ale absolutne nepochopil lajtmotiv clanku ani mojho prispevku.
"Nerovnaka (dynamicky generovana) velkost dlazdic". To je preboha co? Tych 220 dlazdic je uplne rovnakych. Aj tych vyse 9 tisic je uplne rovnakych, aj moja myslienka 32 dlazdic pre iba 8-vlaknovy CPU a dajme tomu 1024 dlazdic pre 256-512 vlaknovy CPU. Aj tam by bolo tych 32 ci 1024 dlazdic co sa tyka velkosti, uplne rovnakych.
Uz chapes kde je problem?
"Nerozumiem reci tvojho kmena."
Jste to vy, kdo přišel na český server a hovoří zde cizí řečí. Dá se pochopit, že budete mít problém s jejím pochopením, ale to není jeho problém.
"Tych 220 dlazdic je uplne rovnakych. Aj tych vyse 9 tisic je uplne rovnakych"
No právě že není.
Problém je vidět celkem jednoznačně, a to v pochopení psaného textu.
Náročnosť na výpočet 1 dlaždice z 220 bude iná ako 1 z akéhokoľvek iného počtu. A to je ten problém. Ideálne by bolo, aby každé vlákno akéhokoľvek CPU malo rovnakú záťaž.
Ako sorry, ale iba idiotsky diskutér může pod článek napsat komentář, který popírá celý smysl článku.
1) Právě různě velká velikost dlaždice tento problém způsobuje. Nic medzi tym !!!!!! No strasny, asi by to bolo treba doprogramovat.
2) Neměl by být generovaný dynamicky. Je to přesně 1 dlaždice na 1 vlákno. NeCílem je, aby ty podmínky byly za všech okolností pro výpočetní vlákno stejné.
Ovšem suverenita, s jakou jste to napsal, je obdivuhodná.
poprosim daslieho diskutera aby my vysvetlil, z ktorej vety vyplyva, ze tych JEDNOTLIVYCH 220 alebo 9K dlazdic nema rovnaku velkost
Tak si poslušte, a poproste. Asi budete muset napřímo, protože si nemyslím, že by další diskutér věděl, že je to ten další diskutér, kterého jste měl na mysli.
A než to uděláte, tak vám tu pastnu takový malý úsek z toho článku:
"u procesorů s vyšším počtem vláken zmenšuje CineBench velikost dlaždice, a tak namísto 11×20 (220) dlaždic může být obraz rozložen na 88×107 (9416) dlaždic.
Problém však může být právě v tom. Změnou velikostí dlaždice se totiž mění charakter zátěže. S menší dlaždicí klesají nároky na kapacitu cache a spíš rostou nároky na její rychlost."
Jsou tam části jako "zmenšuje", stejný obraz ... rozložen na jiné množství částic, "změnou velikosti dlaždice", "s menší dlaždicí"...
Rozumím, že máte nějakou jazykovou bariéru, ale to je váš problém. Vy si ale tento problém nepřiznáváte, a jste si docela suverénně jistý, že špatně jsou všichni kolem vás. Tomu se říká arogance, a je to nepříjemná vlastost. Všichni to v sobě do nějaké míry máme, a když se to pak projeví, občas se později cítíme jako úplní pitomci.
"cesky server", ale no, hadam nie sme nacionalisti
moja ziadost trva - poprosim o vysvetlenie, ako z toho vyplyva ze kazda z tych 220 dlazdic a kazda z tych 9K dlazdic ma inu velkost
""cesky server", ale no, hadam nie sme nacionalisti
Nechápu. Mluví se tu česky, vy jste sem přišel s jinou jazykovou výbavou, máte problém nám porozumět, a ještě se tváříte, že to není vaše chyba. Jak to souvisí s nacionalismem, to nevím; mně to přijde spíš jako hloupost. Nebo nálepka, a pak se za sebe styďte.
Toto je jiná ziadost než předtím. To z článku nevyplývá, a jsem přesvědčen, že to tak ani není. V tom totiž ten problém nespočívá.
De Pjetro IMHO píše o tom, že objekt/9000+ bude mať každú dlaždicu rovnakú. Článok a my píšeme o tom, že 1 dlaždica z 220 bude mať inú veľkosť ako 1 z 9000+. Proste my o koze, De Pjetro o voze.
Vysvětlení pro lidi s pomalejším procesem zpracovávání vstupů (aka pokud to pochopím já, už by to měl pochopit každý):
De facto dostáváme 2 různé benchmarky, které není možné mezi sebou přímo srovnávat.
- ten, na který jsme zvyklí (220 dlaždic)
- ten druhý (9k dlaždic)
Do budoucna zde budeme mít 3 skupiny CPU (se stávající verzí CB)
- ty, co se testovaly pouze na D220
- ty, co se otestují na obou verzích (pokud to jde zvolit)
- ty, co se testují pouze na D9000
Toto je otázka matematiky asi 1. stupňa ZŠ.
Ak obraz rozdelíme na 220 častí, alebo na 9000+ častí, tak jedna dlaždica NEBUDE mať rovnakú veľkosť. A spracovanie 1 väčšej, alebo 1 menšej nie je pre CPU vlákno rovnako náročné. U veľkej môže byť výhoda, že je v nej viac rovnakých objektov a tým pádom ju vlákno spracuje rýchlejšie ako u menšej dlaždice, kde tie rovnaké objekty bude vo viacerých dlaždiciach a teda ich budú spracovávať viac vlákien CPU. Ty asi stále píšeš o tom, že obrázok rozdelený na x dlaždíc = každá dlaždica v danom objekte je rovnaká. Ale my sa bavíme o testoch rôznych procesorov (s rôznymi počtami vlákien), kedy sa objekt delí na rôzny počet dlaždíc.
Viem si celkom dobre predstavit, ze tie pocty dlazdic budu vychadzat z nejakeho cisla, ktore je mocninou dvojky a ma zaklad v konfiguracii nejakej casti HW. Napr. onehda v dobach drevnych pre PowerPC G4 bolo vyhodne spracovavat bloky o dlzke 128 bitov, pretoze to bola dlzka cacheline a aj sirka vonkajsej datovej zbernice procesora (aj ked bol len 32-bitovy).
Cize rozsekat to na 1024 dlazdic by mozno vyzeralo cool, ale dosiel by si na to, ze dlazdica ma nejaky debilny rozmer, rozbija sa ti locality of reference v cache, alebo nacitavas neuplnu cacheline, alebo nejaka ina low levelova pakaz vdaka ktorej prichadzas o radovo vyssie % vykonu, nez rozsekanim na mensi pocet dlazdic.
A na tomto sakra zalezi, cisto to ako si zorganizujes data v pamati a ako k nim pristupujes moze znamenat nasobny rozdiel v rychlosti na uplne rovnakom procesore uplne nezavisle od toho, ci sa jedna o ST alebo MT algoritmus. Been there done that.
"ktory renderuje naraz napevno bud 220 dlazdic alebo napevno 9416 dlazdic"
Nie je to napevno. Co som videl viac videi, tak v Cinebench R23:
6 jadro 7600X ma 21x12 dlazdic,
12 jadro 7900X ma cca 23x24 dlazdic,
16 jadro 7950X ma 32x32 dlazdic,
32 jadro 3970X ma 64x64, ak som dobre spocital.
Ještě větší chaos, než jsem myslel.
A kde je problem tomu 8C a 128C cpu nastavit stejny vysoky pocet malych dlazdic?
Resp. jak se zmeni skore, kdyz na 8c pustite tech 220 vs 9K dlazdic?
Imho pri raytracingu nehraje moc roli cache.. jadro s malo MB bude kripl tak jako tak - a cpu maji prumerne stejne cache per jadro. Ale klidne udelejte test na stejnem cpu, s ruznou povolenou cache a ruznym poctem dlazdic - z tech 4 mereni lze odvodit jak se to chova.. namisto zbytecneho JPP zvatlani.
odpoved je v clanku: S menší dlaždicí klesají nároky na kapacitu cache a spíš rostou nároky na její rychlost
keby sme zili v idealnom vesmire a program by vytazoval CPU uuuuuuuuuuuuplne optimalne, tak pocet dlazdic by jednak pocital dynamicky a druhak do vypoctu pre pocet dlazdic by vzal do uvahy premenne ako:
- pocet fyzickych jadier
- pocet virtualnych jadier (HT/SMT, poculi sme ghosipy a rumory s 4 vlaknach na jadro v x86 svete)
- rychlost a velkost cache na jadro (je rozdiel ked pre CPU vychadza 4 MiB L3 na jadro s latenciou 40 cyklov alebo 3 MiB s latenciou 30 cyklov - to su tie v clanku opisane vhodnosti/nevhodnosti na mensie/vacsie dlazdice)
- architekturru cache (L2 zdielana medzi 2 fyzicka jadra, pocet fyzickych jadier medzi ktorymi sa zdiela L3 atd)
... ale bohuzial nezijeme v idealnom vesmire a dosledok je ten, ze 96C192T procak to zatazi iba na 67%
co dodat
V clanku jsou teoreticke uvahy nepodlozene merenim.
Pokud mensi dlazdice maji mensi naroky na cache a tudiz je to optimalnejsi zatez, proc neni CB23 odpocatku provozovan na malych dlazdicich?
Ad cache u RT - ma vyznam jedine sdilena, kdy ruzne CPU a ruzne dlazdice budou mit spolecnou geometrii kterou lze cachovat. V ramci jedne dlazdice je totalne jedno jaky ma rozmer, protoze RT funguje per pixel - a zda dohledate 100 pixelu vedle sebe nebo 1000 neudela nijak signifikantni rozdil.
A proto rikam - dejte sem konkretni mereni, jak JEDEN faktor ovlivnuje vysledek, a neni dobre delat zavery z tak komplexne zmeny jako clanek popisuje.
Ze 96C/192T je zatizen jen z casti.. a vy to mate na Win? Aha.. tak si nejprve poridte normalni OS a ne nejakou omalovanou hracku. To je jak testovat lambo na polni ceste.
„Pokud mensi dlazdice maji mensi naroky na cache a tudiz je to optimalnejsi zatez“
Menší nároky na cache ≠ optimálnější zátěž.
Pokud se obsah dlaždice vejde do cache, nepřináší zmenšení dlaždice žádné pozitivum. Naopak je pro zpracování dané části obrazu zapotřebí uskutečnit (přinejmenším) vyšší počet datových přenosů (=nárůst režie, horší škálování s počtem jader).
Opakuji, dejte sem konkretni mereni kde se zmeni jeden jediny parametr, a netvrdte takove JPP "fakta" a nerozvijejte vase teorie kdyz ani neznate jak dana zatez funguje a jaky vliv cache ma. RT je totiz vicemene random memory read pattern a cachovani moc nema smysl. Predpokladam ze CB ma reprezentaci sceny udelanou optimalne, kdyz je to jejich denni chleba.
R7-5800X3D: 14221 pri 96 M cache
R7-5800X: 15316 pri 32 M cache
Pri brani do uvahy zmenu boost frekvence 4.35 vs 4.5, jsou prepocteny score:
R7-5800X3D: 14711 pri 96 M cache (a 4.5/4.35 faktoru)
R7-5800X: 15316 pri 32 M cache
Takze jisteeeee... cache ma na CB23 drasticky vliv. Ale asi negativni, pac vice znamena mene :))
ako som napisal, nezijeme v idelanom vesmire a podla mna by to chcelo riadne testy a optimalizaciu zo strany autorov SW, aby to bolo optimalizovane pre konkretnu radu CPU
dovtedy sa mozme zhodnut na dvoch veciach: 1) optimalizovane to teraz neni 2) mozeme to u tom akurat tak tliachat
:)
Problém je v tom, že ve světě měření nejde o získání největšího výkonu. Při měření jde o stejné podmínky měření, aby se výsledky daly porovnávat.
Dělá se to tak, že se dá procesorům stejná úloha. Pokud byste ale každému vláknu dal shodnou úlohu, CPU se sdílenou cache bude ve velké výhodě. Takže každému dáte stejnou úlohu, ale nad jinými daty. Problém přichází ve chvíli, kdy podmínky té úlohy měníte mezi testovanými procesory.
Že to procesor zatíží jen na 67%, není až takový problém. To je prostě omezení testovací metodiky, a je třeba to zohlednit při vyhodnocování výsledků. Ostatně některé části procesoru zůstávají zcela nevyužité, třeba video dekodér nebo jednotky pro AES-NI, a vůbec ničemu to nevadí. Pro ty jsou zase určené jeho metodiky.
Počet dlaždic by měl být shodný (nebo celočíselný násobek) s počtem výpočetních vláken, jde - li vám o srovnávání paralelního výkonu na všech vláknech. Vymýšlet sofistikovanější řešení tomu akorát ublíží.
Měření není úplně legrace, málo redakcí to umí dělat dobře. Diit je na tom z tohoto pohledu dobře, zdejší redaktoři vědí, jak testovací metodiky fungují, používají rozum, své názory nebo dedukce zdůvodňují.
Podmínka celočíselného násobku počtu vláken by měla smysl jen, pokud by zpracování každé dlaždice každým vláknem trvalo stejně. To ale v žádném případě platit nebude. Každá dlaždice má jiné výpočetní nároky a každé vlákno má jiný výkon, tak nikdy nepojedou a nebudou končit všechny zcela paralelně.
Bude taky záležet na způsobu modelování světa a jeho sdílení mezi vlákny. Jestli se obsah dlaždice počítá nezávisle na ostatních, nebo se už jednou provedená práce sdílí mezi dlaždicemi, které jsou ovlivněny stejnými částmi virtuálního světa.
„A kde je problem tomu 8C a 128C cpu nastavit stejny vysoky pocet malych dlazdic?”
To by R23 musel používať 9000+ dlaždíc od začiatku a taký Celeron G1820 by ich počítal hádam cez hodinu :D. C2Q
Veľkosť dlaždice je dôležitá. Jednak je to v článku a IMHO väčšia dlaždica môže byť rel. jednoduchšia na spracovanie ako viac menších (vo väčšej môže byť pod. častí, ktoré sa spracujú súčasne 1 vlákno a nie viacerými vláknami).
>Řada zdrojů si tyto limity neuvědomuje, a tak jsme se v souvislosti s testem
>128jádrové konfigurace Zen 5 mohli setkat s názorem, že vlastně Zen 5 dosahuje >o 50 % vyššího výkonu na jádro než Zen 4 a to jde teprve o vzorek, takže finální
>výkon bude jistě ještě mnohem vyšší(!!!). Skutečně ne. Problém je pouze v tom, >.., takže výkon na vlákno ve skutečnosti u testovaného vzorku Zen 5 dosahuje jen
>o procenta vyšší hodnoty než u sériově vyráběného Zen 4. Zkrátka jak se dá u
>vzorku ve stavu rok před vydáním očekávat.
Ono sa za 9 rokov veľ nezmenilo v softvérovej podpore pre multicore CPU, ale tento týždeň AMD v tejto oblasti, kde tradične zaostáva, zažiarilo. Je pomerne zaujímavé vidieť, že AMD sa zlepšuje aj tu
Software needs meaty cores, not thin, stringy ARMs, says Intel
Wed 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.”
https://www.theregister.com/2014/02/26/software_needs_meaty_cores_not_th...
Lucky 13? AMD Pensando Elba SoC Linux Enablement Revised The 13th Time
in AMD on 11 April 2023
https://www.phoronix.com/news/AMD-Pensando-Elba-Linux-13
AMD Phoenix Support Progressing For Coreboot, New Google Chromebook Added
on 11 April 2023
https://www.phoronix.com/news/AMD-Phoenix-Coreboot
Mesa 23.1 RADV Change Leads To ~60% Smaller Single File Disk Cache
on 11 April 2023
https://www.phoronix.com/news/Mesa-23.1-RADV-Smaller-SF-Cache
AMD CPUs Are Safe For Late-Loading Microcode, Will No Longer Taint The Linux Kernel
on 11 April 2023
So with this pending patch, the CPU microcode updating on late-loading will only trigger a kernel taint for non-AMD systems. Ideally though all CPU microcode updates should be early-loaded during boot time.
https://www.phoronix.com/news/AMD-Late-Loading-Microcode
Mesa 23.1 RadeonSI Enables Rusticl OpenCL Support
on 12 April 2023
Benchmarks previously carried out by Karol (Herbst) have indicated Rusticl outperforming ROCm OpenCL at the time.
https://www.phoronix.com/news/RadeonSI-Rusticl-Mesa-23.1
AMD Details openSIL For Advancing Open-Source System Firmware
on 13 April 2023
AMD is committed to open-source software and is now expanding into the various firmware domains with the re-architecture of its x86 AGESA FW stack - designed with UEFI as the host firmware that prevented scaling, to other host firmware solutions such as coreboot, oreboot, FortiBIOS, Project Mu and others. A newer, open architecture that potentially allows for reduced attack surface, and perceivably infinite scalability is now available as a Proof-of-Concept, within the open-source community for evaluation, called the AMD openSIL – Open-Source Silicon Initialization Library."
AMD openSIL is a set of three statically linked libraries – xSIM (x86 Silicon Initialization Libraries), xPRF (x86 Platform Reference Library) & xUSL (x86 Utilities & Services Library)
https://www.phoronix.com/news/AMD-openSIL-Detailed
AMD Brings ROCm to Consumer GPUs on Windows OS
09:48
https://www.techpowerup.com/307259/amd-brings-rocm-to-consumer-gpus-on-w...
Co?
Mam rad Vase kratke komentare, ale tohle je opravdu pro bezneho cloveka, i pri trochu vetsi nez bezne snaze, neuchopitelny myslenkovy proces. Nemuzete prispevky zkratit? Vase kratke prispevky jsou vetsinou k veci, tento prispevek taky (po rozkliknuti par odkazu a sledovani toku celeho prispevku), nicmene "effort", ktery jsem pro porozumneni celemu prispevku musel vyvinout, ma velice spatny pomer cena/vykon...
Nojo to je pořád mínusů, pokaždý když tu napíšu, že testovat CPU Cinebenchem je blbost... :-)
Ja ted testoval svoji sbirku sestav na CPH (compiles per hour) ale je to takovy med kolem huby. Takze jsem presel na C/kWh (compiles per kWh) a to je hned jina... a ted to musim projet znova na ruzne frekvenci at se najde sweet spot.. protoze defaultni boosty jak u AMD tak u Intelu stavi vsechno moderniho v tomto sportu fakt na posledni mista.
Zahrnutí přepočtu výkonu/doby běhu úlohy na 1kWh považuju za možná jedinou rozumnou cestu jak recenze obohatit. Samozřejmě s dodatkem, že sice třeba Cinebench hypoteticky proběhně v nejvyšší efektivitě na pidiARMíčku v nějakém Raspberry, ale nikdy nikdo nebude chtí čekat na výsledek 100x déle neže s hladovým Intelem.
Tak ono existuji i 2D grafy - tak se daji ty vysledky namapovat jako body v prostoru a pak si muzete vybrat zda preferujete reseni nad nebo pod uhloprickou. Ostatne by to tak melo byt u kazdeho testu, co poskytuje dvoji metriky - zde jsou primarni merene hodnoty - cas kompilace a odebirany vykon (spravneji by to chtelo lepsi merak a resit odebranou energii).
Akurat to chce vypracovat lepsi metodiku, protoze jsem koukal na wattmetr a opsal proste max, kdyz byl boost na max frekvenci a tam se i drzel.
Az pak prisel na radu i9-10900K tak mi do toho hodil vidle s tim TVB, ze to pul minuty jelo rychleji-zraveji a pak zbytek testu uz normalne. V me uloze to bylo tusim 30-60sec z 3.5 minuty. Nastavovat to nemuzu (chlazeni by ten max dalo, teploty to neukazoval nijak vysoke - ale ted ctu ze je podminka <70st. ), no.. je to DELL komp s marnym biosem, se divim ze tam davaji K cpu kdyz ten bios neumi vubec zadny OC.. ale coz.. ten cpu se uz nejak vytoci i sam.
Ja by som nepovedal, ze je to blbost. Len ten vysledok treba brat v kontexte. Zobecnil by som ten vyrok tak, ze porovnavat CPU na zaklade jednneho konkretneho testu je blbost. S vynimkou pripadu, ak to CPU prave na ten konkretny ucel chcem pouzivat.
Pre ludi, co v Cinema 4D renderuju je ten test stale vysoko vypovedny a to, ze sa "zmeni testovacia metodika" je uplne irelevantne, pretoze je ten test vysoko reprezentativny realnej zatazi.
Tak to je fakt blbý, když je těch vláken tolik, že už je neumí pořádně využívat už ani programy pro rendering. :D
Rok cca 2002.
"Linux už umí menežovat 65 536 výpočetních vláken!"
"A už vám na Linuxu funguje Flash?"
"Ne, to někdo potřebuje?"
...
Rok 2023:
Chachá. Naše chvíle konečně přišla :-D
To, že nejsou zcela srovnatelné výsledky testů mezi procesory s různým počtem vláken neznamená, že programy neumějí víc vláken využít. Kromě toho vyšší počet vláken obvykle nevyužívá jen jeden program.
Taky vícejádra nejsou procesory pro BFU, kterým běží nanejvýš internetový prohlížeč, textový editor a možná ještě přehrávání muziky na pozadí. Ale třeba na pracovní stanici architekta nebo konstruktéra a ten výkon občas hodit může.
".. na pracovní stanici architekta nebo konstruktéra .."
poběží CPU většinu času na jedno jádro (+nějaké drobnosti kolem samotného OS).
Tímto pozdravuji AutoCAD & Co.
Autocad dela jednojadroce i rendrovani 3d scen a pripadne animaci :-O ? To jsem myslel, ze jsou za tu spoustu let, co jsem s nimi nemel kontakt, preci jen kousek dal.
Nedalo mi to a zkusil jsem dohledat, jak na tom ten autocad je. Podle jejich podpory (viz odkaz dole) bezi nektere veci vicevlaknove. Ale je otazka jak moc a od kdy. Prehled v odkazu je pro aktualni verzi 2023 a nasel jsem zminky i o verzi 2020.
Nevim jaka je licencni politika, ale cekal bych rocni poplatek a placeni i za prechod na novejsi verzi. A tak lidi, kteri vystaci i s vykonem starsich verzi, mozna opravdu jedou jednojadrove vsechno vcetne 3d vizualizaci, protoze naklady na novou verzi by pro ne mohly byt vyssi, bez prinos z vicejadriveho zpracovani.
https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfd...
Licenční polilika Autocadu je dokonale user unfriendly (aneb opakovaně plať jak mourovatej) - momentálně jenom předplatné, trvalé verze se přestaly pár let zpátky prodávat. Pokud máš předplatné tak můžeš jít na nejnovější verzi, nestojí tě to nic navíc, pokud trvalou, tak máš nějakou starou prehistorii.
Napadajú ma 3 riešenia:
1. U veľajadrových CPU testovať len polovicu. Síce výkone nebude reálny, ale bude odpovedať reálnemu výsledku polovici jadier. Teoreticky ×2 a máme predstavu o výkone.
2. Spustiť dva inštancie benchmarku a každému priradiť natvrdo polovicu jadier.
3. Nemeniť veľkosť dlaždice, ale počet dlaždíc a výsledok bude počet vyrenderovaných dlaždíc/čas. Šlo by to? Samoz. súčasné výsledky by sa nedali porovnať, ale dalo by sa to použiť v ďalšej verzii CineBench.
1) blbost, protoze polovina jader bude mit jinej boost nez plny pocet. Treba pro intely je na wikipedii vzdy ke kazdemu modelu napsanej boost jako cislo N x100MHz pri vytizeni jen 1..X jader.
2) tohe je potreba jenom na win, ktere nezvlada moc vlaken v jednom procesu
3) zbytecny, staci test zastavit na dobehnuti prvniho vlakna, a pak vzit progress zbylych vlaken a z toho extrapolovat vysledek.
Porad si ale myslim ze CB RT uloha nema ruznej vysledek mezi malymi nebo velkymi tiles a zalezi spis na tom, jak se obslouzi corner case, kdy na konci testu je cpu vytizen jen castecne a ceka se na posledni thread a tile. Vi se, ze jakym zpusobem bere CB do uvahy ten konec? Nebo proste pocita jen cas, ktery je od prvniho po posledni aktivni thread? To by zkreslovalo vysledek mnohem vice nez velikost tiles..
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.