SPECjalne rozczarowanie!
Uwielbiałem dotychczas benchmark SPECviewperf, bo chociaż jego bezpośrednie wyniki są dość trudne do prezentacji, to jednak pozwalają szybko odróżnić udaną stację roboczą od imitacji sprzętu tej klasy. Ale tym razem... Popatrzmy na wyniki testów.
Szok na samym początku! Im więcej rdzeni, tym wolniej, a różnice są w dodatku spore... Taki rezultat jest całkowicie sprzeczny z wcześniejszymi testami, wykonanymi z programem 3ds Max. Na wyjaśnienie rozbieżności trzeba jednak chwilę poczekać.
Podobnie jak w przypadku 3ds Max, równiez i CATIA osiąga najlepsze wyniki w jednordzeniowym systemie, zaś zwiększenie liczby rdzeni z dwóch do czterech daje znikomy efekt.
Także EnSight najlepiej czuje się w środowisku jednoprocesorowym. I w jego przypadku cztery rdzenie są gorsze niż jeden.
Podobne poglądy prezentuje Lightscape, a także Maya.
Równie przerażająco, jak w przypadku 3ds Max, prezentuja się wyniki SolidWorks.
Czy naprawdę im więcej rdzeni, tym gorzej? Wygląda na to, że w SPECviewperf rzeczywiście tak jest...
Wyjaśnienie zagadki
Na szczęście benchmarki SPEC, w odróżnieniu od wielu innych popularnych testów, są dobrze udokumentowane. Nie było więc trudno dowiedzieć się szczegółów działania SPECviewperf. Wbrew temu, czego można byłoby się spodziewać, nie zawiera on silników graficznych aplikacji, występujących w tytułach poszczególnych testów – jest jedynie generatorem sekwencji instrukcji OpenGL, charakterystycznych dla działania tych programów. Sam program, w rozpowszechnianej darmowo skompilowanej wersji, jest w dodatku całkowicie jednowątkowy. A skutki? Popatrzmy na to, jak wykorzystuje rdzenie obliczeniowe program 3ds Max 8.
Wszystkie cztery jądra wykorzystane są maksymalnie, podobnie byłoby, gdyby się ich znalazło w systemie więcej. Porównajmy to z wykorzystaniem zasobów przez test 3dsmax-04 z benchmarku SPECviewperf. Niby w jakimś stopniu wykorzystywane są wszystkie cztery jądra, ale tylko „niby” – przyjrzyjmy się dokładniej dwóm ostatnim okienkom Menedżera zadań. Okazuje się, że łącznie naprawdę obciążone jest jedno.
Nie trzeba się długo wpatrywać, by zauważyć, że obciążenia stanowią (oczywiście w przybliżeniu), wzajemne dopełnienie. System przerzuca po prostu zadania pomiędzy jądrami, a o równoległości nie ma w ogóle mowy - maksymalna odpowiada co najwyżej wydajności jednego jądra, zaś przy wielu będzie mniejsza!
Za obsługę OpenGL odpowiadają w Windows GL API oraz sterowniki karty graficznej. No i wszystko jasne – ani jedno, ani drugie nie tylko nie jest w swojej obecnej postaci przystosowane do pracy w środowisku wieloprocesorowym, lecz wręcz przeciwnie – wieloprocesorowa platforma może odbijać się niekorzystnie na ich wydajności. W jaki sposób liczba jąder obliczeniowych mogłaby się odbić negatywnie na wydajności jednowątkowej aplikacji i graficznych API? To pytanie należy skierować do czarodziejów z Redmond, którym w jakiś sposób udało się uzyskać taki rezultat, nam pozostają fakty. A pokazane wyżej fakty mówią, wręcz krzyczą, że nieprzystosowany do wielojądrowego środowiska program może w nim stracić wiele na szybkości działania, jak to ma miejsce właśnie w przypadku obsługi OpenGL.