flops = floating point operations per second , tj. počet operací procesoru při práci s čísly s plovoucí desetinnou čárkou za sekundu .. aneb operace s desetinnými čísly. Teoretický výkon současného C2D 2,93GHz psal někdo o kus výš ­(47 GFLOPS­)..

Pokud vezmeme starsi 2 GHz verzi A64 3000+ a jednoduchou presnost floatu ­(32bit­), tak bude vypocet nasledujici: 2 000 000 000 ­(frekvence­) * 2 ­(nasobicka, scitacka­) * 2 ­(64­-bitova SIMD pipeline­). Vysledek je tedy 8 GFlops.

Neni nad ­"zdravy­" optimismus :­-­)­) aby tohle byla pravda musel by ten proc mit 2GB interni cache s rychlosti pristupu jakou ma proc jenom do svych registru, pak by jednu sekundu dokazal pracovat touhle rychlosti, ovsem pak by musel vysledky vysypat do RAM coz je zdrzeni v radu stovek milisekund dane rychlosti ­(pomalosti­) sbernic a... je to moc pekne. V realu se tyhle faktory prolinaji takze problem neni tak zrejmy, ale je to moc pekne, takova cisla.

;­-­) ne nadarmo je ta hodnota pouze TEORETICKÁ, tj. vypočítaná, ne změřená.. Btw. k té cache ­- kdo říká, že zrovna na dosažení takového množství operací bude cache potažmo paměť vůbec využívat? Stačí, aby jednoduché násobení probíhalo mezi registry a latence je zanedbatelná :­-­) I když by to ve své podstatě neudělalo vůbec nic užitečného :­-D

Mam bohate zkusenosti s rucnim psanim optimalizovaneho SSE kodu. V urcitych typech vypoctu, kde neni nutne pracovat s velkym mnozstvim dat ­(takze se vejdou do L1­) se da dosahnout realneho vypocetniho vykonu blizkeho tomu teoretickemu.

Jo, silne mi to pripomina vykony P.M.P.O. co se udavaji u aususovych reprobednicek, kolik procent z celkoveho casu behu ralneho procesoru muze byt tento vykon udrzovan ? ­(ted neberu v potaz prinos SSE na vykon jako takoveho­), naproste mizive procento v beznych ulohach a i ve specialnich to nebude vubec slavne.

Pokud se zoptimalizuje hlavni smycka hlavniho algoritmu ­(treba renderingu, ­(de­)komprimace, sifrovani, simulace atd.­), tak to klidne muze predstavovat 99 % vypocetniho casu.

No, nyni je dobre videt ze jsi vubec nic z toho co jsem psal nepochopil.

:­-­) a jaké máš ty praktické zkušenosti s optimalizací kódu? To, co napsal x_R je osobní zkušenost a konkrétní příklad, kdy praktickžý výkon téměř odpovídá teoretickému. Ty jsi zatím nabídnul akorát hromadu obecných keců...

Tak teď ses priznal taky, kecale, navrhnuls tak leda velke kulové. ­(­"téměř­" ­- magické slovo které dovoluje neomezeně lavírovat a slovíčkařit­) Já třeba dával dohromady MMX filtrování obrazu ale že by výkon odpovídal ­(měl odpovídat­) na 99% teoretickému to je vážně komické.
Ono to bude jinak, na 99% si pletete celkovou dobu běhu procesoru a celkový výpočetní čas procesoru. Jakou školu přesně studuješ ?

Pojmem ­"blizkeho­" jsem myslel tak 80­-95 % teoretickeho vykonu daneho procesoru. Samozrejme se musi optimalizovat zvlast pro konkretni architektury a nejlepe pro konkretni jadra. Tento optimalizovany kod muze podle ulohy bezet az v 95­-99% vypocetniho casu procesu.
S tim MMX mate pravdu, tam to tak dobre nejde. Ja jsem mluvil o floating­-point SSE­(2,3­), ktere je navrzene a implementovane lepe.

On to ale nebude ani pomocný komprocesor, ani nic podobného. Pokud se nepletu, Intel tento procák nevyvíjel pro komerční nasazení, ale jen tak sám pro sebe. Zkouší si na něm v praxi hlavně komunikaci mezi mnoha jádry a podobné věci, protože za nějaký ten rok ­(nejdřív asi za 5 let­) by se měli dostat na trh procesory s mnoha desítkami jader. Ty by však měli být mnohem komplexnejší, i když asi stále jednodušší, než ty současné.

