Po zapoznaniu się z tematem, istnieje wiele dowodów z wielu źródeł, że używanie standardowych rzutów C lub C++ do konwersji z liczb zmiennoprzecinkowych na liczby całkowite na Intel jest bardzo powolne. Aby spełnić specyfikację ANSI/ISO, procesory Intela muszą wykonać wiele instrukcji, w tym te potrzebne do przełączenia trybu zaokrąglania sprzętu FPU.Jak zapewnić, że wydruk jest inline w gcc?
W różnych dokumentach opisano kilka obejść, ale najczystszym i najbardziej przenośnym wydaje się być połączenie lrint() dodane do standardów C99 i C++ 0x. Wiele dokumentów mówi, że kompilator powinien rozszerzać te funkcje, gdy włączona jest optymalizacja, prowadząc do kodu, który jest szybszy niż konwencjonalny rzut lub wywołanie funkcji.
Znalazłem nawet odniesienia do worków śledzenia cech gcc, aby dodać tę wbudowaną ekspansję do optymalizatora gcc, ale w moich własnych testach wydajności nie mogłem go uruchomić. Wszystkie moje próby pokazują, że wydajność drukowania jest znacznie wolniejsza niż zwykła obsada stylu C lub C++. Analiza wyjścia zespołu kompilatora i rozmontowanie skompilowanych obiektów zawsze pokazuje jawne wywołanie zewnętrznej funkcji lrint() lub lrintf().
Wersje gcc, nad którymi pracowałem, to: 4.4.3 i 4.6.1, a także wypróbowałem wiele kombinacji flag w 32-bitowych i 64-bitowych miejscach docelowych x86, w tym opcje umożliwiające jawne włączenie SSE.
Jak uzyskać dostęp do gcc w linii rozwijanej lrint i uzyskać szybką konwersję?
Czy rzeczywiście wyprofilowałeś i potwierdziłeś, że używanie oczywistych rzutów znaczna część środowiska wykonawczego twojego programu? –
Profilowanie pokazuje, że mogę uzyskać różnicę prędkości 2-4%, używając ręcznie napisanego makra asemblera unoszonego z artykułu. Jest to opłacalne, ponieważ obliczenia wykonywane są między ramkami aplikacji do renderowania 3D. –
czy ustawiłeś '-fno-math-errno'? powinieneś także rozważyć użycie '-ffast-math', która nie zawsze jest opcją, jeśli polegasz na specyficznej selekcji fp ... – Christoph