Vyznam dual core

[tomase]

ach jaj, chyba ti zakladna znalost a to, ze nemozes porovnavat dve rozdielne architektury tj. Netburst v podobe D805 a Core 2 Duo v podobe E6600.

[PiT]

barjos:

Polopaticky povedane jedno jadro C2D zvladne viac operacii na takt ako P3 a to zvladne viac operacii za takt ako P4.

Krajsie je to vysvetlene v Eaglovych clankoch na svethardware.cz

[Eagle]

no to ale plati i naopak, ze?

Samozřejmě. Pokud chceš něco levně, tak přílišnou kvalitu neočekávej.

kde se vzal ten veliký rozdíl mezi dvoujádrovými procesory D805 a C2D E6600.

Důvodů může být hned několik:
- větší L2 cache (4MB vs. 1MB) a větší L1 cache (32kB vs. 16kB)
- rychlejší L2 cache (cca. 2x) i L1 cache (o 33 %)
- rychlejší přístup do paměti (odhadem o 20 %)
- jádro s větším paralelismem, více spekulativními výpočty, mnohem kratší dobou provádění instrukcí

Až na tu velikost cache by ti nejspíš to samé (v budoucnu) nabídlo jednojádrové Pentium a Celeron na bázi stejné architektury. To ale samozřejmě Intel nechce momentálně dávat najevo, neboť jeho cílem je přesvědčit lidi, že Core 2 Duo je úžasné... což sice je, ale ne proto, že by bylo dvoujádrové, ale kvůli vylepšením v samotném jádru (viz můj článek na Živě, kde jednojádrový Core 2 v některých případech překonal i dvoujádrový Athlon 64 X2).

[barjos]

Díky všem za vysvětlení a omlouvám se že v záplavě příspěvků mi unikla podstata problému. Eagle díky - články prostuduji, ale určitě půjdu do c2d. Hlavní důvod je že potřebuji novější pc a proto že v brzké době asi sc bázi stejné architektury asi jen tak brzo nebude v nabídce. Pro čtyřjádrový procesor asi v dohledné době nebudou aplikace které by ho využily. Jinak asi žádný přínos oproti c2d nebude. Navíc prý čtyřjádro bude mít dvojnásobné TDP

[Fox!MURDER]

Samozřejmě. Pokud chceš něco levně, tak přílišnou kvalitu neočekávej.

ja to myslel tak, ze pokud nechces platit nehorazny penize za jeden procesor, budes se muset spokojit s DC jako metodou zvysovani vykonu ... pokud das dost penez, urcite se najde nekdo ocohtnej, vyrobit ti SC s vypocetnim vykonem DC ...

[Petrik]

2 SWARM: Takze jestli to chapu dobre, tak ten clovek skutecne potvrdil, ze ty nejnovejsi enginy budou mit oddlene jednotlive veci (AI, fyziku, Zvuk a pod)? To je super Otazka je jak moc komplikovane to bude, aby pak ty hry vubec vysli v konecnem case.
Ad ta fyzika: doufam ze ne vsichni vyvojari, co pisi fyziku, ani poradne nevedi, co to je Laplaceova transformace. Ono je dost mozne, ze by i do her sla aplikovat vysokoskolska fyzika jako napr. Lagrangeovy rovnice druhého druhu a pod. veci, problem je ale v tom, ze ten vyvojar by musel byt jak dobry programator, tak alespon prumerne vzdelany fyzik. Takovych lidi asi moc neni a to je mozna duvod, proc az do nedavna fyzika ve hrach vypadala tak jak vypadala. Neber to prosim jako urazku toho tveho znameho a diky za tvoje prispevky.
Ad vyrobci HW vs. programatori: Jestli to chapu dobre, tak se soucasnou technologii vyrobit rozumne 6GHz SC patrne nejde, kdezto psat MT programy, pokud to algoritmus dovoli (dost casto), jde. Presto jich je velmi malo. Kdo je tedy neschopny nebo liny? A proc jsou podle meho nazoru obecne kvalitnejsi linuxove programy velmi casto MT, kdezto wokenni malo kdy? Neni to proste spise tim, ze linuxovy programatori pisi proto, aby ty programy byly co nejlepsi (a proto jsou casto MT), kdezto wokenni pisi proto, aby si vydelali? Mozna je tedy dobre, ze intel jen tak neuvede SC verzi core 2 ***, protoze si alespon vice lidi poridi DC a mozna to konecne donuti i wokeni vyvojare psat MT SW.

[Rainbow]

Ked robis open source, tak ten kod pises tak, aby si sa za to nemusel hanbit... Teda vacsinou, uz som videl aj hrozny kod v open source. Ale v closed source to skoro nikto nevidi, tak tam mozu byt omnoho horsie veci.

[swarm]

