Dokładnie ten sam kod zwraca różne wyniki przy każdym uruchomieniu

0

Mam taki kod:

#include <cstdint>
#include <cstdio>
#include <bitset>
#include <immintrin.h>
#include<iostream>

uint32_t multiply(uint32_t a, uint32_t b)
    {
        uint32_t p = 4194311;
        uint64_t L = 1;
        uint64_t c;

        //__m128i result = _mm_clmulepi64_si128(_mm_set_epi64x(0, a), _mm_set_epi64x(0, b), 0);
        //uint64_t c = _mm_cvtsi128_si64(result);   // Extract  low 64-bits of result

        for (unsigned int i = 0; i < 32; ++i)
        {
            c ^= a & (L << i) ? (uint64_t)b << i : 0;
        }

        for (unsigned int i = 32; i --> 0; )
        {
            if (c & (L << (i + 32)))
            {
                c ^= L << (i + 32);
                c ^= (uint64_t)p << i;
            }
        }

        return (uint32_t)c;
}

I zwraca mi on za każdym razem inne wyniki dla ciągu pewnych iteracji. Problem jest w:

for (unsigned int i = 0; i < 32; ++i)
        {
            c ^= a & (L << i) ? (uint64_t)b << i : 0;
        }

Bo gdy użyję zamiennie:

__m128i result = _mm_clmulepi64_si128(_mm_set_epi64x(0, a), _mm_set_epi64x(0, b), 0);
uint64_t c = _mm_cvtsi128_si64(result);   // Extract  low 64-bits of result

To wynik za każdym razem jest taki sam. Z tą zagadkową pętlą wyniki są różne, nawet, gdy uruchamiam w konsoli ten sam skompilowany już program.

Moja hipoteza jest taka, że gdzieś następuje jakieś przepełnienie i bity są ucinane w losowych miejscach lub jakoś podmieniane. Może w (uint64_t)b jest problem? c++ nie przestaje mnie zadziwiać, choć pewnie zaraz okaże się, że znów popełniam jakiś trywialny błąd.

1

Podaj cały kod który odpalasz w tej konsoli.

0

Na przykład taki wariant:


#include <cstdint>
#include <cstdio>
#include <bitset>
#include <immintrin.h>
#include<iostream>

    uint32_t multiply(uint32_t a, uint32_t b)
    {
        uint32_t p = 4194311;
        uint64_t L = 1;
        uint64_t c;

        //__m128i result = _mm_clmulepi64_si128(_mm_set_epi64x(0, a), _mm_set_epi64x(0, b), 0);
        //uint64_t c = _mm_cvtsi128_si64(result);   // Extract  low 64-bits of result

        for (unsigned int i = 0; i < 32; ++i)
        {
            c ^= a & (L << i) ? (uint64_t)b << i : 0;
        }

        for (unsigned int i = 32; i --> 0; )
        {
            if (c & (L << (i + 32)))
            {
                c ^= L << (i + 32);
                c ^= (uint64_t)p << i;
            }
        }

        return (uint32_t)c;
}


int main()
{
    uint32_t x = 11111;
    uint32_t result;

    for(int i=0; i<200; i++)
    {
        x = multiply(x,k);
        result = x;

        std::cout << result << "\n";
    }
    return 0;
}

1

Zmieniasz x na każdym kroku pętli, to czemu się dziwisz że jest inaczej?

0

Patrzę na 200 iterację pętli. I raz wynosi ona 1937479107 a innym razem 3251208498. Cała lista liczb jest inna:

Drugie uruchomienie kodu, bez ponownej kompilacji, bez zmieniania niczego w kodzie:

Nic nie zmieniam w kodzie a dostaję zupełnie inne wyniki, gdy go uruchamiam. Jedynie pierwsza iteracja daje zawsze to samo, chyba, bo tego też nie jestem pewien.

Korzystam z aplikacji Ubuntu na Windows, tam to kompiluję, choć piszę kod w Visual Studio. Może to w konsoli jest problem?

1

Zmniejszyłem do 2-ch aby długo nie czekać:

0

A ja dostaję:

$. /mojprogram
367137385
4040469388
$. /mojprogram
367137385
4168303020
$. /mojprogram
367137385
4095167788
$. /mojprogram
367137385
4136574748
$. /mojprogram
367137385
3285852380
$. /mojprogram
367137385
3556439020
$. /mojprogram
367137385
4017922780
$. /mojprogram
367137385
3755137532

Docelowo kod był bardziej skomplikowany. To miał być generator liczb pseudolosowych, ale nie aż tak dobry, że dla tych samych parametrów daje inne wyniki :D

6

A no to wszystko jasne, masz nie zainicjalizowana zmienną c.

0

Faktycznie, zainicjalizowanie c rozwiązuje problem. A co się właściwie dzieje, jeśli jej nie zainicjalizuję? Za każdym razem jest inicjalizowana czym popadnie?

