Wszystkie odpowiedzy wyżej to WAT?
Co wówczas właściwie trafia do k?
Śmieci. Niezainicjalizowana wartość. Jest to Undefined behaviour, i może prowadzić do dowolnych błędnych optymalizacji kompilatora. Nie wolno tak robić!!!
Aha, tak właśnie przeczuwałem. Ale w takim razie, czy to można uznać za poprawne:
https://prng.di.unimi.it/splitmix64.c
Czy, gdy k już zostanie zainicjowane, to taka funkcja będzie działać tak samo jak w pierwszym przypadku z arytmetycznego punktu widzenia?
Nie, kompilator może wykonać dowolne bezsensowne transformacje kodu, bo kod jest błędny, a więc żaden poprawny program by nigdy jej nie uruchomił.
Czy mimo wszystko może być szybciej wykonywana?
Może być. Np. kompilator zauważy, że to błędny kod, i po prostu go usunie (a więc uzyskasz prędkość nieskończoną).
Czy, jeśli nie zależy mi na tym co za liczba trafi początkowo do k (ale w kolejnych powtórzeniach musi być obliczane prawidłowo k = k + x, jak w pierwszym przykładzie), taka implementacja ma sens?
Nie.
Ogólnie, z tego co widzę, gcc -O2 po prostu zakłada, że początkowa wartość k
to 0, nigdy nie patrząc co było wcześniej. Ale możesz nie mieć takiego szczęścia. No a tak czy inaczej, nie spełnia to twoich wymagań funkcjonalnych.
Ok, czyli porzucam podobne pomysły. Tylko co z tym SplitMixem, czy tam też jest błąd w sztuce? Swoją drogą to jest kod, który przywiódł mi na myśl podobne pomysły, sam bym nie wpadł na to, żeby robić takie rzeczy. Ale w tym kodzie robią. Chyba, że nie dostrzegam różnicy, a różnica jest.
Na marginesie, czy ktoś zdaje sobie na tym forum sprawę z permanentnego, uciążliwego błędu, który nie pozwala na normalną dyskusję, bo co chwilę przy próbie wysłania komentarza lub odpowiedzi wyskakuje "Zbyt wiele prób. Spróbuj za chwilę."?