2 SWARM: Takze jestli to chapu dobre, tak ten clovek skutecne potvrdil, ze ty nejnovejsi enginy budou mit oddlene jednotlive veci (AI, fyziku, Zvuk a pod)? To je super Otazka je jak moc komplikovane to bude, aby pak ty hry vubec vysli v konecnem case.

No, týkalo se to teď ohlašovaných enginů, takže teď máme 3 roky čas než na těch enginech začnou vycházet hry .

Ad ta fyzika: doufam ze ne vsichni vyvojari, co pisi fyziku, ani poradne nevedi, co to je Laplaceova transformace. Ono je dost mozne, ze by i do her sla aplikovat vysokoskolska fyzika jako napr. Lagrangeovy rovnice druhého druhu a pod. veci, problem je ale v tom, ze ten vyvojar by musel byt jak dobry programator, tak alespon prumerne vzdelany fyzik. Takovych lidi asi moc neni a to je mozna duvod, proc az do nedavna fyzika ve hrach vypadala tak jak vypadala. Neber to prosim jako urazku toho tveho znameho a diky za tvoje prispevky.

Jako urážku svého známého to neberu. Ani nevim jestli ho můžu nazvat svým známým, když jsem se s nim bavil dneska v poledně snad minimálně po půl roce. Záleží asi na konkrétním člověku, jaké má školy ohledně té fyziky. Drtivá většina herních vývojářů, se kterými se ale setkávám mají za sebou aspoň několik semestrů vysokoškolské fyziky, takže tvoje teorie, že takových lidí moc neni ti tu rovnou radši vyvracím, než je začneš moc rozvíjet. Jsem přesvědčen o tom, že většina lidí, co kodí fyziku ve hrách má vysokoškolskou fyziku probranou. Aspoň teda když se zaměřím na mé nejbližší okolí, tak určitě.

A proc jsou podle meho nazoru obecne kvalitnejsi linuxove programy velmi casto MT, kdezto wokenni malo kdy?

Nějak nemám pocit, že by v tom byl linux nějak lépe. Z čeho vycházíš?

[Eagle]

ja to myslel tak, ze pokud nechces platit nehorazny penize za jeden procesor, budes se muset spokojit s DC jako metodou zvysovani vykonu ... pokud das dost penez, urcite se najde nekdo ocohtnej, vyrobit ti SC s vypocetnim vykonem DC ...

Za to mi to nestojí, radši se spokojím se současným výkonem a prostě nebudu upgradovat nebo až po dlouhé době (např. pět let).

[Fox!MURDER]

Za to mi to nestojí, radši se spokojím se současným výkonem a prostě nebudu upgradovat nebo až po dlouhé době (např. pět let).

jiste, kdyz nepotrebujes vyssi vykon, tak je cela debata o zbytecnosti DC bezpredmetna ...

[Eagle]

jiste, kdyz nepotrebujes vyssi vykon, tak je cela debata o zbytecnosti DC bezpredmetna ...

Potřebuju vyšší výkon a hodně moc. Akorát to řešení jaksi momentálně není.

[Petrik]

Potřebuju vyšší výkon a hodně moc. Akorát to řešení jaksi momentálně není.

to reseni je, ale ne momentalne, to mas pravdu. Presvedcit vetsinu vyvojaru, aby zacali psat HT, to bude chvili trvat. Ale doufam ze ne moc, protoze cekat nejaky dramaticky vyvoj v oblasti SC asi ocekavat moc nelze. Alespon ne v oblasti klasickych CPU, jake dneska zname. Spise bych to videl na stale vetsi a vetsi paralelizaci, at se ti to libi, nebo ne. Ad tvoje tvrzeni: nebo nam chces tvrdit, ze je nejaka dulezita vec, kterou vylozene zivotne potrebujes a ktera je principialne neparalelizovatelna?

No, týkalo se to teď ohlašovaných enginů, takže teď máme 3 roky čas než na těch enginech začnou vycházet hry .


Jako urážku svého známého to neberu. Ani nevim jestli ho můžu nazvat svým známým, když jsem se s nim bavil dneska v poledně snad minimálně po půl roce. Záleží asi na konkrétním člověku, jaké má školy ohledně té fyziky. Drtivá většina herních vývojářů, se kterými se ale setkávám mají za sebou aspoň několik semestrů vysokoškolské fyziky, takže tvoje teorie, že takových lidí moc neni ti tu rovnou radši vyvracím, než je začneš moc rozvíjet. Jsem přesvědčen o tom, že většina lidí, co kodí fyziku ve hrách má vysokoškolskou fyziku probranou. Aspoň teda když se zaměřím na mé nejbližší okolí, tak určitě.

Nějak nemám pocit, že by v tom byl linux nějak lépe. Z čeho vycházíš?

