Wiele moich własnych prac dotyczy ulepszania skalowania algorytmów, a jednym z preferowanych sposobów wykazania równoległego skalowania i / lub wydajności równoległej jest wykreślenie wydajności algorytmu / kodu na podstawie liczby rdzeni, np.
gdzie oś reprezentuje liczbę rdzeni, a oś pewną miarę, np. pracę wykonaną na jednostkę czasu. Różne krzywe pokazują równoległe wydajności wynoszące odpowiednio 20%, 40%, 60%, 80% i 100% przy 64 rdzeniach.y
Niestety, w wielu publikacjach wyniki te są wykreślane za pomocą skalowania dziennika , np. Wyniki w tym lub w tym dokumencie. Problem z tymi wykresami dziennika jest taki, że niezwykle trudno jest ocenić rzeczywiste równoległe skalowanie / wydajność, np
Który jest taki sam wykres jak powyżej, ale ze skalowaniem log-log. Zauważ, że teraz nie ma dużej różnicy między wynikami dla wydajności równoległej 60%, 80% lub 100%. Tutaj napisałem o tym trochę więcej .
Oto moje pytanie: jakie jest uzasadnienie pokazywania wyników w skalowaniu dzienników? Regularnie używam skalowania liniowego, aby pokazywać własne wyniki, i regularnie jestem wbijany przez sędziów, którzy twierdzą, że moje własne równoległe wyniki skalowania / wydajności nie wyglądają tak dobrze, jak (log-log) wyniki innych, ale przez całe moje życie nie rozumiem, dlaczego powinienem zmieniać style fabuły.
Georg Hager napisał o tym w Fooling the Mas - Stunt 3: Skala dziennika jest twoim przyjacielem .
Chociaż prawdą jest, że wykresy logarytmiczne silnego skalowania nie są zbyt wymagające w wysokiej klasie, pozwalają one na pokazanie skalowania na wiele innych rzędów wielkości. Aby zobaczyć, dlaczego jest to przydatne, weź pod uwagę problem 3D z regularnym udoskonalaniem. W skali liniowej można rozsądnie wykazać wydajność dla około dwóch rzędów wielkości, np. 1024 rdzeni, 8192 rdzeni i 65536 rdzeni. Czytelnik nie jest w stanie stwierdzić z wykresu, czy prowadziłeś coś mniejszego, i realistycznie, fabuła w większości porównuje tylko dwa największe przebiegi.
Załóżmy teraz, że możemy zmieścić w pamięci 1 milion komórek siatki na rdzeń, co oznacza, że po silnym skalowaniu dwa razy 8-krotnie możemy nadal mieć 16k komórek na rdzeń. Jest to wciąż spory rozmiar subdomeny i możemy oczekiwać, że wiele algorytmów będzie tam działać wydajnie. Omówiliśmy spektrum wizualne wykresu (od 1024 do 65536 rdzeni), ale nie weszliśmy nawet w reżim, w którym silne skalowanie staje się trudne.
Załóżmy zamiast tego, że zaczęliśmy od 16 rdzeni, również z 1 milionem komórek siatki na rdzeń. Teraz, jeśli skalujemy do 65536 rdzeni, będziemy mieli tylko 244 komórki na rdzeń, co będzie znacznie bardziej wymagające. Oś logarytmiczna jest jedynym sposobem wyraźnego przedstawienia widma od 16 rdzeni do 65536 rdzeni. Oczywiście nadal możesz używać osi liniowej i podpisu, że „punkty danych dla 16, 128 i 1024 rdzeni pokrywają się na rysunku”, ale teraz używasz słów zamiast samej figury do wyświetlenia.
Skala log-logu pozwala również skalowaniu „odzyskać” atrybuty maszyny, takie jak przejście poza pojedynczy węzeł lub stelaż. Od Ciebie zależy, czy jest to pożądane, czy nie.
źródło
Zgadzam się ze wszystkim, co Jed miał do powiedzenia w swojej odpowiedzi, ale chciałem dodać następujące. Stałem się fanem sposobu, w jaki Martin Berzins i jego koledzy pokazują skalowanie dla swojego środowiska Uintah. Wykreślają słabe i silne skalowanie kodu na osiach log-log (wykorzystując czas działania na krok metody). Myślę, że pokazuje to, jak dobrze skaluje się kod (chociaż odchylenie od idealnego skalowania jest trochę trudne do ustalenia). Patrz na przykład strony 7 i 8, rysunki 7 i 8 tego * artykułu. Podają także tabelę z liczbami odpowiadającymi każdej skali.
Zaletą tego jest to, że po podaniu liczb recenzent nie może wiele powiedzieć (a przynajmniej niewiele, czego nie można obalić).
*JOT. Luitjens, M. Berzins. „Poprawa wydajności Uintah: wielkoskalowe środowisko obliczeniowe adaptacyjnej siatki”, w toku 24. sympozjum międzynarodowego przetwarzania równoległego i rozproszonego IEEE (IPDPS10), Atlanta, GA, str. 1--10. 2010. DOI: 10.1109 / IPDPS.2010.5470437
źródło