Vyznam dual core

[THX]

Instrukce mě nestojí dvojnásobek.

to nemozes tvrdit; vyrobne mozno ano, predajnou cenou nie. Kazda novinka ma isty "priplatok" jednak za vyssiu vyrobnu cenu, ale aj za dalsi vyvoj. Ak si si v dobe uvedenia porovnal ceny p3 a p4 s sse2 a ich vykon, tak urcite sa p4 spociatku neoplatil, celkovo ale dosiahol vyssi vykon. Ale ceny sa casom menia, preto myslim ze fakt nema zmysel rozoberat cenu, ale skor pouzitie.

Při stejném výkonu cenový rozdíl JE dvojnásobný. Otestuj si to a porovnej v ceníku.

DC je lacnejsi o 60%!!!! viz:
http://www.czechcomputer.cz/product.jsp?artno=30676
a
http://www.czechcomputer.cz/product.jsp?artno=38987

Myslim ze o cenach sa nema vyznam bavit, pretoze sa menia - od predajcu k predajcovi, a z casu na cas. O rok budu tvoje argumenty o cenovych rozdieloch neplatne.

Kvůli tomu mě ale nemusí nabízet jen DC variantu s tím, jak je to skvělé. Pokud mi nenabídne adekvátní volbu za pro mě přijatelnou cenu, prostě půjdu jinam.

to ze tebe dany procak pre tvoje programy nevyhovuje, neznamena ze je na h, pretoze mnoho inych ludi pren ma vyuzitie. A stale si myslim ze DC je lepsie ako nejake sse8. Single threaded vykon uz velmi zvysovat nejde, tak aspon vdaka za to druhe jadro.

Podle mě to, co bude mít lepší price/performance. Další instrukce nepřinesou skoro žádný užitek navíc, ale taky nestojí skoro nic navíc (max. pár transistorů, což se ve stovkách milionů ztratí). DC mít přínos může, ale taky stojí o 100 % víc.

DC je lacnejsie o 60%. Dalej sa odmietam bavit o cenach.

Optimalizace pro dvě jádra je to samé jako pro čtyři, osm, tisíc.

nemyslim, moho veci rozdelis na niekolko asymetrickych threadov, hoci ten hlavny vypocetny ostane nezmeneny, vsetko okolo (grafika, prekreslovanie okna, animacie atd.) mozes dat do druheho threadu a tak ziskat trocha vykonu navyse.

SIMD mají dle mě v mnoha případech značný přínos a optimalizace na ně je snazší než pro DC. Navíc je dostanu prakticky zdarma, což se o DC říct nedá. Dívej se na to asi takhle - kdybych měl na výběr mezi dvěma procesory, jedním s SSE2 a druhým bez nich, přičemž ten s SSE2 by byl dražší, tak bych taky porovnával cenu, zda se mi to vyplatí. Kdyby ne, tak bych koupil ten bez SSE2.

ber to tak, ze ak by si dnes zacal vyrabat p3 na najmodernejsom vyrobnom procese, tak dosiahnes mozno aj 2ghz frekvencie - na kanc. pracu a beznym uzivatelom by to v pohode stacilo. A urcite by to bolo lacnejsie ako c2d, p4 atd., pretoze by netrebalo platit navyse ziaden vyvoj. Ale uz to raz tak byva, ze vyrobcovia pouzivaju rozne strategie a robia napr. to ze starsie procesory prestavaju vyrabat atd. Kazdopadne stale si mozes kupit transmentu.

Alpha má tuším 256 záznamů. A to už pěknou řádku let. Velké okno by mohlo pomoct spekulaci. Přirozeně by to chtělo i spoustu dalších změn. Takovýmto inovativním návrhům jsem přikloněn víc než přidávání jader, což dlouhodobě stejně nikam nepovede.

lenze alpha je RISC a trocha ina architektura, takze tam sa vacsie reorder buffery a window mozu oplatit viac. Myslim, ze ak by to malo mat podstatny prinos, tak u c2d su omnoho vacsie reorder buffery.

Sdílená cache má výhody pro multithreading, ale pro multitasking je špatná. A ono sdílení taky nemusí být tak jednoduché. Navíc mám pocit, že Intel do Core 2 Duo nakonec nedal ono přímé spojení L1D cache.