Jo, to říká ale je to pravda ? v komplexním systému kde běří na stovky servisních prográmků by se užil spíš multiproc se stovkami jednoduchých jader, ono žádný program dneska není jednolajnový využívá hromadu knihoven služeb IO komunikace... a tohle všechno se může přerozdělovat bez větších problémů na víc než malý počet jader ;­-­) na úrovni jednotlivého programu pak není problém spouštět víc vláken až na úroveň per objekt, každý animový flash může vyfasovat svoje jádro, kdaždý pajdulák ve hře svoje jádro generující jeho AI, hlasový projev a pohyb, když bude v aréně pobíhat 50 pajduláků každý může vyfasovat svoje jádro, nebude se tak dělit o výpočetní sílu , nic nebude trhat a vše poběží ve stabilním framerate, nesdílená pásma jsou osatně už hudbou přítomného času, třeba v PCIex

Jo to je hezky takze ja budu mit ve hre npr 10000 tis postavicek a na to 10000 jader?? Oni prece nemuzou delat porad vic a vic jader ma to svfoje limity. Uz 60 jader je vic nez dost.

o tohle se ti převážne stará OS...aplikaci pouze naprogramuješ aby byla multitheardová a o víc se nestaráš­(zjednodušeně řečeno­) OS si pak sám určí které jádro co bude dělat­(taky zjednodušeně řečeno :D)

Pokud budou mět být postavičky velice autonomní a chovat se inteligentně+budeš požadovat aby jejich ­"mentální­" výkon nekolísal díky užírání času procesuru jiným processem opravdu budeš těch 10000 jader potřebovat. Ale protože počítače jsou o kompromisech a všichni si na kompromisy zvykly tak tenhle přístup asi ještě dlouho nehrozí, hlavně se tu bavíme o úplně jiné úrovni simulace která vyhrazený výkon vyžaduje, o úrovni která může ale nemusí být v budoucnu uživateli vyžadována.

a jak mezi sebou budou komunikovat? Už jen blbá kolize spritů by se dělala jak?

To asi bylo na mě že ... jak budou komunikovat ? no a jak dneska komunikuje několik zařízení využívající vyhrazená pásma PCIex ? prostě je to všechno připojený na exktrémně výkonný řídící prvek nebo několik prvků, První vtip je v tom že v případě PCIex je to hardwarová záležitost kdyžto multithreading v operačním sys je jenom softwarová emulace WH Druhý pak v případě desítek­/stovek.. jader a na nich běžících simulací pajduláků stačí přenášet jenom výsledky jejich ­"hloubání­" které jsou daleko méně náročné na přenos dat, obrazně řečeno místo neustálého přenášení stamilionů nervových vzruchů při simulaci ­"mozku­" se přenese jenom hlasový projev který je výstupem složitého extrémně datově náročného procesu, prostě, záleží jak hodně autonomě se pojme návrh těch jader. Na sprity nepotřebuješ 10000 jader, pokud opravdu potřebuješ kolidovat stamiliony spritů tak mě prvně řekni o co jde konkrétně.

Ale jak si myslíš, že by mezi sebou komunikovaly ty virtuální procesory ­(jádra­)? To v případě více vláken 1 procesu. Jak by se dělal přístup do paměti? To by bylo extrémně nákladné, přičemž by to rostlo exponenciálně s počtem jader.

"To by bylo extrémně nákladné, přičemž by to rostlo exponenciálně s počtem jader.­" Nebylo, kdysi stál jednoduchý počítač obsahující několik integráčů ještě víc než stojí dnes PC s desítkami složítých čipů které maji moho struktur které se dají nazvat sub­-jádra ­(nebo virtuální procesory ­(co to je virtuální procesor?­)­). Vše je jenom otázka zvládnutí technologie a tu se zvládat daří + jádra která byla nastíněna by vůbec nemusela být komplexní jako P4 ani by to nebylo účelné tzn. plocha využitého křemíku by vůbec nemusela být větší než je dnes, je to prostě jiný přístup k dělení celkového výkonu, dokáže vůbec někdo spočítat jaké jsou celkové režie systému win, managementu multivláknových procesů oraganizace a přesunu dat ? kdy každá úloha má stovky a tisíce ­"chapadel­" po systému ?

"Ale jak si myslíš, že by mezi sebou komunikovaly ty virtuální procesory ­(jádra­)? To v případě více vláken 1 procesu.­" Dle potřeby ale jak už jsem psal odevzdávaly by až výsledek pro globální úlohu takže nějaká výrazná komunikace vůbec nevzniká. Záleží jak se pojedná systém a programování aplikace, všichni roubují návrh procesoru na stávající systémy, zastaralý spůsob řešení a managementu úloh, to dá rozum že při tomto přístupu bude vždy někde ­"úzké hrdlo­". Někde se už projevuje nový přístup ale bohužel se k němu nedošlo ­"návrhem jak to udělat nejlíp­" ale evolučně, jedná se o grafickou kartu, její vyhrazený procesor ­(GPU­) se svou vyhrazenou pamětí ­(SRAM­) a vyhrazeným pásmem k hlavnímu procesoru PC ­(AGP­/PCIex­).

