Vyznam dual core

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