nezabudaj, ze beznemu uzivatelovi na pozadi bezi winamp, dc, nejaky antivir (ktory kazde 3 hodiny stahuje novu databazu a kontroluje ram) a kopec dalsich aplikacii (icq, rozne netlimitery, oc utilitky atd.). Nevravim ze nejak vyrazne zatazuju jadro, povedme dokopy 10%. Vsade kde sa robia v recenziach testy, tak na pozadi nic nebezi, podobne v hrach je vypnuty zvuk. U DC mas vyhodu v tom, ze tieto ostatne veci bezia na druhom jadre a 100% vykonu jedneho jadra ma pre seba tvoja hlavna aplikacia. U hier druhe jadro vyuzije napr. multithreaded driver od grafiky, alebo si na nom bude robit vypocty driver integrovanej "sw" zvukovky.
Skratka oproti novym instrukciam ma DC vyhodu v okamzitej pouzitelnosti.

[Eagle]

Pokud nehodláš pochopit, že cenová politika Intelu je mi úplně u pr****, protože to samé mi AMD nabídne podstatně levněji (D945 na 3.4 GHz je jako A64 3500+ za 2700 Kč), pak nemá smysl se s tebou nadále bavit, protože jsi nepochopil smysl této diskuze.

Za druhé jádro bych někomu poděkoval pouze tehdy, když by to bylo zadarmo. Co kdybychom to udělali tak, že já si vyberu SC, ty mi pak zaplatíš to druhé jádro, koupím DC a poděkuju ti? Férová nabídka, ne?

ad zbytek - Přijde mi, že máš lehce zkreslené představy o přidělování jádra v OS a o programování. Doporučuju zkusit ASM, z toho pochopíš, jak se věci mají. BTW, Core 2 Duo je samozřejmě RISC procesor (jako všechny dneska).

[THX]

Pokud nehodláš pochopit, že cenová politika Intelu je mi úplně u pr****, protože to samé mi AMD nabídne podstatně levněji (D945 na 3.4 GHz je jako A64 3500+ za 2700 Kč), pak nemá smysl se s tebou nadále bavit, protože jsi nepochopil smysl této diskuze.

zmysel tejto diskusie je ze DC nie je na h

kym nevyslo c2d, tak boli ceny AMD o dost vyssie - skratka ceny sa menia, preto sa odmietam bavit o cenach

Za druhé jádro bych někomu poděkoval pouze tehdy, když by to bylo zadarmo. Co kdybychom to udělali tak, že já si vyberu SC, ty mi pak zaplatíš to druhé jádro, koupím DC a poděkuju ti? Férová nabídka, ne?

staci ze si pockas tak rok a cenovy rozdiel bude zanedbatelny
Potom padnu vsetky tvoje argumenty o cene a ze dc je na h atd. Neagrumentoval by som tym, co sa bude menit.

ad zbytek - Přijde mi, že máš lehce zkreslené představy o přidělování jádra v OS a o programování. Doporučuju zkusit ASM, z toho pochopíš, jak se věci mají. BTW, Core 2 Duo je samozřejmě RISC procesor (jako všechny dneska).

nie som si celkom isty ci su vobec dnes nejake RISC procesory (mozno nejake sparc?), skor to je nieco medzi risc a cisc. Mozno blizsie k RISC, ale rozhodne nie cisty risc.

V com sa ti zda ze mam skreslene predstavy o pridelovani jadra v OS a o programovani? V com mi ma pomoct assembler pri pochopeni pridelovania jadra nejakym schledulerom?

[Petrik]

Sam vis, ze to tak neni. Interne sice jedou na RISC, ale pro SW se tvari jako CISC, prevod CISC instrukci na RISC provadi dekodery instrukci. Nebo snad instrukce typu MMX, SSE a pod jsou RISC? Asi ne, co Cisty RISC jsou ruzne embeded CPU typu MIPS, pokud se nepletu, ale mozna ze uz i ty maji neco navic.

Ad ceny: nemuzes porovnavat novou vlajkovou lod intelu proti staremu modelu AMDcka, to se pak nediv, ze to vychazi 2x draz. Nove CPU, zvlaste od intelu a zvlaste pokud jsou dobre, byly vzdycky drahe. Ze to je DC na tom nic nemeni. Ja se tesim, az zacne intel prodavat neco jako core solo, tedy core 2 duo s jednim vadnym jadrem. Je ale dost mozne, ze to bude cenove skoro stejne jako DC, tak to ostatne je u core duo/solo.

