Vyznam dual core

[Haste]

K tomu opravdu nemam co dodat, snad jen, ze by ses nemel michat do veci, se kteryma si nikdy nedelal. To, ze te bavi cist whitepapers k HW je tvoje plus, ale ty ses evidentne vitez uz predem

Tak 1. Tyto 3D programy vyuzivaji MultiCore pri RENDERINGU, to je to co zpomaluje praci grafiku. Graficky akcelerator na to nema ZADNY vliv. Klidne muzes pouzit grafiku, ktera nema vubec 3D akceleraci a renderer ti pobezi stejne rychle. Grafiku potrebujes pouze na modelovani a i tam je vetsi problem CPU pro vypocet iteraci krivek. Renderery FinalRender/MantalRay ci primitivni Scanline jsou naprosto SW a jejich narust rychlosti je takmer linearni s poctem jader. Nejdriv si o to neco zjisti nez zacnes psat, pro priste.

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

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. Opet nevis o cem mluvis.

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

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

[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

[cluzoe]

no mam problem po novej instalacii Win sp2 mi ide len jedno jadro na 100% druhe ide na 0% ovladac ACPI Multiprocessor PC mam z 1.7.2001
ked ho dam aktualizovat tak nic nenajde
no kto pomoze

[tomase]

screen z taskmanagera by helfol

[cluzoe]

mas ho mat!

[Eagle]

mas ho mat!

Využita jsou obě jádra. A jestli ti to jednovláknové programy nechává na jednom z CPU, buď jen rád!

[cluzoe]

Využita jsou obě jádra. A jestli ti to jednovláknové programy nechává na jednom z CPU, buď jen rád!

no ale je to citelne pomalsie a trha to! pri 100%

[tomase]

no ale je to citelne pomalsie a trha to! pri 100%

A aky program mas spusteny? Podporuje vobec multicore?

[Neo2199]

Ja si myslim ze jedini lidi kteri nedokazou pochopit vicejadrove procesory sou snad jenom hraci her, ktere ve vetsine sou psane pouze pro jedno jadro. Kdyzto clovek ktery dela i neco jineho nez hraje hry. Tak casto nepracuje jenom z jednou aplikaci ale z vice. Takze mu tam nemusi vadit ze je napsana pro jedno jadro. A pricemz aplikaci pro vice jader pribyva a pribyva takze nevim proc zahazovat Kentsfield. Myslim ze ma dobre predpoklady do budoucna. A dnesni vyuziti vicejadrovych procesoru se vzdy uplatni na servrech. Vim to z prace.

[Eagle]

Ja si myslim ze jedini lidi kteri nedokazou pochopit vicejadrove procesory sou snad jenom hraci her, ktere ve vetsine sou psane pouze pro jedno jadro. Kdyzto clovek ktery dela i neco jineho nez hraje hry. Tak casto nepracuje jenom z jednou aplikaci ale z vice.

Víc aplikací se dá v 95 % případů v pohodě ošetřit prioritami. A vzhledem k tomu, že dual-core přináš v průměru tak + 10 % i u současných optimalizovaných aplikací, vidím jeho přínos dost uboze. To si radši upravím priority a trošku počkám, za tu nižší spotřebu a možnost pasivního chlazení mi to jednoznačně stojí.