🚀 go-pugleaf

Jaka tu cisza i spokój... Raj socjopaty. :-)

No, dobra...

Całe moje programowanie polega na tworzeniu aplikacji, które mają zassać dane, wymłócić je i wypluć wyniki - tyle, że tych danych bywa sporawo.
Używam Code::Blocks z MinGW i różne mam z nim przygody, o czym pewnie jeszcze napiszę, ale ostatnio kompletnie szlag mnie trafił, bo nie mogłem nigdzie znaleźć mojej "ulubionej" funkcji sincos() - a takie odwołanie FPU pamiętam z niegdysiejszych zainteresowań asemblerem.
Rozważałem nawet powrót/przejście na inny kompilator, Borland, albo Microsoft, ale to byłby tylko półśrodek, w dodatku kłopotliwy.
Mamy przecież koprocesor, który tylko czeka na instrukcje. :-)

Podrążyłem trochę temat i znalazłem rozwiązanie, od razu zbenchmarkowane:


volatile double a = 0.55;
...
for (n = 0; n < nIterations; n++)
{
   asm ("fldl %2;"
        "fsincos;"
        "fstpl %1;"
        "fstpl %0;"
        : "=m"(sin_a), "=m"(cos_a) : "m"(a));
}


Przy nIterations = 50 000 000 całość liczy się nieco ponad sekundę, natomiat przy użyciu sin() i cos() z math.h... prawie cztery.
Dla pojedynczych funkcji przyśpieszenie nie jest aż tak spektakularne, ale i tak wychodzi ponad dwa razy szybciej.
Warto więc się było nad tematem pochylić. No i kodowanie "na żywca", bez użycia zewnętrznych bibliotek jest jakby bardziej... sexy! :-)

Znalazłem taką stronę z gotowcami:

https://www.willus.com/mingw/_fastmath.shtml

Ale tam czytam:
I've noticed lately that the difference between my in-lines and the gcc 3.x/4.x defaults depends significantly on what arguments are sent to the functions. Sometimes mine are faster; sometimes the gcc defaults are faster. In general, with gcc 4.x, I've found that only my sincos in-line gives me any benefit over the gcc default on Core 2 processors, and it's not by much. 


Może ktoś mi wytłumaczyć, o co tu biega?
Bo albo gość zmaścił odwołania FPU, albo GCC nie umie prawidłowo obsłużyć odwołań, albo te wbudowane funkcje liczą sinusy na jakimś SSE/AVX (w co wątpię).
Ja w każdym razie mam odmienne doświadczenia (chyba, że się nie znam).



Druga sprawa - fajnie było czytać stare książki o asemblerze, przedstawiające program jako sekwencję instrukcji.
Ale teraz kończymy drugą dekadę XXI wieku - procesory mają wiele rdzeni, a system ujeżdża jednocześnie kupę procesów.
Co się dzieje, jeśli w sam środek misternie poskładanego zestawu instrukcji wpierdzieli nam się inny proces?