Ted neco k budoucnosti. Podle me jedina cesta, jak zvysit vykon CPU, je cesta, jakou se vydal cell, resp. intel s jeho 80-ti jadrovou novinkou. Procaky budoucnosti budou mit podle me nekolik zakladnich charakteristik: budou vysoce paralelni, budou mit velmi vykonne SIMD jednotky/jadra a jejich logika bude podobna, jakou ma cell nebo transmeta, tedy vpodstate zadna. Tim nevznikne omezeni pro budoucnost, jako je nyni u x86, procesory budou plne programovatelne. Dopadne to tedy opdobne jako tomu bylo ve vyvoji telekomunikaci/siti, kdyz se od komplikovaneho prepinani okruhu preslo na jednoduzsi prepinani packetu a sit jako takova neumi vpodstate nic, vse se dela pomoci SW.

ad zbytek - Přijde mi, že máš lehce zkreslené představy o přidělování jádra v OS a o programování. Doporučuju zkusit ASM, z toho pochopíš, jak se věci mají. BTW, Core 2 Duo je samozřejmě RISC procesor (jako všechny dneska).

[THX]

Sam vis, ze to tak neni. Interne sice jedou na RISC, ale pro SW se tvari jako CISC, prevod CISC instrukci na RISC provadi dekodery instrukci. Nebo snad instrukce typu MMX, SSE a pod jsou RISC? Asi ne, co Cisty RISC jsou ruzne embeded CPU typu MIPS, pokud se nepletu, ale mozna ze uz i ty maji neco navic.

su to post-risc procesory, maju tolko vela pridanych zmien, ze uz ich davno nemozno povazovat za cisto riscovske procesory. RISC a CISC su velmi stare koncepty. Uz pentium bol post risc (a to teda dost velmi vzdialeny cistemu risc), nie to este dnesne core2. Pokial viem, dnes uz nejaky risc alebo cisc procesor tazko vobec niekde najdes. Aj tie embedded budu istym variantom post-risc, aj ked verim ze blizsie k risc.

[zivan]

No ja chapu problemy s malou optimalizaci na dual a vice core procesory. Kdyz si odmyslime, ze programator je v jadru "liny" tvor, tak proti porad stoji cena.
Proc by se mel programator ucit ladit "rucne" multi core program, kdyz je to mnohem slozitejsi a malokdo mu to zaplati. Souhlasim s tim, ze se nejdrive musi mnohem zlepsit v podpore vyvojove nastroje a co nejvic ulehcit praci.

Odhadnul bych, ze vyvoj takove optimalizovane aplikace bude cca stat minimalne 2x tolik a testovani 4x tolik. A ted rekni zakaznikum, ze budou mit vykon o nejakych 20-70% vetsi, bude to stat minimalne 4x tolik a bude v tom vic chyb, protoze se blbe hledaji? Napr. dnes prodavane hry za 1000,- budou rychlejsi, ale budou stat 4000,-? Kdo to koupi?

na jednej strane tvrdis, ze programatorom pracu navyse nikto nezaplati a ze nebudu optimalizovat atd. Teda potom asi vsetci pisu este vo visual basicu, pretoze je to najjednoduchsie a preco by stracali akykolvek cas ucenim sa nejakeho ineho jazyka (napr. C) v ktorom ide urobit to iste, len sa to pise zlozitejsie, a ze to ide rychlejsie - ved to je predsa problem hw.

Spatne porovnavas C a Visual Basic. Musis porovnavat puvodni Basic. A pak psat, ze v Cecku se pise hur. No ja ti nevim, ale me podstatne lip. A chtel bych videt napr. interpretovany Linux

[xjohny]

Jen tak na okraj, uz delsi dobu se daji psat multi-threadove aplikace i ve Visual Basicu, vsechno je uz zalezitost .NET Frameworku.

Musim potvrdit, ze se mi v nem taktez pise mnohem hur nez treba v C#, ale to sem uz spis nepatri.

[Rainbow]

A naco je to dobre? Ked to niekto spravi v tom VB.NET, tak to na tom dvojjadrovom C2D pojde pomalsie ako rovnaky program v C na Celerone 266.

[xjohny]

No ja netvrdil, ze to bude nejak rychle Jen jsem branil vsemi (vcetne me) nenavideny VB

[THX]

