Vyznam dual core

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