Vyznam dual core

[tomase]

OMG!!! Toto AMD len tak lahko nerozdycha...

[Eagle]

OMG!!! Toto AMD len tak lahko nerozdycha...

AMD může být naprosto v klidu. Více jader je úplně na ho***. Jediná aplikace, kde to může mít nějaký vliv, je kódování videa... tam se ale možná budou o slovo hlásit grafické karty, které mají mnohem vyšší výkon než tohle.

[Rainbow]

Este si pamatam, ako sa Sandra "optimalizovala" pre P4. V jednej verzii boli P3 rychlejsie ako P4 a v dalsej verzii to uz bolo "opravene"... Takze vztah medzi vysledkami zo Sandry a realnym vykonom je...ziadny.

[tomase]

AMD může být naprosto v klidu. Více jader je úplně na ho***. Jediná aplikace, kde to může mít nějaký vliv, je kódování videa... tam se ale možná budou o slovo hlásit grafické karty, které mají mnohem vyšší výkon než tohle.

"uplne na ho**o". To si asi ludia kupuju X2 a P-D a C2D len preto ze po veceroch nemaju co robit a peniaze trhaju na stromoch S tymi grafickymi kartami si myslel to "famozne" Atineviemco, co sa napokon zistilo ze za vsetkym je software?

Rainbow > Vysledok zo Sandry je len jeden z mnoha, na Tom's sa staci pozriet ze inde daval Kentsfield tiez slusny kotol.

[Eagle]

"uplne na ho**o". To si asi ludia kupuju X2 a P-D a C2D len preto ze po veceroch nemaju co robit a peniaze trhaju na stromoch S tymi grafickymi kartami si myslel to "famozne" Atineviemco, co sa napokon zistilo ze za vsetkym je software?

Udělal jsi nějaký test nebo jen podléháš hype? Já si dual-core vs. single-core otestoval a moje volba je jasná: single-core.

ATi to ještě nedodělalo. Grafická karta má podstatně vyšší SIMD výkon než CPU.

[misokgb]

Viac jadrove je LEN lepsie to je jasne. Len mozno nie dnes, teda nie je na to optimalizovany OS a programy... V buducnu je to jasne, ak KAZDA JEDNA aplikacia bude schopna vyuzit dve a viac jadier. Kentsfield je ozaj len na machrovanie, dnes je velmi malo programov, ktore to vyuziju... Najlepsie by asi bolo keby bol taky OS, ktory by aj program, pisany pre single core, nejak efektivne rozlozil do viac CPU, to by bolo ono

[Eagle]

Viac jadrove je LEN lepsie to je jasne.

Není pravda. Dvoujádrové procesory jsou v některých single-threaded aplikacích pomalejší než identické jednojádrové.

Len mozno nie dnes, teda nie je na to optimalizovany OS a programy... V buducnu je to jasne, ak KAZDA JEDNA aplikacia bude schopna vyuzit dve a viac jadier.

To jsem teda zvědavý, jak někdo donutí programátory kompenzovat neschopnost výrobců hardware a to bez jakékoli (finanční) náhrady. První dvoujádrový procesor přišel před rokem a půl a od té doby se výkon navíc nějak nedostavil.

Najlepsie by asi bolo keby bol taky OS, ktory by aj program, pisany pre single core, nejak efektivne rozlozil do viac CPU, to by bolo ono

Z principu není možné kvůli tomu, že instrukce se z pohledu programátora vykonávají v předem stanoveném pořadí.

[misokgb]

Není pravda. Dvoujádrové procesory jsou v některých single-threaded aplikacích pomalejší než identické jednojádrové.


To jsem teda zvědavý, jak někdo donutí programátory kompenzovat neschopnost výrobců hardware a to bez jakékoli (finanční) náhrady. První dvoujádrový procesor přišel před rokem a půl a od té doby se výkon navíc nějak nedostavil.


Z principu není možné kvůli tomu, že instrukce se z pohledu programátora vykonávají v předem stanoveném pořadí.

Sak s tym s tebou suhlasim, je tam slovicko KEBY Keby to je tak ako som napisal, vtedy je dvoj a viac jadrovy procak dobry... Ako osobne by som si kupil dualcore (keby na to mam) uz len kvoli odozve systemu

[Haste]

AMD může být naprosto v klidu. Více jader je úplně na ho***. Jediná aplikace, kde to může mít nějaký vliv, je kódování videa... tam se ale možná budou o slovo hlásit grafické karty, které mají mnohem vyšší výkon než tohle.

Tady ses opravdu, zase, dost shodil. Jak toto: "Více jader je úplně na ho***" muzes napsat ? A jeste takovym pubertackym zpusobem ? Co takhle 3DsMAX, Maya, Lightwave, encodovani a nemluve o serverech a profesionalnim vyuziti Intel i AMD pripravuji QuadCore protoze to je "na .....", ano, spravne. Osobne znam hodne developeru co na QuadCore dost horlive cekaji. Takove Intel/MS kompilery vyuzivaji pri prekladu vice projektu multicore az do mnozstvi projektu v solution a to je az nekolik set vlaken !!! To cos napsal je jak od nactileteho pubertaka, opravdu me to zaskocilo. Opet tady vyvolavas nesmyslne flamy takymto trapnym zpusobem...

[Eagle]

Tady ses opravdu, zase, dost shodil. Jak toto: "Více jader je úplně na ho***" muzes napsat ? A jeste takovym pubertackym zpusobem ? Co takhle 3DsMAX, Maya, Lightwave, encodovani a nemluve o serverech a profesionalnim vyuziti

Tento typ programů jistě využívá každý běžný uživatel. Škoda že žádného takového neznám. Mimochodem, tyto programy jsou často hodně závislé na akceleraci od grafické karty - rychlejší karta přinese mnohem víc výkonu než rychlejší CPU.

Intel i AMD pripravuji QuadCore protoze to je "na .....",

Protože neumí zvýšit výkon jiným způsobem. Když to ještě uměli, žádný dual-core nebyl, přestože technicky by nebyl problém ho tehdy vyrobit a ani by to nebylo drahé.

Takove Intel/MS kompilery vyuzivaji pri prekladu vice projektu multicore az do mnozstvi projektu v solution a to je az nekolik set vlaken !!!

To nemůžu potvrdit ani vyvrátit - máš nějaký důkaz? Co ale můžu s klidem prohlásit, že při kompilaci jednoho projektu je kompilátor MSVC rychlejší na jednojádru. Dokonce je to jeden z příkladů, kdy dual-core oproti single-core zpomaluje. I kdyby platilo, co tvrdíš, zátěž na pevný disk a RAM je při simultárním kompilování více projektů velkou limitací. A navíc spousta programů má buďto jediný projekt nebo jeden hlavní, který se kompiluje podstatně déle než ostatní.

To cos napsal je jak od nactileteho pubertaka, opravdu me to zaskocilo. Opet tady vyvolavas nesmyslne flamy takymto trapnym zpusobem...

Myslím, že by ses měl klidnit. Máš docela velký problém s chováním.

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

[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

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

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