Intel Atom na smartfonach: sztuczki z kompilatorem pozwoliły na manipulowanie wynikami benchmarku

Strona głównaIntel Atom na smartfonach: sztuczki z kompilatorem pozwoliły na manipulowanie wynikami benchmarku
15.07.2013 11:14
Intel Atom na smartfonach: sztuczki z kompilatorem pozwoliły na manipulowanie wynikami benchmarku

Kilka tygodni temu w Sieci opublikowano zaskakujące wyniki testów wydajności smartfonów, wśród którychznalazł się model z procesorem Intel Atom Clover Trail (Lenovo K900).Z testów wynikało, że dwurdzeniowy CPU Intela pozostawił konkurencjębazującą na procesorach ARM (nawet tych czterordzeniowych) bez szans,i to nie tylko pod względem wydajności, ale i zużycia energii. Czyżbywięc na tym polu projektowana od początku z myślą oenergooszczędności architektura ARM przegrała w końcu z x86,architekturą projektowaną z myślą przede wszystkim o wydajności?Niekoniecznie, gdyż w grę wchodzą tu pewne software'owe…manipulacje.Exophase, jeden z czytelników serwisu AnandTech przyjrzał siębliżej benchmarkowi, który posłużył do uzyskania tych bolesnych dlaARM-ów wyników. To AnTuTu,rekompilacja kodu z lat 90, przygotowanego przez nieistniejący jużmagazyn Byte. Benchmark wygląda na dość solidny i kompleksowy,pozwala mierzyć wydajność pamięci, procesora, grafiki 2D i 3D, czyoperacji I/O na pamięci masowej i z bazami danych. Pod tym względemnie można mu niczego zarzucić. Problem tkwi gdzie indziej – wkompilatorach wykorzystywanych do zbudowania uruchamialnej wersji.[img=armwrestling-opener]Okazuje się, że wykorzystana w testach wersja benchmarkaskompilowana została dla procesorów Intel Atom za pomocą kompilatoraICC, podczas gdy wersję dla ARM skompilowano za pomocą GCC.Naszym starszym Czytelnikom mogą się już w tej sytuacji włączyćalarmowe lampki – pamiętają, jak podczas dochodzenia w sprawiewytoczonego przez AMD pozwu antymonopolowego przeciwko Intelowiokazało się, że kompilator Intela włącza optymalizacje tylko dlaprocesorów „Genuine Intel”, nie sprawdzając faktycznychmożliwości docelowego układu. Dla procesorów VIA, jedynych w którychmożna było zmienić ciąg CPUID, wystarczyła ta zmiana, by zwiększyćwydajność kodu kompilowanego przez ICC o nawet 30%. Choć tuoczywiście taka sytuacja wystąpić nie mogła (ICC generuje kod tylkona x86), to alarm jest poniekąd uzasadniony: skompilowana przez ICCwersja benchmarka otrzymała automatycznąwektoryzację kodu wynikowego, podczas gdy w kompilowanej zapomocą GCC wersji na ARM nie włączono rozszerzeńNEON (rozszerzeń ARM-a dla architektury SIMD). To prawda, GCC samo tych rozszerzeń nie włącza, ale wydaje się, żeskoro wersję na Atomy zbudowano za pomocą intelowskiego kompilatora,to wypadałoby wersję na ARM-y skompilować za pomocą kompilatora odpoczątku projektowanego z myślą o ARM, np. Keila,by z rozszerzeń NEON korzystać – w końcu są dostępne napraktycznie wszystkich nowoczesnych układach ARM, zarówno Cortex A9jak i Cortex A15. Problemy z kodem wygenerowanym przez ICC na tym sięnie skończyły – według Exophase kompilator celowo psuje wielekonstrukcji wykorzystanych w benchmarku. Na przykład jedna z pętli,która powinna zostać wykonana 32 razy, zostaje wykonana tylko raz, anastępnie zgłasza, że zadanie zostało ukończone.Zarówno w serwisach takich jak Slashdot, jak i na forach serwisówpoświęconych sprzętowi komputerowemu trwają dyskusje na temat tegoincydentu, który być może jest zwykłym zbiegiem okoliczności, ale byćmoże też jest częścią zamierzonych działań, mających na celuwykazanie wartości architektury x86 w urządzeniach przenośnych.Całkiem niedawno przecież Intel udostępnił kompletny zestawnarzędzi deweloperskich na Androida/x86, a tu nagle wypływająraporty uznanych analityków, wykazujące o ile Atom sprawuje sięlepiej od ARM-ów? Wątpliwości trudno będzie wyciszyć, szczególnie, żeudało się porównać, o ile zmieniły się wyniki poszczegónych testów.Między wykorzystaną w badaniach ABI Research wersją 3.3 AnTuTu ipoprzednią wersją 2.9.3, różnice są dramatyczne, i trudno je zrzucićna zwykły przypadek – dla testu wydajności RAM wynik Atoma (naMotoroli RAZRi) wzrósł o 292%, podczas gdy wynik ARM-owego procesora(w Samsungu Galaxy S4) wzrósł jedynie o 53%. Sprawa wygląda jeszczebardziej podejrzanie, gdy porówna się wyniki innych benchmarków,takich jak Quadrant, Linpack i Geekbench – tam przewaga układówARM w niektórych testach była nawet trzykrotna.[img=antutu-charge][join][img=arm-cpu1]A teraz ciekawostka – AnTuTu wydało nową wersję 3.3.2swojego benchmarka. Wyniki dla urządzeń z procesorami Intel Atom sąjuż znacznie skromniejsze, często nawet o 20-50%. Wniosek jestoczywisty – zamierzone lub nie błędy metodyczne mogą uczynićkażdy pomiar pozbawionym merytorycznego znaczenia. Szkoda tylko, żebłędy metodyczne nie pozbawiają jednocześnie takiego badaniaznaczenia marketingowego.

Oceń jakość naszego artykułuTwoja opinia pozwala nam tworzyć lepsze treści.
Udostępnij:
Wybrane dla Ciebie
Komentarze (14)