Jakie są zagrożenia podczas tworzenia wątku o rozmiarze stosu 50x domyślnym?

Odkryłem 530% wzrost szybkości przetwarzania!

Jest bardzo, bardzo trudno pochłonąć dużo miejsca na stosie w programie. NET, poza nadmierną rekurencją. Rozmiar ramki stosu zarządzanych metod jest ustawiany w kamieniu. Po prostu suma argumentów metoda i zmienne lokalne w metodzie. Pomijając te, które mogą być przechowywane w rejestrze procesora, możesz to zignorować, ponieważ jest ich tak mało.

Zwiększenie rozmiaru stosu nic nie da, po prostu zarezerwujesz trochę przestrzeni adresowej, która nigdy nie zostanie użyta. Nie ma mechanizmu, który mógłby wyjaśnić wzrost perf z nieużywania pamięci oczywiście.

Jest to w przeciwieÅ„stwie do natywnego programu, szczególnie tego napisanego w C, może on również rezerwować miejsce na tablice na stack frame. Podstawowy wektor ataku zÅ‚oÅ›liwego oprogramowania za przepeÅ‚nieniami bufora stosu. Możliwe również w C#, trzeba by użyć sÅ‚owa kluczowego stackalloc. JeÅ›li to robisz, oczywistym niebezpieczeÅ„stwem jest konieczność napisania niebezpiecznego kodu, który podlega takim atakom, a także uszkodzenie losowej ramki stosu. Bardzo trudne do zdiagnozowania bÅ‚Ä™dy. Istnieje przeciwdziaÅ‚anie temu w późniejszych treÅ›ciach, myÅ›lÄ™, że zaczynajÄ…c od. NET 4.0, gdzie jitter generuje kod, aby umieÅ›cić "cookie" na ramce stosu i sprawdza, czy jest w stanie nienaruszonym po powrocie metody. Natychmiastowa awaria na pulpicie bez możliwoÅ›ci przechwycenia lub zgÅ‚oszenia awarii, jeÅ›li tak siÄ™ stanie. Tak ... niebezpieczne dla stanu psychicznego użytkownika.

Główny wątek programu, ten uruchomiony przez system operacyjny, będzie miał domyślnie 1 MB stosu, 4 MB podczas kompilacji programu kierującego x64. Zwiększenie tego wymaga uruchomienia Editbin.exe z opcją / STACK w zdarzeniu post build. Zazwyczaj można poprosić o maksymalnie 500 MB przed program będzie miał problemy z uruchomieniem podczas pracy w trybie 32-bitowym. Wątki też mogą, oczywiście o wiele łatwiej, strefa zagrożenia Zwykle unosi się wokół 90 MB dla programu 32-bitowego. Wywołane, gdy program był uruchomiony przez długi czas, a przestrzeń adresowa została fragmentowana z poprzednich przydziałów. Całkowite wykorzystanie przestrzeni adresowej musi być już wysokie, ponad GIGA, aby uzyskać ten tryb awarii.

Chciałbym mieć tam zastrzeżenie, że po prostu nie wiem , jak to przewidzieć-uprawnienia, GC (który musi skanować stos), itp-wszystko może mieć wpływ. Bardzo bym się skusił, żeby zamiast tego użyć pamięci niezarządzanej:

var ptr = Marshal.AllocHGlobal(sizeBytes);
try
{
    float* x = (float*)ptr;
    DoWork(x);
}
finally
{
    Marshal.FreeHGlobal(ptr);
}

JednÄ… rzeczÄ…, która może pójść źle, jest to, że możesz nie dostać pozwolenia na to. JeÅ›li nie dziaÅ‚a w trybie peÅ‚nego zaufania, Framework zignoruje żądanie o wiÄ™kszy rozmiar stosu (zobacz MSDN on Thread Constructor (ParameterizedThreadStart, Int32))

Zamiast zwiększać rozmiar stosu systemowego do tak ogromnej liczby, sugerowałbym przepisanie kodu tak, aby używał iteracji i ręcznej implementacji stosu na stercie.

Tablice o wysokiej wydajności mogą być dostępne w taki sam sposób, jak normalne C#, ale może to być początek kłopotów: rozważ następujący kod:

float[] someArray = new float[100]
someArray[200] = 10.0;

