Vyznam dual core

[Eagle]

Tak 1. Tyto 3D programy vyuzivaji MultiCore pri RENDERINGU, to je to co zpomaluje praci grafiku.

Jistě. Jenže je taky spousta profesionálního software, kde hlavní roli má grafická karta a CPU je až druhořadý. Ostatně můžeš si to vyzkoušet na SPECviewperf, což je průmyslově uznávaný benchmark těchto nástrojů - procesor tam má poměrně malý vliv.

2. Nevim co to ma spolecneho s tim, ze je podle tebe DualCore k nicemu ?

Že by to byl argument na to, že Intel a AMD dělají dual-core kvůli výkonu?

3. U kompilace je predevsim problem CPU Az zacnes jako ja kompilovat bakalarku se 150 projektama, ktere i na X2 zabere 20 minut, tak poznas, ze HDD ti zacne byt bottleneck teprve az pri linkovani a tam uz jeksi nejde o zatez CPU protoze v tu dobu jsou jiz potrebne projekty prekompilovane.

Jen 20 minut? Nic proti, ale já už kompiloval věci, které trvají víc jak hodinu. A můžu s klidem prohlásit, že když spustím dvě kompilace paralelně vedle sebe, že jde hodně o výkon pevného disku. Ostatně pevný disk je extrémní limitací u většiny programů nějak přistupujících na disk - například u RARu zrychlí bufferování vstupu a výstupu práci klidně o 50 %.

Pořád jsi nedoložil to tvoje tvrzení, že na vícejádrových počítačích kompilátor jede projekty paralelně.

4. Moje vyjadrovani je zcela a naprosto v poradku. Dalsi snaha od tebe tu vyvolat flame.

Tvoje vyjadřování je pro mě pouze snahou na sebe upozorňovat a dokazovat tady ostatním, že seš velkej machr. Pokud ti nepřijdou urážky ostatních členů fóra jako jasný příklad nevychovanosti, je mi tě upřímně líto. Budeš to mít v životě těžké.

[Haste]

1. No to samozrejme je spousta i takovych aplikaci. Copak ti tohle nekdo vyvraci ? Rec je o vyuzitelnosti multicore a ty se zacnes bavit o programech ktere jsou zavisle na grafice ? Vtipne...

2. Presne ! Kvuli vykonu ! A proto je nesmysl tvrdit ze je multicore k nicemu !

3. Tak to opravdu nevim jak nebo co si kompiloval(jestli vubec). Ani nevim procs poustel 2 kompilace paralelne vedle sebe. Kompilery se totiz samy vetvi podle zanorenosti projektu do sebe pricemz kazdy projekt pak dostane vlastni thread. Pricemz v idealnim pripade je to opravdu az thread na projekt. Nicmene si pak staci pouzit MS VisualStudio 7.0-8.0(alias 2005) a podivej se na TaskManager na vyuziti jader, to ti snad jako dukaz staci, ne ? A rozhodne HDD je bottleneck jenom u linkovani, to mi muzes verit Pokud prekladas projekty, potom se veskery kod projektu da do pameti (zdrojaky maji obvyke do 1MB/projekt) a to rozhodne HDD nepretizi ) Teprve az pri linkovani se vytvareji OBJecka (a jine debug soubory) ktere uz maji i nekolik desitek MB a teprve tento linking pretezuje disk !!! Ale to uz sme uplne jinde. Nebudu ti tu vysvetlovat jak funguje kompiler ve VisualStudiu.

4. Na flame veci neodpovidam.

[Eagle]

1. No to samozrejme je spousta i takovych aplikaci. Copak ti tohle nekdo vyvraci ? Rec je o vyuzitelnosti multicore a ty se zacnes bavit o programech ktere jsou zavisle na grafice ? Vtipne...

Pokud jsi to stále nepochopil, tak se bavíme o využitelnosti dual-core. Já tvrdím, že drtivá většina programů takový procesor není schopna využít. Připouštím, že existují určité profesionální a multimediální aplikace, které z toho mohou těžit. Zároveň ale říkám, že mnoho z těch profesionálních aplikací je závislých na výkonu grafické karty a že některé multimediální aplikace by mohly v budoucnu těžit z výkonu grafických karet, který je pro tyto účely podstatně vyšší než ten, který dokáže nabídnout jakýkoli vícejádrový procesor.