Doporučuju přečíst si něco od Hillise o Connection Machine. ;­-­) Třeba jeho disertaci – vyšla jako kniha ­(v Gradě­) tiskem i u nás. Což je něco, co se drtivé většině studentů ­(zahraničních škol­) s jejich pracemi nepoštěstí ani v Americe. ;­-)

Jestli se nepletu, tak Core 2 Duo na 2,93GHz má asi 47 GFLOPs ­(2 jádra * 2 FPU jednotky * 4 vektoroví SIMD * 2,93­), což je asi 27x méně, než onen 80­-ti jádrový procesor na 4 GHz. Ovšem v normálních aplikacích by Core 2 Duo rozsekalo tenhle 80­-ti jádrový procák na hadry. Jednotlivá jádra zde jsou velice primitivní a chybí jim všechny ty predikční fiňáry, Out of Order vykonávání instrukcí, a tak podobně. Je to podobné jak CPU vs GPU. GPU má mnohem vyšší teoretický výkon ­(asi 10x až 20x­), ale může ho uplatnit jen u jednoduchých paralelních operacích. Podobně je to s Cellem od IBM. I ten poskytuje teoreticky brutální výkon, ale jednotliivá jádra svou komplexností za PC proesory výrazně zaostávají.

:­-­) výborně, aspoň nejsem sám, kdo si to myslí :­-­) nejsi taky kolega z ČVUT?

.... no abych pravdu řekl, člověk ani nemůsí být z ČVUT, aby si tohle myslel ... :­) stací se trochu dívat a přemýšlet .... :­)



Jinak s výše uvedeným, naprosto souhlasím ..

:­-­) já jenom že jsme si s vektorovýma a paralelníma procesorama nedavno hráli a zkoušeli, na kolik taktů se dá srazit obyčejné násobení matic 10x10 :­-­)

Tak tak. IBM Cell je proste navrzen pro jiny ucel, v kterem ma opravdu brutalni vykon.

Pokud vím tak Cell má taky komplexní jádro které ovšem používá­-úkoluje několik jednoduchých jader jako určité univerzálnější DSP, takže až tak jednoduché srovnání nejde udělat.

Jo, ale to komplexní jádro není až tak komplexní... tuším je to něco jako G4, ale pracující in­-order ­/jsem četl­/. Výkon jako G5 s frekvencí něco přes 1 gigahertz ­- což trošku zklamalo lidi, co si hodili na PS3 linux...

No jo , linux už je taky rozežranej ;­-)

Jo, ale to komplexní jádro není až tak komplexní... tuším je to něco jako G4, ale pracující in­-order ­/jsem četl­/. Výkon jako G5 s frekvencí něco přes 1 gigahertz ­- což trošku zklamalo lidi, co si hodili na PS3 linux...

No jo ale to taky hodně odvisí od toho jakým způsobem je program zkompilován, když bude přeložen 80­-ti jádráku na míru a bude vhodně využívat jeho jednoduché instrukce tak ve výsledku bude mnohem rychlejší už jen kvůli počtu jednotek, na jednoduché instrukce se taky dá líp autmatizovaně optimalizovat ­(v assembleru se už aplikace nedělají­).

mozno setko ostatne su tam elektronky :)

a celý to i s elektronkama žere 89 W, viď ? :)

no a ne,sak aj predtym boli elektronkove pocitace,male,usporne a chladne :)

Jde o to, že t­\ jádétka jsou velice jednoduchá ... proto může kažté žrát jen cca 1w a vejdou se do 100mil tranďáků ....

Tak tak, není problém udělat slušné malé 32b jádro s cca. 20000­-25000 tranzistory a několika desítkami mW spotřeby. :­-­) Bohužel problém je v interfacingu a programování, takže honíme všechny ty pajplajny a branch predictory a instruction schedulery do neuvěřitelných rozměrů. ;­-­) Škoda, poněkud tím klesá výkon na jednotku příkonu, ale pro konvenční aplikace ­(a pro konvenční programátory­) s tím zatím moc hnout nejde.

Co je to málo ? existují 8bit procesory které maji jenom několik ticíc trandů, existují i 16­/32bit ­"spartánské­" procy, kolik se vejde do 100megatr takových procs ? třeba taková Motorola 68000 má cca 68000 trandů ­(což teda ještě není spartánský proc, jsou daleko jednodušší­) a je 16­/32bit, dokáže adresovat bez stránkování, má široké registry atd. žádný ojeb, tak těch by se do 100mega tranzistorů vešlo cca 1470 :­-)

Motorola 68000 je 32bitová od prvníkho modelu.

Samozdřejmě se nejedná o jádra nynějšího typu­(architektury­)!

asi tak :­-)

Jaký teoreticky maximální výkon jde vyrazit z 1W, tzn. jaký je fyzikální limit ? myslím ať je jakýkoliv jsou dnešní procesory v tomto světle uboze neefektivní.

http:­/­/www.aldebaran.cz­/forum­/viewtopic.php?t=805