[BloodDeath94]

Na #studbaza mieliśmy zrobić program który m.in. ma przemielić plik z danymi. Ja robiłem w #cpp, kolega w #csharp "bo nie trzeba pisać tyle kodu"
u mnie wczytanie pliku i sparsowanie danych zajmuje około


a u kolegi w super C Sharpie



troche #humorinformatykow

[b.....l]

@BloodDeath94 w asm trza bylo pisac

[kyaroru]

@BloodDeath94: A teraz przeróbcie te programy tak, żeby otworzyły, przemieliły i zapisały ten plik powiedzmy 100000 razy i zmierzcie czas wtedy.

[ogrod87]

@BloodDeath94: Ale wiesz, że jezyk to tylko narzędzie? Można zoptymalizować i w C# zrobić to szybko, natomiast cpp będzie robiło to wieki? Czy tego na studiach nie uczą?

[YuiMizuno]

@BloodDeath94: w jaki sposób 7 cykli? Przecież samo wywołanie jakiejkolwiek funkcji to jest kilka cykli (wywołanie funkcji, zrzucenie ramki stosu, etc.)?

[kyaroru]

@ogrod87: O czym my tu w ogóle dyskutujemy jak >99% czasu działania tego programu w C# to narzut na odpalenie środowiska dotnetowego i inicjalizacja różnych bibliotecznych pierdół:))

[BloodDeath94]

@kyaroru @YuiMizuno: tzn mierzymy czas tak, ze pobieramy ilosc cykli procesora od uruchomienia programu przed rozpoczeciem odczytu danych z pliku i po odczycie danych z pliku.

[YuiMizuno]

@BloodDeath94: nie wiem jak to mierzycie, ale tutaj masz przykładowy assembler z C który otwiera plik, wczytuje 64 bajtów i zamyka plik:

mov DWORD PTR [esp+4], OFFSET FLAT:LC0

mov DWORD PTR [esp], OFFSET FLAT:LC1

call fopen

mov

[BloodDeath94]

@YuiMizuno tzn jestem noobem i może użyłem złego określenia. Chodzi mi o wartość zwracana przez funkcje clock()

[YuiMizuno]

@BloodDeath94: a jak to sprawdzałeś w c#?

[BloodDeath94]

@YuiMizuno to kolegi muszę spytać, on tam robił ale mówił, że jakoś podobnie tylko użył jakiejś csharpowej funkcji

[BloodDeath94]

@YuiMizuno kolega użył stopwatcha

[BloodDeath94]

@Kamasetto podejrzewam, że wystartował stopwatcha przed rozpoczęciem odczytywania i odczytał wartość po zakończeniu

[YuiMizuno]

@BloodDeath94: generalnie nie powinno się pobierać wartości clock i interpretować jej jako cykle zegarowe.

The value returned is expressed in clock ticks, which are units of time of a constant but system-specific length (with a relation of CLOCKSPERSEC clock ticks per second).

Głównie dlatego, że aktualne procesory mają chociażby zmienne taktowanie oraz procesy skaczą między różnymi rdzeniami.
Jedyny słuszny sposób porównywania to czas i też w taki sposób,

[BloodDeath94]

@YuiMizuno na komputerze kolegi mój program wykonywał się jeszcze szybciej niż u mnie.
Jakby różnice były w dziesiątkach albo setkach tickow to bym był skłonny sądzić że możliwe że przy lepszym sposobie porównania różnice byłyby mniejsze.

Ale najmniejsza wartość jaka uzyskaliśmy dla csharpa to 14k

A największą dla c++ to było kilkadziesiąt

[YuiMizuno]

@BloodDeath94: tak, tylko nie wypada porównywać dwóch rzeczy mając zupełnie 2 różne metody pomiarowe. Kto wie czy obie metody mają dokładnie taką samą liczbę 'ticków' na sekundę?
W moim prostym przykładzie na otwarcie pliku, odczytanie i zamknięcie go uzyskuję wynik 0 ticków w clock().
A jak dodam Sleep(1000) to już uzyskuję 1016 ( ͡° ͜ʖ ͡°)

[BloodDeath94]

@YuiMizuno to jaka metodę pomiarowa proponujesz, skoro porównywanie znalezionymi metodami dla tych języków na tym samym procesorze jest niedobre?

[YuiMizuno]

@BloodDeath94: pomiar czasu wykonania całego pliku wykonywalnego.
I jeżeli chcesz pominąć narzut czasu uruchomienia programu, to tych operacji powinno być dużo. Nawet rzędu kilkuset tysięcy.
No i najlepiej by było przy każdej iteracji otwierać inny plik, żeby nie ryzykować cache'owania zawartości plików.

[BloodDeath94]

@YuiMizuno a w jaki konkretnie sposób mierzyć czas wykonania pliku wykonywalnego. Bo może ta informacja która daje środowisko też jest niewłaściwa ( ͡° ͜ʖ ͡°)

[Vetinari]

@BloodDeath94: Stoperem. Na tym samym urządzeniu. I przy zbliżonej implementacji. On może zapisywać do pamięci a Ty wypisywać na ekran. Piszę w C++ na co dzień, często piszę w C# i C++/CLI jestem pewien, że wyniki nie są w ogóle miarodajne.