W jaki sposób „liczby opóźnień Jeffa Deana, które powinien znać każdy programista” mogą być dokładne w kontekście różnych implementacji sprzętowych?

Mam na myśli tę tabelę latencji , przypisaną Jeffowi Deanowi z Google.

Nie rozumiem tylko, czy te liczby nie różnią się w zależności od zestawu sprzętu? Jak mogą być dokładne dla wszystkich różnych rodzajów pamięci RAM, procesora, płyty głównej, dysku twardego itp.?

Liczby te (wymienione również w Norvig's Teach yourself Programming za 10 lat ) są przybliżone, użyteczne tylko jako (rząd) wielkości.

W rzeczywistości dzisiejszy sprzęt (przynajmniej dla komputerów stacjonarnych lub laptopów) nie różni się tak bardzo, nawet między tanim laptopem o wartości 300 EUR a wysokiej klasy stacją roboczą o wartości 10 000 EUR. Prędkość zmienia się co najwyżej 2 lub 4 razy. Taka stacja robocza może mieć większy dysk, więcej rdzeni, pamięć podręczną i pamięć RAM. Nie ma to jednak większego wpływu na surową wydajność jednowątkową.

Spójrz na niektóre dane na http://openbenchmarking.org/ lub niektóre komparatory procesorów.

Tzw Prawo Moore'a jest umierający . Mój 3-letni komputer stacjonarny w domu (i3770K) mógłby zostać zastąpiony (dzisiaj, w marcu 2016 r.) Przez jakiś i6700, który jest tylko o 20% szybszy.

Liczby nie mają być dokładne. Liczy się stosunek między rzędami wielkości między poziomami .

Jednak gdy pojawi się przełomowa technologia (np. Przetwarzanie w chmurze, Ethernet 10 GB / 100 GB, nowy moduł jądra sieciowego, sieci pamięci masowej SSD, wirtualizacja i konteneryzacja), liczby te mogą zostać unieważnione z powodu pojawienia się, zniknięcia lub przetasowania nowych warstw.

Podczas programowania na bardzo wysokim poziomie - gdzie wszystkie obliczenia, tworzenie sieci, parsowanie itp. Są wykonywane przy użyciu bibliotek, które nie zostały napisane przez ciebie, znajomość wydajności operacji niskiego poziomu może nie pomóc, ponieważ Twoja szansa na ulepszenie każdego z nich wydajność biblioteki jest raczej ograniczona lub wręcz niemożliwa.

Zamiast tego przeczytaj uważnie dokumentację związaną z wydajnością każdej biblioteki. Jeśli do biblioteki nie ma tych, poproś ich - zrób z tego problem. Lub dowiedz się, jak poprawnie testować oprogramowanie.

Podstawowa znajomość liczb opóźnień jest ważna, gdy jesteś zatrudniony przez firmę, która projektuje i produkuje komponenty oprogramowania. Porównaj to z firmą, która projektuje i produkuje samochody i wszystkie elementy w nich zawarte - przysłowiowe „wynalezienie koła” (guma, ciśnienie w oponach, bieżniki itp.)

Większość firm programistycznych nie działa na poziomie komponentów - całe funkcjonalne systemy oprogramowania można zbudować z połączenia komponentów. Firmy produkujące oprogramowanie nie muszą koncentrować się na tym, jak projektować komponenty pod względem opóźnień; zamiast tego muszą ocenić jakość wybranych komponentów.

Podsumowując: (1) jest bardzo możliwe, że nie musisz znać liczb latencji; (2) chyba że chcesz zostać zatrudniony przez firmę produkującą komponenty oprogramowania (biblioteki), na sprzedaż lub do użytku wewnętrznego (jak w niektórych największych firmach programistycznych na świecie), (3) jeśli potrzebujesz tych liczb, Twoim zadaniem jest samodzielne wykonanie testów porównawczych w naukowo poprawny sposób, w przeciwnym razie nie powinieneś pracować nad komponentami oprogramowania.

Nikt nie twierdził, że te liczby są dokładne dla dowolnego sprzętu.

Są jednak znacznie bardziej dokładne niż domysły. Na tym niestety wiele osób opiera swój kod.

Nie są idealnie dokładne i tak naprawdę nie są przeznaczone.

Są jednak (szczególnie w przypadku mniejszych liczb) trochę lepsze niż rząd wielkości. Inną kwestią jest to, że może pomóc zrozumieć, które rzeczy są blisko siebie, że ludzie czasami błędnie interpretują, że znajdują się znacznie dalej niż są w rzeczywistości. Dla jednego oczywistego przykładu, sporo osób zakłada, że ​​nieprzewidywalność gałęzi jest często bardzo ważna. To może być wielka sprawa, jeśli jest powtarzany wiele, ale nie jest to koniecznie warte poświęcenia ogromnej ilości gdziekolwiek indziej tylko , aby uzyskać lepsze przewidywania rozgałęzień (na przykład, jeśli odczytać z pamięci głównej, a nawet L2 cache w celu poprawy przewidywania rozgałęzień, to prawdopodobnie strata netto).

Jednocześnie tak, rzędy wielkości mogą być najbardziej użytecznymi częściami. Na przykład dostęp do danych z pamięci głównej zajmuje około 100 razy dłużej niż z rejestru. Tak, na jednej maszynie może być około 97 razy dłużej, a na innej może być bliżej 127 razy dłużej. Jednak prawie na pewno będzie bliżej 100, niż 10 lub 1000.

Osobiście uważam, że większość z nich jest podobna do wysp, powiedzmy na Oceanie Spokojnym. Prędkości dysków twardych (na przykład) mogą być wyspami hawajskimi. Prędkości SSD to wyspy filipińskie. To pokazuje mapę w wystarczająco małej skali, aby każdy z nich wyglądał jak pojedynczy punkt. Jeśli będziemy powiększać, które wyraźnie nie jest prawda - ale odległość pomiędzy dwoma łańcuchami jest wiele razy większa niż odległości pomiędzy wyspami w każdym łańcuchu.

Oczywiście liczby nie mogą być dokładne dla każdej maszyny. I chyba nigdy nie mieli. Wykazują jednak różnice w rzędzie wielkości między kilkoma rodzajami operacji.

Więcej przydatnych linków i danych można znaleźć w komentarzach do połączonych danych.