Spodziewasz się wyjątku out of bound i to ma sens, ponieważ próbujesz uzyskać dostęp do elementu 200, ale maksymalna dozwolona wartość to 99. Jeśli przejdziesz do trasy stackalloc, nie będzie żadnego obiektu owiniętego wokół tablicy, aby sprawdzić Wiązanie, a poniższe nie pokażą żadnych wyjątek:

Float* pFloat =  stackalloc float[100];
fFloat[200]= 10.0;

Powyżej przydzielasz wystarczającą ilość pamięci do przechowywania 100 pływaków i ustawiasz lokalizację pamięci sizeof (float), która rozpoczyna się w miejscu uruchomionym tej pamięci + 200*sizeof(float) do przechowywania wartości float 10. Nic dziwnego, że pamięć ta znajduje się poza przydzieloną pamięcią dla pływaków i nikt nie wiedziałby, co może być przechowywane w tym adresie. Jeśli masz szczęście, możesz użyć obecnie nieużywanej pamięci, ale jednocześnie prawdopodobnie możesz nadpisuje lokalizację używaną do przechowywania innych zmiennych. Podsumowując: nieprzewidywalne zachowanie środowiska uruchomieniowego.

Mikrobenchmarking języków z JIT i GC, takich jak Java lub C# może być nieco skomplikowany, więc ogólnie dobrym pomysłem jest użycie istniejącego frameworka-Java oferuje mhf lub Caliper, które są doskonałe, niestety z mojej najlepszej wiedzy C# nie oferuje niczego zbliżającego się do nich. Jon Skeet napisał to Tutaj, które ślepo zakładam, zajmuje się najważniejszymi rzeczami(Jon wie, co robi w tej dziedzinie; również tak, nie martwiłem się, że faktycznie sprawdziłem). Trochę podkręciłem czas bo 30 sekund na test po rozgrzewce to za dużo jak na moją cierpliwość (5 sekund powinno wystarczyć).

Więc najpierw wyniki,. NET 4.5.1 pod Windows 7 x64 -- liczby oznaczają iteracje, które może uruchomić w 5 sekund, więc wyższe jest lepsze.

X64 JIT:

Standard       10,589.00  (1.00)
UnsafeStandard 10,612.00  (1.00)
Stackalloc     12,088.00  (1.14)
FixedStandard  10,715.00  (1.01)
GlobalAlloc    12,547.00  (1.18)

X86 JIT (tak to jeszcze trochÄ™ smutne):

Standard       14,787.00   (1.02)
UnsafeStandard 14,549.00   (1.00)
Stackalloc     15,830.00   (1.09)
FixedStandard  14,824.00   (1.02)
GlobalAlloc    18,744.00   (1.29)

A oto kod:

public static float Standard(int size) {
    float[] samples = new float[size];
    for (var ii = 0; ii < size; ii++) {
        samples[ii] = 32768 + (ii != 0 ? samples[ii - 1] : 0);
    }
    return samples[size - 1];
}

public static unsafe float UnsafeStandard(int size) {
    float[] samples = new float[size];
    for (var ii = 0; ii < size; ii++) {
        samples[ii] = 32768 + (ii != 0 ? samples[ii - 1] : 0);
    }
    return samples[size - 1];
}

public static unsafe float Stackalloc(int size) {
    float* samples = stackalloc float[size];
    for (var ii = 0; ii < size; ii++) {
        samples[ii] = 32768 + (ii != 0 ? samples[ii - 1] : 0);
    }
    return samples[size - 1];
}

public static unsafe float FixedStandard(int size) {
    float[] prev = new float[size];
    fixed (float* samples = &prev[0]) {
        for (var ii = 0; ii < size; ii++) {
            samples[ii] = 32768 + (ii != 0 ? samples[ii - 1] : 0);
        }
        return samples[size - 1];
    }
}

public static unsafe float GlobalAlloc(int size) {
    var ptr = Marshal.AllocHGlobal(size * sizeof(float));
    try {
        float* samples = (float*)ptr;
        for (var ii = 0; ii < size; ii++) {
            samples[ii] = 32768 + (ii != 0 ? samples[ii - 1] : 0);
        }
        return samples[size - 1];
    } finally {
        Marshal.FreeHGlobal(ptr);
    }
}