Predem sorry za OT.
To rad slysim, s temi vyvojari. Dalsi otazka je, jakou vysokoskolskou fyziku mas na mysli. Nechci nijak urazet treba CVUT, ale krome jaderky je tamni fyzika ponekud priliz prakticka a melka oproti treba MFF a to predevsim kvuli nedostaku potrebne matematiky.

Jako jasne ze jsou i dobre programy pod windows, to jiste, ale stejne mam vzdycky pocit, ze hlavni neni kvalita, ale aby to hlavne vydelalo ty prachy. Navic, dost dulezita vec podle me je, ze napr. v gentoo se instaluje vse formou zdrojovych kodu. Kdyz jsem to poprvy videl v procesu, tak jsem jen ziral a divil se, jak je mozny, ze se to vsechno po cca 25hod (az na uplne vuyjimky) spravne zkompiluje, ze to fakt funguje. Ve windows mi to pripada jako scifi, tam bych se vubec nedivil, kdyby se autor pri kompilaci musel drbat pravou rukou za levym uchem a odrikavat nejaou modlitbu, aby se mu to spravne zkompilovalo. Prehanim, ale myslim, ze to tak nejak bude. A pokud to tak nejak je, tak to podle hodne vypovida o kvalite zdrojoveho kodu.

[Eagle]

nebo nam chces tvrdit, ze je nejaka dulezita vec, kterou vylozene zivotne potrebujes a ktera je principialne neparalelizovatelna?

Např. LAME.

Ve windows mi to pripada jako scifi, tam bych se vubec nedivil, kdyby se autor pri kompilaci musel drbat pravou rukou za levym uchem a odrikavat nejaou modlitbu, aby se mu to spravne zkompilovalo.

Protože žádný programátor komerčního software není tak hloupý, aby zveřejnil zdrojáky - při nejbližší příležitosti by mu s nima někdo udělal COPY & PASTE.

[Rainbow]

Protože žádný programátor komerčního software není tak hloupý, aby zveřejnil zdrojáky - při nejbližší příležitosti by mu s nima někdo udělal COPY & PASTE.

Tak to sa dost mylis... Open Source a komercne ucely sa vobec nevylucuju. Linuxove distribucie sa veselo predavaju, MySQL sa da pouzivat zadarmo ale aj kupit...

[Eagle]

Tak to sa dost mylis... Open Source a komercne ucely sa vobec nevylucuju. Linuxove distribucie sa veselo predavaju, MySQL sa da pouzivat zadarmo ale aj kupit...

Obávám se, že se nemýlím. Výjimky vždy potvrzují pravidlo. Např. když vyšel zdroják na Descenta II, musely z něj být vypuštěny některé části kvůli copyrightu (takže nešel zkompilovat).

[Haste]

Např. LAME.

Proc myslis, ze zrovna LAME je pricipialne neparalelizovatelny ?
Cloveka napadne x zpusobu jak na to. Takovy asi nejrealnejsi je rozdelit encoding na tolik useku kolik mas jader. Tj. u DualCore na 2 casti a pak paralelne encodujes kazdou pulku na jinem jadre. Spojeni by nemel byt velky problem a to ani kvalitou ani narocnosti. A uz tu bylo napsano nejmin 10x, ze je to navic zbytecne, kdyz kazde album ma nejakych 12+ pisnicek a muzes encodovat kazdou zvlast na jinem jadre, tedy v realnych podminkach je to az linearni narust.

[Caleb]

..... Spojeni by nemel byt velky problem a to ani kvalitou ani narocnosti.

Nepovidej ... a tenhle thread si cetl ?

[Haste]

Obávám se, že se nemýlím. Výjimky vždy potvrzují pravidlo. Např. když vyšel zdroják na Descenta II, musely z něj být vypuštěny některé části kvůli copyrightu (takže nešel zkompilovat).

To je uplne jiny pripad. Nektere casti jsou vypustene kvuli urcitym vecem v kodu, ktere nebyli vyvinute stejnou firmou/teamem a pokud ta druha firma se rozhodla zdrojaky nezverejnit tak jsou vypusteny. Tj. soucasti jednoho produktu jsou obvykle casti od ruznych firem, kde kazda zvlast je pod copyrightem, dnes to jdou jine .dll, takze sice mas cely kod ale neprelozis to, protoze nemas .bin a nasledne ani .dll onech dalsich firem . Rozhodne to neni proto, abys nemohl udelat copy/paste Jinak zdrojaky zverejnuje i ID soft a to uz pekne dlouho. A za dalsi, u tohodle typu OSource nejde o copy/paste. Tady jde o podivani se jak to udelali. Ten kod je jak technikou programovani, tak i technologiema "ancient history" (jak descent tak ID hry= Doom1,2,Quake1 ...) a rozhodne je to dneska nepouzitelne.

[Haste]

Nepovidej ... a tenhle thread si cetl ?

