Új hozzászólás Aktív témák
-
pmonitor
aktív tag
válasz
pmonitor
#9458
üzenetére
Az egészet arra éleztem ki, hogy a "fő programom"(a cutter) esetében sokat kell tömböt másolni. Igaz, hogy csak kis méretűeket. És ezt rekurzívan kell tenni(ismétléses permutáció generálásához). A Win api CopyMemory() esetén lényegesen gyorsabb lett az ismétléses permutáció generálása(a rekurzív hívásokban lévő tömb másolások gyorsulása miatt.) .
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
válasz
pmonitor
#9458
üzenetére
static unsafe void teszt_6(int[] source, int n){int[] dest = new int[n];fixed (int* pSource = source, pdest = dest){int* pSource_0 = pSource;int* pdest0 = pdest;int* pmax = pSource_0 + n;for (; pSource_0 < pmax; ++pSource_0, ++pdest0){*pdest0 = *pSource_0;}}}mivel a metódusnak visszatérési értéke nincsen (void), a program végeredménye szempontjából lényeges mellékhatás sincsen (nincsen IO, nem változtat semmilyen állapotot) ezért ezért honnan tudod, hogy futás közben release + optimalizáció beállítással ez egyáltalán lefut? (valószínűleg lefut, de nem kéne)
Ráadásul a timert úgy indítod-állítod le, hogy a memóriamásoláson kívül szinte minden tesztesetedben van ciklikus heap allokáció is. Ha nagyot foglalsz a heapen akkor az triggerelhet egy GC futást is.
Mivel a teszt-metódusaidat ciklusban futtatod, az iterációk között teleszemeteled a heapet halott objektumokkal ezért FOG futni a GC, többször, sokszor. A GC futás valószínűleg több időbe kerül mint maga a memóriamásolás. (pld mert a memóriaterületeket valamikor nullázni is kell stb) . Innentől kezdve a méréseid pontatlanok.
Ha memóriát akarsz kézzel másolni, akkor #9455 szigorúan allokáció nélkül. az kimaxolja a mem sávszélt, az a másolás sebességének elméleti határa
====
Az egészet arra éleztem ki, hogy a "fő programom"(a cutter) esetében sokat kell tömböt másolni. Igaz, hogy csak kis méretűeket.
Csak másolni kell a tartalmat egyik helyről a másikra vagy allokálni kell és feltölteni? Elég jelentős a különbség. (nem ismerem a feladatot)
====
A legnagyobb meglepetést azonban az Unsafe kód okozta. Kis méretű tömb esetén a "középmezőnyben" van. Nagy méretű tömb esetén azonban lényegesen a leggyorsabban végez az összes többinél.
Két oka van:
1,
Az eredeti unsafe teszt-metódusodban nem volt for ciklusos heap allokáció hanem stackalloc volt => nincs GC a szemét eltakarítására, összehasonlíthatatlanul gyorsabb. Az összes többi teszt ahol new int[n] hívódik ciklikusan hatalmas handikeppel indult...
2,
Az unsafe kikapcsolja a tömb hozzáférések során az indexer értéktartomány ellenőrzését. ezzel csökkentetted a ciklusonkénti munkát (indexer értékhatár ellenőrzés + mem másolás helyett csak mem másolás). Gondolom a többi library metódus is unsafe-ként van belül megvalósítva. Csak ugye lsd 1. pont[ Szerkesztve ]
Új hozzászólás Aktív témák
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