4

Tomasz_D napisał(a):

Faktycznie, zainicjalizowanie c rozwiązuje problem. A co się właściwie dzieje, jeśli jej nie zainicjalizuję? Za każdym razem jest inicjalizowana czym popadnie?

Przyznane jest jej jakieś miejsce w pamięci, które było wcześniej używane przez inne zmienne. W zależności od konfiguracji możesz trafić na całkiem różne wartości.

0

Na oko to jest dla mnie bug w języku programowania per se. Takie rzeczy nie powinny mieć miejsca. Ale pomijając fakt, że wiele rzeczy w c++ mi się nie podoba.

Czy pierwsze obliczenie c nie powinno czyścić tego miejsca w pamięci i umieszczać tam wyniku, dokładnie jak przy pierwszej iteracji? Jeśli tak to dlaczego akurat pierwsza iteracja jest zawsze taka sama? Nie rozumiem jak można c ^= a & (L << i) ? (uint64_t)b << i : 0; wymieszać z czymś innym, podczas, gdy jest określone, że ma to być uint64_t. Nawet, jeśli nie ma sensu trzymać pustego miejsca uint64_t, dopóki nie zostanie użyta zmienna, to jak można miejsca jej dedykowanego nie wyczyścić, gdy zostaje wywołania/użyta?

Czy takie rzeczy nie powinny zostać wyeliminowane z języka programowania w ogóle?

4

Na oko to jest dla mnie bug w języku programowania per se. Takie rzeczy nie powinny mieć miejsca.

Jest to popularny pogląd, bo to faktycznie jest błędogenne. Tym niemniej, istnieje sporo sytuacji, w których nie chcemy tracić na niepotrzebną inicjalizację zmiennej (bo planujemy ją potem zainicjalizować sami), i w takich sytuacjach zachowanie C++ ma sens.

Czy pierwsze obliczenie c nie powinno czyścić tego miejsca w pamięci i umieszczać tam wyniku, dokładnie jak przy pierwszej iteracji?

Nie powinno, bo tam już coś jest. Nie to, co chciałeś, być może, ale C++ o tym nie wie i o to nie dba — z punktu widzenia języka nie ma różnicy między przypadkowymi, a celowo wpisanymi danymi. Alternatywą byłoby trzymanie „sprawdzarki” dla każdej zmiennej, która pilnuje za programistę, czy on już coś z tą zmienną zrobił, czy nie.

Nawet, jeśli nie ma sensu trzymać pustego miejsca uint64_t, dopóki nie zostanie użyta zmienna, to jak można miejsca jej dedykowanego nie wyczyścić, gdy zostaje wywołania/użyta?

Bo czyszczenie kosztuje, a nie zawsze jest potrzebne — w szczególności, nie ma sensu czyścić przed zapisem (bo i tak zapis nadpisze to, co tam było). To tak, jakbyś chciał zawsze mieć x = 0; x = y; zamiast samego x = y.

2

Kompilatory C++ zwykle maja flagę, która wstrzymuje kompilację po wykryciu błędu typu użycie niezainicjalizowanej zmiennej, brak instrukcji return w funkcji mającej zwrócić wartość itp. W gcc to -Werror -Wall -Wextra.

Nie jest też oczywiste jaką wartość przypisać na początku, np.:

long long silnia(int n)  {
  long long wynik; // samoczynne wyzerowanie nie pomaga, trzeba podstawić jeden
  for (int i = 1; i <= n; ++i) {
    wynik *= i;
  }
  return wynik;
}

0

Ad vocem. Jeśli nie zrobimy castingu, to mogą się dziać chyba podobne rzeczy. Liczyłem przed chwilą coś takiego:

__int128 output = ((x1 ^ (h1_h0 >> 64)) << 64) | (x0 ^ (uint64_t)h1_h0);

Gdzie x0 to __int128, ale wcześniej umieściłem tam pewne liczby tylko w dolnych 64 bitach:

__int128 x0 = _mm_cvtsi128_si64(d1_d0);

I dostaję błędne wyniki. Dopiero zapisanie:

__int128 output = ((x1 ^ (h1_h0 >> 64)) << 64) | ((uint64_t)x0 ^ (uint64_t)h1_h0);

Nie powoduje pewnych dziwnych problemów. W tych dwóch przypadkach wyniki są inne. Co więcej wygląda na to, że do górnej połówki tego inta wędrują jakieś powiązane z poprzednimi wynikami bity, jeśli nie zrobimy castingu.

1

Niech ktoś jeszcze powie koledze o braku kontroli wartości indeksu przy odczycie tablicy :)

Dokładnie ten sam kod zwraca różne wyniki przy każdym uruchomieniu

Tomasz_D napisał(a):

1 użytkowników online, w tym zalogowanych: 0, gości: 1

Praca dla programistów

Forum dyskusyjne

Sprawy administracyjne

O nas

Skontaktuj się z nami