Vyznam dual core

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