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ť

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