Piękny przykład benchmarku tak nagiętego, by operacje dyskowe wydawały się szybsze niż operacje na pamięci. http://arxiv.org/pdf/1503.02678v1.pdf
Co gorsza, na podstawie takich pięknych papierów (toaletowych) ludzie w gazetkach piszą artykuły, które potem (śmierdzący potem) managosi używają jako podstawkę do podejmowania decyzji http://www.itworld.com/article/2901453/no-its-not-always-quicker-to-do-thing...
Przynajmniej dali kod źródłowy w pracy...
Ale generalnie rzecz biorąc, środowiska naukowe robią teraz takie same wały jak biznesy. Trudno się dziwić, że mamy przez to ruchy antyszczepionkowe. Ale cóż, zachciało się tworzyć środowisko oparte o twardą konkurencję...
Dnia 25 mar 2015 o godz. 19:19 Robert Sebastian Gerus ar@bash.org.pl napisał(a):
Piękny przykład benchmarku tak nagiętego, by operacje dyskowe wydawały się szybsze niż operacje na pamięci. http://arxiv.org/pdf/1503.02678v1.pdf
Erm, nie, autorzy są całkiem uczciwi. Kluczowe:
Although the resulting code, shown in Appendix 1 in Java and Appendix 2 in Python are developed specifically for this paper, the inspiration for them has come from examples of real-life, production code. [..] We start by adding 1 character (byte) at a time to the content, so in the in-memory case, the string containing the file will be concatenated 1,000,000 times."
Trochę kodu pisanego przez naukowców widziałem i spokojnie jestem w stanie w to uwierzyć.
---- Wł. Śr, 25 mar 2015 21:50:56 +0100 Edward Tomasz Napierałatrasz@FreeBSD.org napisał(a) ----
Dnia 25 mar 2015 o godz. 19:19 Robert Sebastian Gerus ar@bash.org.pl napisał(a):
Piękny przykład benchmarku tak nagiętego, by operacje dyskowe wydawały się szybsze niż operacje na pamięci. http://arxiv.org/pdf/1503.02678v1.pdf
Erm, nie, autorzy są całkiem uczciwi. Kluczowe:
Although the resulting code, shown in Appendix 1 in Java and Appendix 2 in Python are developed specifically for this paper, the inspiration for them has come from examples of real-life, production code. [..] We start by adding 1 character (byte) at a time to the content, so in the in-memory case, the string containing the file will be concatenated 1,000,000 times."Trochę kodu pisanego przez naukowców widziałem i spokojnie jestem w stanie w to uwierzyć.
Zgadzam się z traszem. To, co oni stwierdzili jest prawdą, na tle powolnej implementacji łączenia ciągów w javie i pythonie, napisany w C system plików jest demonem prędkości ;). Nothing to see here, move along.
I tak trochę w temacie, do poczytania: http://www.brendangregg.com/ActiveBenchmarking/bonnie++.html
On Thu, Mar 26, 2015 at 9:42 AM, Robert Sebastian Gerus ar@bash.org.pl wrote:
I tak trochę w temacie, do poczytania: http://www.brendangregg.com/ActiveBenchmarking/bonnie++.html
Tak, mikrobenchmarki ssą.
Natomiast reprodukowanie prawdziwych workloadów to sztuka sama w sobie.
Mamy tam, na przykład, benchmarki oparte na bazach danych, na symulacji mocno obciążonego serwera e-mail, na symulacji przeglądarki WWW itp. Tego typu benchmarki mniej mówią o detalach, ale jeśli chodzi o rzeczywistą wydajność są lepszymi wskazaniami dla danego konkretnego zastosowania.
Jedna rzecz, która często nie jest symulowana, to wydajność "na zimno", tzn. dostęp do lub modyfikacja rzadko używanych danych - i inne najgorsze przypadki, które są bardzo istotne w mierzeniu latencji i odczuć użytkownika.
Polecam na przykład taki jeden blog o "sprzęcie": http://mechanical-sympathy.blogspot.com/ No i taki malutki wykład o tym, co rzeczywiście się liczy dla użytkownika: https://www.youtube.com/watch?v=9MKY4KypBzg
-
Edward Tomasz Napierała -
enki -
Radoslaw Szkodzinski -
Robert Sebastian Gerus -
TeMPOraL