2. Presne ! Kvuli vykonu ! A proto je nesmysl tvrdit ze je multicore k nicemu !

Jsi velmi naivní. Jediné, co Intel a AMD sledují, je finanční ukazatel zvaný zisk (přesněji řečeno ROE a EPS). Jim nejde o žádný výkon. Rychlejší procesory jsou uváděny jen proto, že zákazníka zajímá (zjednodušeně řečeno) poměř výkon/cena, tudíž ten, kdo přichází s rychlejším procesorem, mu může nasadit vyšší prodejní cenu, tj. vydělat víc. Dokud bylo možné získávat vyšší výkon zvyšováním frekvence, žádné dvoujádrové procesory nebyly. Dual-core je pouze důsledkem toho, že výrobci nejsou schopni zvyšovat výkon vyšší frekvencí. Proto se snaží obalamutit zákazníky vyšším výkonem v některých specifických programech (... které málokdo používá), ovlivňováním benchmarků a přirozeně taky vydáváním hypových tiskových zpráv, ukázkových testů atp.

Ani nevim procs poustel 2 kompilace paralelne vedle sebe.

Že by na zkoušku?

Kompilery se totiz samy vetvi podle zanorenosti projektu do sebe pricemz kazdy projekt pak dostane vlastni thread.

U projektů netuším, protože obvykle kompiluju věci, které mají jen málo projektů (max. tak kolem pěti). A ty se na mém CPU kompilují postupně. To je ostatně vcelku logické, neboť některé výstupy vyžadují .lib z jiných projektů, tudíž kdyby se kompilovalo paralelně, muselo by se na finalizaci .lib počkat. BTW, pořád jsi nedodal důkaz, že na dual-core se to bude chovat jinak.

Pokud jde o kompilaci .cpp, tak ta probíhá samozřejmě postupně a to i na dual-core. Počet threadů je přirozeně vždy roven jedné, neboť každý soubor se kompiluje individuálně a je pro něj separátně spoustěn cl.exe (spustí se, zkompiluje, vypne se). IDE v tomto ohledu slouží jen jako volání cl.exe.

podivej se na TaskManager na vyuziti jader, to ti snad jako dukaz staci, ne ?

Počet threadů = 1.

A rozhodne HDD je bottleneck jenom u linkovani, to mi muzes verit

Tak to ti teda rozhodně věřit nemůžu, když to tak není. Když si spustím paralelní kompilaci více projektů zároveň, zátěž na čtení .cpp a zápis .obj je natolik velká, že to kompilaci každého z projektů začne zpomalovat.

Teprve az pri linkovani se vytvareji OBJecka

*.obj vytváří přímo kompilátor - je to strojový kód funkcí. S linkerem to nemá nic společného.

Rad bych pripsal poznamku o vyuziti dual-core. Dejme tomu, ze ve specifickych testech je jejich prinos diskutabilni, ale co takhle bezna prace s PC jako programovani, testovani, virtualni masiny (tj. misto kde opravdu bezi vic aplikaci naraz)? Nebo myslis, ze si vsichni prispivajici v tomto threadu vymysleji?

Přínos je naopak diskutabilní při běžné práci, neboť prakticky neexistují vícevláknové aplikace se zátěžovými vlákny. A pokud ano, přínos není právě ohromující (v řádu třeba + 10 %). Ve specifických testech je nárůst výkonu daný tím, že tyto testy jsou pro dual-core optimalizovány (... za což kupující takového software řádně zaplatí).

ad thread - stejně tak znám lidi, kteří rozdíl při přechodu na dual-core nepoznali. Faktem je, že záseky Windows existují i na dual-core a že pokud chceme provozovat nějakou aplikaci na pozadí, dá se to ve většině případů snadno vyřešit prioritami. Ostatně dual-core v tomhle není záchrana, protože jakmile si budu chtít spustit na pozadí dvě aplikace nebo budu mít jednu multithreaded, mám hned stejný problém.

[SajmoN]