A naco je to dobre? Ked to niekto spravi v tom VB.NET, tak to na tom dvojjadrovom C2D pojde pomalsie ako rovnaky program v C na Celerone 266.

OT: to by som netvrdil, sice ano, urcite najdes taky specificky program, ale celkovo je .net dost rychly, navyse som niekde cital/pocul ze by sa mohli objavit procesory ktore by ciastocne podporovali .net mikrokod (nieco take chcel spravit aj sun s javou) a potom by ta rychlost mala byt omnoho lepsia

[pYr0]

OT: to by som netvrdil, sice ano, urcite najdes taky specificky program, ale celkovo je .net dost rychly, navyse som niekde cital/pocul ze by sa mohli objavit procesory ktore by ciastocne podporovali .net mikrokod (nieco take chcel spravit aj sun s javou) a potom by ta rychlost mala byt omnoho lepsia

Zrovnavat .NET a C co sa rychlosti tyce sa naozaj neda. Mal som moznost to porovnavat a mozem povedat, že ak nejaku aplikaciu napisete v C, tak obvykle je x krat rychlejsia ako v pripade že by ste ju napisali v .NET. Ale zase na druhej strane kto pozna .NET aj C, tak vie že porovnavat tieto dve prostredia je dost od veci...každé je určene do ineho segmentu.

[miho]

A naco je to dobre? Ked to niekto spravi v tom VB.NET, tak to na tom dvojjadrovom C2D pojde pomalsie ako rovnaky program v C na Celerone 266.

A pro to mas nejake podklady, nebo jsi to jen tak placnul? Vsechny benchmarky, ktere jsem videl, byly totiz zalozeny na mereni vykonu nejakych kratkych algoritmu. Jinymi slovy- prilis zjednodusujici. A v techto pripadechsi vedl .NET vesmes velmi dobre (dlouhodobe plati, ze prekladace virtualni stroje atd. od MS patri , na rozdil od vetsiny ostatnich produktu teto firmy, ke svetove spicce... staci srovnat o kolik je gcc v kvalite generovaneho kodu za Visual C). Pokud mas skutecne nejake konkretni vysledky tak by me hodne zajimaly. Co jsem nasel ja:

http://www.osnews.com/story.php/5602...File-IO/page3/

Vykon C# vyssi nez gcc c. Proc ne, kdyz jde jen o vypocetni algoritmus a objekty se temer nepouzivaji?

http://www.tommti-systems.de/go.html...enchmarks.html

Velmi zajimavy test. Meren je i maximalni memory footprint aplikace.

http://www.shudo.net/jit/perf/

Cast SciMark 2. Asi nejvice vypovidajici vec. C# 240 bodu, gcc 266 bodu (11% lepsi vysledek nez C#), Visual C 329 bodu (37% lepsi vysledek nez C#). To vse navic s poznamkou "C version is advantageous compared with Java and C# versions because Java and C# versions use a "synchronized" version of the random number generator, which makes the Monte Carlo Test much slower." Linpack taktez dava zajimave vysledky.

http://www.ddj.com/dept/cpp/184401976

Dalsi sada mikrobenchmarku. Vysledky zacinaji na druhe strane.

... a desitky dalsich podobnych...

Jaky je zaver? No at si ho kazdy udela sam Ja si ten svuj utvoril na zaklade mych vlastnich testu (pac je znamo, ze existujou tri druhy lzi- male, velke a benchmarky a take neverim statistikam, ktere jsem si nezfalsoval sam ) a pokusu, kde mi vyslo, ze C# ztraci za C++ zhruba o 30%. Pri urcovani platformy projektu to beru v uvahu a zamicham do toho zkraceni doby vyvoje v C# oproti C++ a cenu programatoro hodiny. Vetsinou mi to vyjde ve prospech C# maximalne s cca 5% aplikace (kriticka cast) napsanymi v C.

[pYr0]

A pro to mas nejake podklady, nebo jsi to jen tak placnul? Vsechny benchmarky, ktere jsem videl, byly totiz zalozeny na mereni vykonu nejakych kratkych algoritmu. Jinymi slovy- prilis zjednodusujici. A v techto pripadechsi vedl .NET vesmes velmi dobre (dlouhodobe plati, ze prekladace virtualni stroje atd. od MS patri , na rozdil od vetsiny ostatnich produktu teto firmy, ke svetove spicce... staci srovnat o kolik je gcc v kvalite generovaneho kodu za Visual C). Pokud mas skutecne nejake konkretni vysledky tak by me hodne zajimaly. Co jsem nasel ja:

http://www.osnews.com/story.php/5602...File-IO/page3/

Vykon C# vyssi nez gcc c. Proc ne, kdyz jde jen o vypocetni algoritmus a objekty se temer nepouzivaji?

http://www.tommti-systems.de/go.html...enchmarks.html

Velmi zajimavy test. Meren je i maximalni memory footprint aplikace.

http://www.shudo.net/jit/perf/

Cast SciMark 2. Asi nejvice vypovidajici vec. C# 240 bodu, gcc 266 bodu (11% lepsi vysledek nez C#), Visual C 329 bodu (37% lepsi vysledek nez C#). To vse navic s poznamkou "C version is advantageous compared with Java and C# versions because Java and C# versions use a "synchronized" version of the random number generator, which makes the Monte Carlo Test much slower." Linpack taktez dava zajimave vysledky.

http://www.ddj.com/dept/cpp/184401976

Dalsi sada mikrobenchmarku. Vysledky zacinaji na druhe strane.

... a desitky dalsich podobnych...

Jaky je zaver? No at si ho kazdy udela sam Ja si ten svuj utvoril na zaklade mych vlastnich testu (pac je znamo, ze existujou tri druhy lzi- male, velke a benchmarky a take neverim statistikam, ktere jsem si nezfalsoval sam ) a pokusu, kde mi vyslo, ze C# ztraci za C++ zhruba o 30%. Pri urcovani platformy projektu to beru v uvahu a zamicham do toho zkraceni doby vyvoje v C# oproti C++ a cenu programatoro hodiny. Vetsinou mi to vyjde ve prospech C# maximalne s cca 5% aplikace (kriticka cast) napsanymi v C.

Tie benchmarky o realnom nasadeni .NET nehovoria NIC. Vzdy ked sa robi aj velmi jednoducha aplikacia...pouzivaju sa objekty z .NET a tie su o vela pomalsie ako triedy napisane v C s podobnou funkciou.

[miho]

Proc citujes muj sahodlouhy prispevek jen abys dolu napsal jednu vetu, ktera byla v mem prispevku navic zminena?

Moje testy byly zalozeny na realnych aplikacich, ktere jsem potreboval vytvorit takze vypovidaly o realnem nasazeni vsechno

Vytvoreni a ruseni objektu ma v .NET vyssi rezii. To je pravda. Ovsem algoritmus, kde se to projevi (tzn. kde se vytvari tak mnoho objektu, ze rezie jejich vytvareni prekroci "spotrebu" zbytku algoritmu) je s nejvetsi pravdepodobnosti proste spatne navrzen. V .NET (a jave) je pak treba pouzit napr. object pool nebo jinou techniku aby se nadmernemu vytvareni objektu zabranilo. Jsou tam jeste dalsi zadrhele jako napr. zpracovani vyjimek, ktere je v .net citelne pomalejsi. Tohle vsechno se ale vejde do tech 30%, ktere jsem zminil vyse.

... ale mam pocit, ze jsme tady uz docela OT.

[pYr0]

Proc citujes muj sahodlouhy prispevek jen abys dolu napsal jednu vetu, ktera byla v mem prispevku navic zminena?

To uz tak nejak ze zvyku ked idem na niekoho reagovat tak hned kliknem quote, proste blby zvyk.

Kde v prispevku si napisal to co ja?? Praveze si pekne zhrnul jak je .NET len o malo pomalsi (coz neni tak) viz. posledny tvoj odstavec.

Vytvoreni a ruseni objektu ma v .NET vyssi rezii. To je pravda. Ovsem algoritmus, kde se to projevi (tzn. kde se vytvari tak mnoho objektu, ze rezie jejich vytvareni prekroci "spotrebu" zbytku algoritmu) je s nejvetsi pravdepodobnosti proste spatne navrzen. V .NET (a jave) je pak treba pouzit napr. object pool nebo jinou techniku aby se nadmernemu vytvareni objektu zabranilo. Jsou tam jeste dalsi zadrhele jako napr. zpracovani vyjimek, ktere je v .net citelne pomalejsi. Tohle vsechno se ale vejde do tech 30%, ktere jsem zminil vyse.