A ty vis neco o Mpeg1 Layer3 a jak se encoduje ?
Doporucuju toto. MDCT rozhodne je do jiste miry paralelizovatelny ve smyslu jaky sem psal. Jen se u krivky musis trefit do spravneho keyframu, aby to bylo spojite. Pokud se chces ptat jak, tak to ti rozhodne z hlavy nereknu, ale jde to

[Eagle]

Rozhodne to neni proto, abys nemohl udelat copy/paste Jinak zdrojaky zverejnuje i ID soft a to uz pekne dlouho. A za dalsi, u tohodle typu OSource nejde o copy/paste. Tady jde o podivani se jak to udelali. Ten kod je jak technikou programovani, tak i technologiema "ancient history" (jak descent tak ID hry= Doom1,2,Quake1 ...) a rozhodne je to dneska nepouzitelne.

Sám říkáš, že to jsou staré hry - no ano, přesně tak. Zveřejní staré zdrojáky, aby fanoušci mohli dělat modifikace. Ale novou věc ti nikdo nezveřejní, protože nechce, aby mu to někdo obšlehnul (ať už stylem Copy & Paste nebo omrknutím know-how). Programátor je placen mimo jiné i za to, že něco umí udělat lépe než ostatní (ať už rychleji nebo kvalitněji).

A ty vis neco o Mpeg1 Layer3 a jak se encoduje ?
Doporucuju toto. MDCT rozhodne je do jiste miry paralelizovatelny ve smyslu jaky sem psal. Jen se u krivky musis trefit do spravneho keyframu, aby to bylo spojite. Pokud se chces ptat jak, tak to ti rozhodne z hlavy nereknu, ale jde to

Určitě o tom víš víc než programátoři LAME... (ironie)

[Haste]

Sám říkáš, že to jsou staré hry - no ano, přesně tak...

No jiste ze ti nezverejni nove hry. Jen sem ti vysvetloval, proc nemuzes mit ve zdrojaku zpristupneny vsechen kod.

Určitě o tom víš víc než programátoři LAME... (ironie)

1. Nevim. 2. Toto je obycejna matematika kolem krivek a jejich navazovani. Kdyz budes mit zajem, tak ti poslu scripta z nasi fakulty.

[Eagle]

No jiste ze ti nezverejni nove hry. Jen sem ti vysvetloval, proc nemuzes mit ve zdrojaku zpristupneny vsechen kod.

Já to samozřejmě vím, dříve se často využíval Miles Sound System na zvuk a ten určitě není možné poskytovat "free". Jenže to jen potvrzuje, co říkám - že prostě programátor komerční aplikace v drtivé většině případů nechce uveřejnit kód, neboť se tím chrání proti kopírování.

Toto je obycejna matematika kolem krivek a jejich navazovani. Kdyz budes mit zajem, tak ti poslu scripta z nasi fakulty.

Jenže program není jen matematika. Můžeš mít paralelismus pro určité specifické bloky, ale ty můžou být tak malé, že se je paralelizovat nevyplácí. Vyplatí se je třeba udělat v SIMD, což taky LAME využívá. Abys mohl paralelizovat všechno, musíš mít poměrně velké instrukční bloky - jednak kvůli režii OS a taky kvůli efektivnosti CPU (než načteš první data a instrukce do cache, trvá to; než z pipeline dostaneš první výsledek, trvá to; než vyměníš výsledky s druhým CPU jedoucím hlavní thread, trvá to). Aby se vyplatilo paralelizovat nějakou smyčku, musí se jednat o tisíce instrukcí (jednojádro při využití SIMD v tom může být hodně rychlé). Ale jestli si myslíš, že to tak není, běž to programátorům LAME předvést - je to open-source a oni určitě uvítají, když jim to trošku urychlíš BEZ ztráty kvality.

[Haste]

Jenže program není jen matematika.

To je prave ono. Ten matematicky navrh totiz nepocita s Multicore, coz ovsem VUBEC neznamena, ze to nejde. Jenom by to znamenalo zmenu celeho navrhu encoderu, coz uz nechce programatora, ale informatika nebo lepe matematika. Decodery by pak teoreticky mely zustat stejne.

[Eagle]

To je prave ono. Ten matematicky navrh totiz nepocita s Multicore, coz ovsem VUBEC neznamena, ze to nejde. Jenom by to znamenalo zmenu celeho navrhu encoderu, coz uz nechce programatora, ale informatika nebo lepe matematika. Decodery by pak teoreticky mely zustat stejne.

Jak už jsem řekl - http://www.hydrogenaudio.org/forums/...p?showuser=138. To je kontakt na programátora LAME, běž mu to vysvětlit, když mu nevěříš.

[Fox!MURDER]

proc sakra vsichni chtej paralelizovat jen rozdelenim do dvou stejnejch vlaken ?