nie ze by som vas chcel rusit pri vasich erudovanych debatach, ale nemohol by niekto vyseknut tento offtopic ako napr "Ma multicore zmysel?" aby sem clovek neliezol zbytocne zakazdym a nasiel tu len dalsi offtopic?

[Haste]

1. "Připouštím, že existují určité profesionální a multimediální aplikace, které z toho mohou těžit."

No tak slava, MultiCore tedy neni na ......

2. Nejsem naivni. K me praci je DualCore neocenitelny. Preklad se mi zkratil z 55 minut s Bartonem na 20m s X2. S C2D sem to jeste nemeril.

3."U projektů netuším, protože obvykle kompiluju věci, které mají jen málo projektů"

No ten zbytek si pak vubec psat nemusel, protoze v ramci 1 projektu je samozrejme 1 thread.

"Tak to ti teda rozhodně věřit nemůžu, když to tak není. Když si spustím paralelní kompilaci více projektů zároveň, zátěž na čtení .cpp a zápis .obj je natolik velká, že to kompilaci každého z projektů začne zpomalovat."

Natolik velka Teda to nevim co mas za disk, ale ujistuji te, ze s beznymi disky co maji vic jak 40MB/s NENI HDD bottleneck pri kompilovani. Nehlede na fakt, ze .cpp uz jsou v te dobe davno v pameti a dochazi pouze k zapisu do .obj a to je opravdu pouze par MB/s na projekt.

"Teprve az pri linkovani se vytvareji OBJecka"

Ano, to priznavam, to sem se prepsal. Chtel sem tim rict, ze az pri linkovani dochazi k prochazeni OBJecek a .lib a tim parsovanim se pak zacne pretezovat disk.

[Eagle]

No tak slava, MultiCore tedy neni na ......

Běžnému uživateli používajícímu normální programy (vyjma komprese videa) je. Mnohem větší přínos vidím v Raptoru a hodně RAM.

2. Nejsem naivni. K me praci je DualCore neocenitelny. Preklad se mi zkratil z 55 minut s Bartonem na 20m s X2. S C2D sem to jeste nemeril.

Kolik z toho času připadlo na upgrade architektury a třeba zvětšení RAMky? Obecně je v tomto K8 vcelku o dost rychlejší než K7 díky rychlejší L2 cache a kratší latency do RAM.

"No ten zbytek si pak vubec psat nemusel, protoze v ramci 1 projektu je samozrejme 1 thread."

Už poněkolikáté tě žádám o důkaz, že se na vícejádrových procesorech projekty kompilují paralelně. Dělá ti to takový problém?

"Natolik velka Teda to nevim co mas za disk, ale ujistuji te, ze s beznymi disky co maji vic jak 40MB/s NENI HDD bottleneck pri kompilovani. Nehlede na fakt, ze .cpp uz jsou v te dobe davno v pameti a dochazi pouze k zapisu do .obj a to je opravdu pouze par MB/s na projekt."

Bottleneck to je a to kvůli seeku, který je příliš pomalý. Také potřebuješ hodně RAMky. Ono to nevypadá, ale zkus si to. To samé jsem si myslel o RARu - pár MB/s. Jenže taky prefetch do RAM dokáže zrychlit kompresi neuvěřitelným způsobem.

Ano, to priznavam, to sem se prepsal. Chtel sem tim rict, ze az pri linkovani dochazi k prochazeni OBJecek a .lib a tim parsovanim se pak zacne pretezovat disk.

Že má linker velkou zátěž, to se nepřu. Jak ale říkám - ke zpomalení dochází i při kompilaci. Výjimkou může být situace, kdy máš hodně RAMky, protože pak Windows bufferují zápis, tj. na disk se zapisuje až se zpožděním v době nevytížení.

[Haste]

Už poněkolikáté tě žádám o důkaz, že se na vícejádrových procesorech projekty kompilují paralelně. Dělá ti to takový problém?

Dela mi to problem, protoze nevim jaky dukaz chces. OK, muzes to udelat takto: Kup si MSVC++ 7.1 a lepsi (pripadne + STL port) . Stahni si zdrojaky k OpenSceneGraph. (Ten je velky dostatecne ). Dej si batch build, pripadne prekompiluj cely solution. Sleduj pri tom vyuziti CPU na multicore systemech, jakmile dojde k vetsimu zanoreni projektu uvidis vyuziti 100% i na 8 jadrovych systemech. Staci ?