Ano rezia je pomalsia ale hlavny dovod proc aplikacie napisane pod .NET su ovela pomalsie neni len kvoli tejto rezii (ta je naopak zanedbatelná). Pomalost NETu je spusobena hlavne principami programovania.

Napríklad string :
Azda všetky bežne client aplikacie vo velkom používajú stringy. Ako iste vies, v .NET su stringy relativne velke objekty ktorych vytvorenie tvori dosť náročných funkcii. Takisto sú tam funkcie ktoré často ani programator v aplikacii nevyužije (len zaberaju sys. prostr.). V C je string obycajny datovy typ (napr. pole charov) ktorý nezaberá ani z daleka toľko sys. prostr. ako jeho ekvivalent v NET (proste v pameti zabera len tolko kolko je treba, jeden znak sa da uložiť do 1 bajtu takže string zaberá minimum). Je sice o niečo pracnejšie pracovat stymto stringom, programator si musí vela vecí písať sám ale to je daň za výkon a efektivitu.

Tým som chcel len povedať kde je ten hlavný dovod, preco je .NET pomalsi. Uviedol som ako príklad sice len string ale ked sa pozres na triedy ktoré .NET obsahuje tak hned vieš prečo je NET pomalší.

A nemusia to byt len zakladne triedy typu string, int, staci sa pozriet aj na GUI triedy, na WIndows.Forms. V porovnani napriklad s MFC ktore použijem v C++ nemaju WindowsForms šancu čo sa týče rychlost

EDIT:

dlouhodobe plati, ze prekladace virtualni stroje atd. od MS patri , na rozdil od vetsiny ostatnich produktu teto firmy, ke svetove spicce... staci srovnat o kolik je gcc v kvalite generovaneho kodu za Visual C

Jo a compilator obsiahnuty v MS produktoch je made by Intel a nie MS.

[miho]

Napríklad string :

Blby priklad:
http://www.ddj.com/showArticle.jhtml...chlegel&pgno=8

v .NET su stringy relativne velke objekty ktorych vytvorenie tvori dosť náročných funkcii.

Neni pravda. String je velmi jednoduchy immutable objekt, ktery ma v datove casti krome samotneho retezce navic pouze delku a pocet odkazu.

Takisto sú tam funkcie ktoré často ani programator v aplikacii nevyužije (len zaberaju sys. prostr.).

Predne- v OOP rikame metody. Kdyz prilinkujes stdlib.h tak si tim nabalis take stovky funkci, ktere nikdy nepouzijes.

jeden znak sa da uložiť do 1 bajtu takže string zaberá minimum).

Tohle si v dnesni dobe mysli uz jen malokdo a kazdy, kdo si to mysli, se drive nebo pozdeji dostane do znacnych problemu a/nebo pise jen male programky pro vlastni potrebu.

int

int v .NET neni objektem, chova se stejne jako v C.

staci sa pozriet aj na GUI triedy, na WIndows.Forms.

Pravda, GUI je pomalejsi. Rozsil ale neni nijak velky a navic to neni kriticka cast aplikace takze to je irelevantni.

Vzdy ked sa robi aj velmi jednoducha aplikacia...pouzivaju sa objekty z .NET a tie su o vela pomalsie ako triedy napisane v C s podobnou funkciou.

Scimark je pomerne velka aplikace. A vysledky viz vyse. Moje aplikace, na kterych jsem testoval, taktez k uplne prtavym nepatrily. Tezko ale urcit nejakou metriku podle ktere se urcuje "velkost aplikace"

[pYr0]

Blby priklad:
http://www.ddj.com/showArticle.jhtml...legel& pgno=8

Na tych strankach pisu:

"String concatenation is performed here, but the memory allocation is done outside the benchmarking loop. That's why I called it "fixed" or "preallocated." "
Neni tam zahrnutá pre nás velmi dôležitá alokácia obektu, takze ten test neni moc objektivný.

Neni pravda. String je velmi jednoduchy immutable objekt, ktery ma v datove casti krome samotneho retezce navic pouze delku a pocet odkazu.

S tymi funkciami čo poskytuje nemôže byť velmi jednoduchy maly objekt. Tomu neverim. A aj keby bol mensi nez si myslim, tak co z toho ked stale neni taky maly jak zakladny string v C? Nic nemeni na tom co som napisal

Predne- v OOP rikame metody. Kdyz prilinkujes stdlib.h tak si tim nabalis take stovky funkci, ktere nikdy nepouzijes.

