W C++, próbuję napisać opakowanie wokół 64-bitowej liczby całkowitej. Oczekuję, że jeśli napisano poprawnie i wszystkie metody zostały wstawione, to takie opakowanie powinno być tak wydajne, jak typ rzeczywisty. Odpowiedź na to question na SO wydaje się zgadzać z moimi oczekiwaniami.Dlaczego VC++ nie może zoptymalizować opakowania całkowitego?
Napisałem ten kod, aby przetestować moje oczekiwania:
class B
{
private:
uint64_t _v;
public:
inline B() {};
inline B(uint64_t v) : _v(v) {};
inline B& operator=(B rhs) { _v = rhs._v; return *this; };
inline B& operator+=(B rhs) { _v += rhs._v; return *this; };
inline operator uint64_t() const { return _v; };
};
int main(int argc, char* argv[])
{
typedef uint64_t;
//typedef B T;
const unsigned int x = 100000000;
Utils::CTimer timer;
timer.start();
T sum = 0;
for (unsigned int i = 0; i < 100; ++i)
{
for (uint64_t f = 0; f < x; ++f)
{
sum += f;
}
}
float time = timer.GetSeconds();
cout << sum << endl
<< time << " seconds" << endl;
return 0;
}
Kiedy uruchomić to z typedef B T
; zamiast typedef uint64_t T
podane czasy są konsekwentnie o 10% wolniejsze podczas kompilacji z VC++. W g ++ wydajność jest taka sama, jeśli używam opakowania lub nie.
Ponieważ g ++ robi to, myślę, że nie ma żadnego technicznego powodu, dla którego VC++ nie może zoptymalizować tego poprawnie. Czy jest coś, co mógłbym zrobić, aby go zoptymalizować?
Już próbowałem grać z flagą optymalizacje bez powodzenia
Czy uruchomiłeś kod z Visual Studio lub z konsoli Windows? – jpo38
Nie będę zaskoczony, jeśli g ++ złożył całą pętlę. –
Zanurz się w wygenerowanym zespole! –