Vyznam dual core

[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)

[Haste]

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

Pekne, thx. Ja myslim, ze ani neni treba nic vic, toto jako prove snad bude stacit

[Fox!MURDER]

Pekne, thx. Ja myslim, ze ani neni treba nic vic, toto jako prove snad bude stacit

jo a jeste dodam odkaz na http://distcc.samba.org/

distcc is nearly linearly scalable for small numbers of machines: Building Linux 2.4.19 on a single 1700MHz Pentium IV machine with distcc 0.15 takes 6 minutes, 45 seconds. Using distcc across three such machines on a 100Mbps switch takes only 2 minutes, 30 seconds: 2.6x faster. The (unreachable) theoretical maximum speedup is 3.0x, so in this case distcc scales with 89% efficiency.

[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.

[SajmoN]

ty si zase musis uvedomit, ze na tomto fore su tieto cisla a pomery uplne ine ako v beznej vzorke obyvatelstva

[Fox!MURDER]

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.

jenze gcc je jen compiler ... ta dulezita komponenta tady je make ...
klidne bych to moh kompilovat iccckem, kdybych na nej mel licenci ...


Edit: a jeste, kdyz uz jsi u toho procentniho zastoupeni ... kolik z tech 99% windows pc ma nainstalovano MSVS ? 0.5%? a kolik z tech linuxovejch stroju pouziva gcc? 30%?

[Eagle]

jenze gcc je jen compiler ... ta dulezita komponenta tady je make ...

Tohle teda kompiluje paralelně projekty nebo přímo .cpp? VCPP má totiž nmake, který .cpp kompiluje postupně, čili u něj je dual-core na prd.

Edit: a jeste, kdyz uz jsi u toho procentniho zastoupeni ... kolik z tech 99% windows pc ma nainstalovano MSVS ? 0.5%? a kolik z tech linuxovejch stroju pouziva gcc? 30%?

S programováním bych to zas tak špatně neviděl, dělá to docela dost lidí. IMHO poměr bude podobný jako u práce s videem.

[Fox!MURDER]

Tohle teda kompiluje paralelně projekty nebo přímo .cpp? VCPP má totiž nmake, který .cpp kompiluje postupně, čili u něj je dual-core na prd.

jednotlivy c/cpp se kompilujou paralelne pokud uz jsou hotovy prequisity ... na ty se holt obcas musi pockat (jestli to ma i nejakou logiku, podle ktery to vybira co driv a co pozdejs, to nevim, natolik jsem to nestudoval, ale ocividne to dela docela good job). a i napriklad pokud kompiluju z notebooku pres distcc na dalsich dvou PC doma, tak mam minimalne 2nasobnej (vetisnou vetsi) speedup. takze disk to rozhodne nebrzdi.

S programováním bych to zas tak špatně neviděl, dělá to docela dost lidí. IMHO poměr bude podobný jako u práce s videem.

no nevim. na video dneska clovek nepotrebuje nic, krom klikaciho nastroje. na progrmovani uz precijen nejaky ty znalosti. teda nepocitam programovani stylem naklikam tam jeden formular, udelam z toho 10MB exac a prohlasim to za hotovy dilo. tam by se ten dc fakt asi neuzivil ... na to by stacil celer 600 ... stejne jako na veskery offisy, wordy, ekcely, etc.
jasne, velky vetsine lidi bude DC celkem k nicemu a kdyz uz neco, tak by uzivili HW akcelerovany video, nebo jiny vychytavky. to ze si oni koupej DC cpu ale je chyba toho, ze nemaj dost informaci. ale porad je tu par % uzivatelu (poweruseru), kteri multicore vyuzijou ... a pri dnesnich cenach si ho i koupej ...

[Haste]

A tyto nástroje, pokud vím, neumí kompilovat víc souborů paralelně vedle sebe.

To ses tak neshopny, ze si ani neprelozis to OSG co sem ti psal ? Tady mas screenshot, mas tam i vyuziti disku. Vyctes z toho, ze spikes na disk time jsou jenom pri linkovani nektereho z projektu pri kompilaci je jeho vyuziti kolem 20-60%. A jak vidis vyuziti je u obou jader prakticky stejne, protoze se pri buildu pouziva pocet kompiletu podle poctu jader(jak psal i FOX u make gcc). Pokud nedochazi k linkovani, tak je 100% casu bottleneck CPU. A vubec nechapu proc se tu snazis vsechno tak hloupe zpochybnovat. Zbytecne tu vyvolavas flamy a me obiras o cas, protoze to nedokazu jen tak prejit...