Nepotrpím si na terminologii. Jo ty funkce a triedy si nabalim do exe to je fakt, ale sys. prostriedky zeru az ked jednu z nich vyvolam alebo vytvorim triedu. Ak nie tak je len o par kB alebo mozno stoviek kB vecší exe což dneska nejak nevadí. To v .NET sa to robí tak že sa aplikacia načíta se vším všudy a hele hned kukam do taskmanageru, že tie čísla reprezentujuce volnu pamet nejako klesaju.

Tohle si v dnesni dobe mysli uz jen malokdo a kazdy, kdo si to mysli, se drive nebo pozdeji dostane do znacnych problemu a/nebo pise jen male programky pro vlastni potrebu.

Ano a kolko si mysliš že ten char v pameti zabere? Kolko ma typ dané, tolko si aj alokuje. Jedina vynimka je co sem niekde čital že niektoré kompilatory alokuju datovemu typu bool 4 bajty....ale co je na tom pravdy to nevim.

int v .NET neni objektem, chova se stejne jako v C.

Ano a co je potom System.Int32 ?

Pravda, GUI je pomalejsi. Rozsil ale neni nijak velky a navic to neni kriticka cast aplikace takze to je irelevantni.

Este kedysi davno som si robil pod .NET, aplikaciu ktorú som nazval ImageViewer, bol to velmi jednoduchy prehladavac obrazkov ktory obsahoval filebrowser, okno pre nahlad obrazkov a hlavne okno pre zobrazovanie fotky fullscreen. Nestacil som sa diviť aké strašné veci to robilo, obrazky som nacitaval do objektu Image (myslim že tak sa volal) a fakt velmi dlho trvalo nacitanie foto 1280x1024 v jpg. Dalsi sok bol ked som to nechal zobrazovat v nahladovom okne. Cela aplikacia si pri tomto procese alokovala asi 80 mb z RAM....tak som musel do toho cyklu este pridať aj garbage colector aby to tie pozostale Image objekty uvolnilo....to bolo samozrejme dalšie spomalenie nacitania obrazkov a fotiek. Asi tolko ku gui .NET Frameworku a jeho "rychlých" objektoch.

Scimark je pomerne velka aplikace. A vysledky viz vyse. Moje aplikace, na kterych jsem testoval, taktez k uplne prtavym nepatrily. Tezko ale urcit nejakou metriku podle ktere se urcuje "velkost aplikace"

Inak neco treba povedat aj ktym testom. Nemyslim si že by boli objektivne lebo pokial viem tak .NET ma rozne optimalizačné techniky, že nejaky usek kodu zkompiluje este pred začatím toho useku, a tym padom sa nenamera spravny vysledok. A myslim že nielen to obsahuje NET, urcite tam sú aj dalšie veci ktore môžu oklamať tak jednoduchy benchmark ako si ty uviedol. Aj v tych jednoduchych cykloch to môže v realu vyzerať inak. Ale to už je tak skor moja spekulacia a silne OT mali by sme to asi nechať

[tomase]

neodbocili ste "kapanek" od temy?

[Halen]

Kamos vymenil pekny single core A64 co behal na 2700+ MHz za A64 dual-core, ktery da maximalne 2550MHz a vsechno co doma ma mu beha pomaleji a ted lituje vyhozenych penez.

[tomase]

Su ale aj opacne pripady ako napr. ja. Stary Wincko dal 2340, teraz beham na 2550... A myslim, ze zdaleka niesom sam

[Eagle]

Su ale aj opacne pripady ako napr. ja. Stary Wincko dal 2340, teraz beham na 2550... A myslim, ze zdaleka niesom sam

Statisticky vzato musí jít dual-core přetaktovat hůř, protože potřebuješ úspěšnost přetaktu u obou jader.

Matematicky zapsáno: Mějme pravděpodobnost a < 1, že jádro půjde přetaktovat na danou frekvenci (libovolně zvolenou). Pak aby šel přetaktovat celý procesor, musí jít přetaktovat obě jádra současně, a tedy musí platit:

a * a < a

[miho]

Statisticky vzato musí jít dual-core přetaktovat hůř, protože potřebuješ úspěšnost přetaktu u obou jader.

