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.