static void Main(string[] args) {
    int inputSize = 100000;
    var results = TestSuite.Create("Tests", inputSize, Standard(inputSize)).
        Add(Standard).
        Add(UnsafeStandard).
        Add(Stackalloc).
        Add(FixedStandard).
        Add(GlobalAlloc).
        RunTests();
    results.Display(ResultColumns.NameAndIterations);
}

Ponieważ różnica w wydajności jest zbyt duża, problem jest ledwo związany z alokacją. Jest to prawdopodobnie spowodowane dostępem do tablicy.

Zdemontowałem ciało pętli funkcji:

Testmetod1:

IL_0011:  ldloc.0 
IL_0012:  ldloc.1 
IL_0013:  ldc.i4.4 
IL_0014:  mul 
IL_0015:  add 
IL_0016:  ldc.r4 32768.
IL_001b:  stind.r4 // <----------- This one
IL_001c:  ldloc.1 
IL_001d:  ldc.i4.1 
IL_001e:  add 
IL_001f:  stloc.1 
IL_0020:  ldloc.1 
IL_0021:  ldc.i4 12500000
IL_0026:  blt IL_0011

Testmetod2:

IL_0012:  ldloc.0 
IL_0013:  ldloc.1 
IL_0014:  ldc.r4 32768.
IL_0019:  stelem.r4 // <----------- This one
IL_001a:  ldloc.1 
IL_001b:  ldc.i4.1 
IL_001c:  add 
IL_001d:  stloc.1 
IL_001e:  ldloc.1 
IL_001f:  ldc.i4 12500000
IL_0024:  blt IL_0012

Możemy sprawdzić użycie instrukcji, a co ważniejsze, wyjątek dorzucają ECMA spec :

stind.r4: Store value of type float32 into memory at address

WyjÄ…tki rzuca:

System.NullReferenceException

I

stelem.r4: Replace array element at index with the float32 value on the stack.

Exception it rzuty:

System.NullReferenceException
System.IndexOutOfRangeException
System.ArrayTypeMismatchException

Jak widzisz, stelem dziaÅ‚a bardziej w sprawdzaniu zakresu tablic i sprawdzaniu typów. Ponieważ ciaÅ‚o pÄ™tli robi niewiele (przypisuje tylko wartość), narzut sprawdzania dominuje w czasie obliczeÅ„. Dlatego wydajność różni siÄ™ o 530%.

I to również odpowiada na twoje pytania: zagrożeniem jest brak sprawdzania zakresu i typu tablicy. Jest to niebezpieczne (jak wspomniano w deklaracji funkcji; D).

EDIT: (mała zmiana w kodzie i w pomiarach powoduje dużą zmianę w wyniku)

Najpierw uruchomiÅ‚em zoptymalizowany kod w debuggerze (F5), ale to byÅ‚o zÅ‚e. Powinno być uruchamiane bez debuggera (Ctrl+F5). Po drugie, kod może być dokÅ‚adnie zoptymalizowany, wiÄ™c musimy go skomplikować, aby optymalizator nie zadzieraÅ‚ z naszymi pomiarami. SprawiÅ‚em, że wszystkie metody zwracajÄ… ostatniÄ… pozycjÄ™ w tablicy, a tablica jest wypeÅ‚niona inaczej. Ponadto istnieje dodatkowe zero W op TestMethod2, które zawsze sprawia, że dziesięć razy wolniej.

    public static unsafe float TestMethod3()
    {
        float[] samples = new float[5000000];

        for (var ii = 0; ii < 5000000; ii++)
        {
            samples[ii] = 32768 + (ii != 0 ? samples[ii - 1] : 0);
        }

        return samples[5000000 - 1];
    }

    public static unsafe float TestMethod4()
    {
        float[] prev = new float[5000000];
        fixed (float* samples = &prev[0])
        {
            for (var ii = 0; ii < 5000000; ii++)
            {
                samples[ii] = 32768 + (ii != 0 ? samples[ii - 1] : 0);
            }

            return samples[5000000 - 1];
        }
    }

    public static unsafe float TestMethod5()
    {
        var ptr = Marshal.AllocHGlobal(5000000 * sizeof(float));
        try
        {
            float* samples = (float*)ptr;

            for (var ii = 0; ii < 5000000; ii++)
            {
                samples[ii] = 32768 + (ii != 0 ? samples[ii - 1] : 0);
            }

            return samples[5000000 - 1];
        }
        finally
        {
            Marshal.FreeHGlobal(ptr);
        }
    }