A k te RAMce. Samozrejme se bavime o systemech, kde neni bottleneck RAM. Tj. systemy s 1GB RAM u mensich projektu a 2GB+ u vetsich (jako treba onen OSG), to sem predpokladal jako samozrejmost.

[JaCK4L]

Necital som celu predoslu diskusiu, tak dufam ze nebudem opakovat, co tu padlo. Co sa tyka profi 3d grafickych programov (3ds max, Maya apod.), treba rozlisit 2 veci: 1) renderovanie vo viewporte (realtime modely) a 2) samotne renderovanie (ziaden realtime). Pre viewporty je dolezita graficka karta (+ RAM pre samotny program), da sa merat FPS, benchuje sa napr. pomocou spominaneho SPECviewperf-u, procesor ma prakticky 0% vyznam. Pre renderovanie je vsak dolezity CPU (tiez aj RAM na spracovanie dat pred renderovanim, pocas a po) a dnesne 3d softy (nativny Scanline renderer v 3ds max nie, ale bezne pouzivane mentalRay, V-Ray, finalRende atd. podporuju multi-core, a viac jadrove procesory su velmi silne pocititelne. Vyuziva to sice len minorita pouzivatelov IT, do ktorej patrim aj ja a na dulacore nedam dopustit.

Existuju este hybridne riesenia, napr. nVidia Gellato - pre renderovanie sa vyuzuiva graficka karta, ale zo skusenosit z okolia viem, ze je to na ho***. Potrebuje silne zazemie zo strany softwaru (rendereru), ktory musi byt prepisany a ani vykonovo to nie je to, co sa predpokladalo.

Skratka, pre mna osobne, dualcore je vyhodny, dokazem vyuzit jeho potencial, ale vacsina uzivatelov to v sucastnosti nevyuzije, aspon nie do doby, kym bude vacsina (bezne pouzivanych) aplikacii prisposobena pre viacjadrove procesory.

[Fox!MURDER]

samozrejme netusim, co to buildite za megazdrojaky, ale tohle jako benchmark imo staci

du -chs php-5.1.6
55M     php-5.1.6

#time make -j3
real    1m45.039s
user    2m32.660s
sys     0m32.264s

#time make -j2
real    1m49.142s
user    2m31.504s
sys     0m31.316s

#time make -j1 
real    3m2.027s
user    2m30.559s
sys     0m31.578s

kdyz budu mit cas, benchnu jeste neco vetsiho ... treba zdrojak gcc ...

rozhodne ale v tomhle DC prinos je (teda je to testovano na dual-nocona 3.2G ale vykonovej rozdil oproti DC je minimalni)

[Eagle]

Dela mi to problem, protoze nevim jaky dukaz chces.

Bohatě by mi stačil link na nějakou stránku, kde o tom píšou.

2Fox!MURDER: GCC je především pro Linuxovou komunitu, na Windows (... které mají mimochodem cca. 99 % zastoupení na PC) jsou klíčovou aplikací Microsoft Visual C++ a Borland Delphi. A tyto nástroje, pokud vím, neumí kompilovat víc souborů paralelně vedle sebe.

[xjohny]

Že by to byl argument na to, že Intel a AMD dělají dual-core kvůli výkonu?

Rad bych pripsal poznamku o vyuziti dual-core. Dejme tomu, ze ve specifickych testech je jejich prinos diskutabilni, ale co takhle bezna prace s PC jako programovani, testovani, virtualni masiny (tj. misto kde opravdu bezi vic aplikaci naraz)? Nebo myslis, ze si vsichni prispivajici v tomto threadu vymysleji?

[tomase]

presne tak. Pokial je moj subjektivni pocit pri praci lepsi, aj ked synteticky test ukaze nieco ine, kupim si DC namiesto SC, pretoze clovek proste dava na pocity

[Yogi_1]

100% pretakt na vzduchu!
E6300, ASUS P5B DLX, Big Typhoon
http://valid.x86-secret.com/show_oc.php?id=120669