2. Fórumok
  3. Szoftverfejlesztés
  4. C# programozás
Keresés

Új hozzászólás Aktív témák

  • #9460 joysefke veterán pmonitor #9458
    Új Válasz #9460
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    joysefke

    veterán

    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

  • #9459 pmonitor aktív tag pmonitor #9458
    Új Válasz #9459
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

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

Új hozzászólás Aktív témák