Vyznam dual core

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