Matematicky zapsáno: Mějme pravděpodobnost a < 1, že jádro půjde přetaktovat na danou frekvenci (libovolně zvolenou). Pak aby šel přetaktovat celý procesor, musí jít přetaktovat obě jádra současně, a tedy musí platit:

a * a < a

Tyto vztahy by platily pouze v pripade, ze a1 (jde pretaktovat jadro 1) a a2 (jde pretaktovat jadro 2) jsou jevy nezavisle coz zde urcite neplati (jeden kus kremiku z casti podobne kvality, potazmo stejna serie atd.). P(a1 a soucasne a2) je samozrejme mensi nez P(a1) ale kvuli zavislosti techto jevu je vetsi nez P(a1)*P(a2).

[miho]

...

Odbihame tady opravdu od tematu. Ja mam sve argumenty podporeny benchmarky zverejnenymi na webu a vlastnimi merenimi. Ty tady stale davas nejake teoreticke argumenty (s kterymi BTW nesohlasim) proc by mel byt .net pomalejsi. Budto to podpor necim konkretnim nebo to nema zadnou vypovidaci hodnotu.

Rozdil mezi hodnotovymi typy (int, char...) a referencnimi (Object a jeho potomci) patri k naprostym zakladum .NET. Pokud je nechapes tak je diskuze zbytecna. int je aliasem System.Int32. To nemeni nic na tom, ze promenne tohoto typu nejsou objekty a vznikaji tudiz na zasobniku a ne na halde. Hodnotove typy maji vzdy ekvivalentni objektovy obal, do ktereho se daji zabalit v pripade, kdy je nutne aby se hodnotovy typ choval jako referencni (napr. kolekce.add(1)). Rika se tomu boxing a deje se to jen v situacich, kdy je to nutne.

ad velikost char- Dnes je v zasade vzdy dvojbajtovy (v jave, .NET, ...). V C je jednobajtovy z historickych duvodu. V seriozne minenych programech musis ale pouzit stejne dvojbajtovy wchar. Duvod- do jednoho bajtu se unicode znak strasne blbe cpe.

//edit: abych nezakladal dalsi OT prispevek- pomoci UTF8 neargumentujte, samotny char musi byt dvojbajtovy pac nikdy nevis, co ti prijde. Vnitrni reprezentace retezcu v jave, .net a C++ wchar a ve vetsine dalsich jazyku je taktez dvojbajtova protoze je s tim mnohem snazsi a rychlejsi prace. Zjistete si fakta nez neco napisete.

[Rainbow]

Ked robis v UTF-8, tak ziadne dvojbajtove znaky nepotrebujes.
A uz dost OT.

[Petrik]

Ted mi dosla jedna vec: tento problem je jiz totiz vyresen, jelikoz PPU Aegia ve hrach funguje a tento problem tam zrejmne nenastava, nebo je nejak elegantne osetren Navic, prenost dat z PPU pres PCI-E x16 do CPU je radove pomalejsi a ma radove vetsi latence, nez prenost dat z jednoho jadra DC do druheho, takze v pripadne DC to bude mnohem bezproblemovehjsi.
Jeste jedno upresneni ke GRAW: defautlne jede cela fyzika na havoku, PPU se pouziva pouze pokud je k dispozici na specialni efekty jako jsou vybuchy a pod. Jelikoz GRAW by mel umet vyuzit DC,a to pry dost vyrazne, predpokladam, ze prave havok bezi oddelne.

Dnes vyšel zajímavý článek na The Inquirer. Někdo z redakce hovořil s vývojáři her o možnosti využití quad-core:



Zvýraznil jsem nejdůležitější část. To docela mění zde nastolený směr diskuze - zjevně nebude problém zatížit jedno jádro výpočtem fyziky a kolizí, potíž bude v tom, že chceme-li, aby tato fyzika probíhala realtime (tj. aby například jedno auto neprojelo celé druhým a až pak byla zjištěna kolize), musí být fyzika spočítána hodně rychle, protože se jedná o sekvenční záležitost. A je zřejmě jasné, že když data musíme překopírovat z jednoho CPU do druhého, může DC dokonce i zpomalovat výpočet.

Možná by to šlo vyřešit tak, že jedno jádro bude počítat kolize a fyziku pro jeden frame dopředu, zatímco další jádra aktuální frame. To ale bude docela potíž z hlediska synchronizace a taky tam bude určité zpoždění reakcí na uživatelům vstup (čili zdaleka to nebude optimální).