Twoje PC  
Zarejestruj się na Twoje PC
TwojePC.pl | PC | Komputery, nowe technologie, recenzje, testy
M E N U
  0
 » Nowości
0
 » Archiwum
0
 » Recenzje / Testy
0
 » Board
0
 » Rejestracja
0
0
 
Szukaj @ TwojePC
 

w Newsach i na Boardzie
 
TwojePC.pl © 2001 - 2024
Wtorek 16 lipca 2013 
    

Wynik testu nowego Atoma w AnTuTu został sfałszowany


Autor: Wedelek | 10:22
(17)
Jakiś czas temu informowaliśmy Was, że nowy Atom Intela z rodziny Bay Trail miażdży najmocniejszego Snapdragona 800 w benchmarku AnTuTu. Dziś wiemy już, że tamten wynik nie był oznaką rewolucji wśród mobilnych procesorów, tylko wynikiem oszustwa. Na jego trop po raz pierwszy trafił jeden z użytkowników serwisu AnandTech, który podzielił się na forum swoimi spostrzeżeniami, skłaniając ekspertów do bliższej analizy uzyskanych wyników. Szybko okazało się, że podczas testu wykorzystano znaną od lat sztuczkę z kompilatorem Intel C++ Compiler.

Kod testu na którym sprawdzono wydajność nowego Atoma został skompilowany z wykorzystaniem narzędzia Intela, które mocno faworyzuje procesory tego producenta i potrafi wydobyć z nich pełen potencjał. Z kolei wersja AnTuTu na której przetestowano procesory konkurencji została skompilowana z użyciem GCC. Co więcej w jednym z testów procesor Intela wykonał zestaw instrukcji tylko raz, zamiast 32 razy, co musiały zrobić konkurencyjne procesory na bazie ARM.

 
    
K O M E N T A R Z E
    

  1. @news (autor: Promilus | data: 16/07/13 | godz.: 20:58)
    No cóż, ICC nie wspiera ARM a w tym się kompiluje sporo appsów x86 więc akurat częściowo jest to "real world scenario"

  2. @up (autor: Wyrzym | data: 16/07/13 | godz.: 21:08)
    no masz racje, nic nie oszukali, pokazali jak to jest naprawde. Procki intela sa takie pro ze licza tylko raz a dobrze, a nie jak jakies inne pfff ;]

  3. zadne falszerstwo (autor: RusH | data: 16/07/13 | godz.: 21:45)
    tylko kompromitacja ARM (ARM Holdings plc) bo nie wydala ani zlamanego dolara na optymalizacje GCC a teraz jecza ze ojejku Intel zly bo inwestuje w narzedzia dla developerow.


    >To jednak nie wystarczyło, więc osoba wykonująca test tak
    >zmodyfikowała kod benchmarku, by w jednym z testów
    >procesor Intela wykonał zestaw instrukcji tylko raz,
    >zamiast 32 razy

    chyba zle przetlumaczyles, kompilator wykryl ze kod benchmarku wykonuje jakas operacje bez sensu i ja pominal = zwykla optymalizacja


  4. @up (autor: Wedelek | data: 16/07/13 | godz.: 21:54)
    źródło z którego po raz pierwszy skorzystałem pisało o modyfikacjach, ale faktycznie chodzi o automatyczne pominięcie kodu. Inna sprawa, że kompilator Intela faworyzuje procki Intela. Głośna była sprawa gdy po zmianie CPUID wyniki wydajności procesorów AMD w aplikacjach rosły.

  5. @Wedelek (autor: Promilus | data: 16/07/13 | godz.: 22:51)
    No dziwne, żeby faworyzował zupełnie inną architekturę niż ich własna ;) W końcu po to go odpicowują na wszelkie możliwe sposoby żeby właśnie wyciągnąć max z ich procków :)
    Z drugiej strony porównanie w samym GCC też nie byłoby zupełnie poprawne ze względu na różnice "zaawansowania" implementacji konkretnych rodzin procesorów. Przykład z samego podwórka x86 - w jednym programie kompilacja GCC z -march=bdver1 względem -march=barcelona daje pozytywne rezultaty, w innym negatywne. Teraz jak to porównać żeby to miało ręce i nogi? Nie da się! Trzeba mieć zoptymalizowany pod konkretną arch. program i takie wyniki porównywać. Wtedy wychodzi co w rzeczywistości po uwzględnieniu optymalizacji kompilatora, wydajności procka sensu stricte i wydajności podsystemu pamięci jest szybsze!


  6. Promilus (autor: Markizy | data: 16/07/13 | godz.: 23:42)
    zgoda, tylko żeby porównywać wydajność CPU należało by albo używać zoptymalizowane lub nie kompilatory dla wszystkich, a nie wybiórczo. Fakt faktem że nikt by tutaj nie jest bez winy, ale dobrze że wychodzi coś takiego teraz niż za xx miesięcy.

    @RusH
    a superpi nie liczy czasem parę razy tą samą liczbę i jest cacy, a jak ktoś tworzy benchmark który też coś liczy bez sensu to jest bee ?


  7. markizy nie do konca (autor: RusH | data: 17/07/13 | godz.: 04:19)
    kompilator nie wytnie twojego kodu od tak sobie
    kompilator zamieni glupie "loop for"y na wersje wektorowa i zamieni 32 skoki petli na jedna instrukcja MMX/SSE w jednym cyklu zegara

    ARM jeczy bo oni
    - nie maja silnej jednostki wektorowej w standardzie
    - nawet jak cpu ma FPU na pokladzie to GCC NIE MA dla niego dobrego wsparcia bo ... ARM nie pokwapil sie nikomu za to zaplacic.


    Mozna by protestowac gdyby SoC ARM dzialaly w arch x86 i ktos uzyl ICC do skompilowania benchmar... wait a minute, tak wlasnie wyglada obecnie sytuacja na rynku x86 :D taki np PCMark jest kompilowany ICC :P


  8. Ale wy sobie (autor: mbe | data: 17/07/13 | godz.: 06:16)
    Fajnie tlumaczycie kolejne klamstwo intela...

  9. jakie znowu klamstwo? (autor: RusH | data: 17/07/13 | godz.: 08:48)
    kod skompilowany pod ICC dziala, i do tego dziala super szybko i jest automagicznie zoptymalizowany

  10. @09 (autor: bmiluch | data: 17/07/13 | godz.: 11:09)
    większość aplikacji (o których mówimy) nie ma oddzielnego kodu pod ICC ale za to ma native code na ARMa i będzie wykonywana na Atomie z użyciem emulatora, co wiąże się ze spadkiem wydajności o 40% (średnio 60% wydajności w stosunku do kodu skompilowanego pod x86)

    są aplikacje które nie mają native code, ale dla nich benchmarki nie mają takiego znaczenia


  11. @Promilus (autor: bmiluch | data: 17/07/13 | godz.: 11:14)
    "Głośna była sprawa gdy po zmianie CPUID wyniki wydajności procesorów AMD w aplikacjach rosły."

    to zdanie oznacza, że zmiana CPUID wykonywanie programu, przy czym zmiana CPUID w żaden sposób nie zmienia architektury procesora AMD

    oznacza to, że kod wynikowy kompilatora Intela nie wykonuje programu tak szybko jak się da, tylko sztucznie (celowo lub nie) wyłącza optymalizacje dla porcesorów AMD


  12. @07 (autor: pio2 | data: 17/07/13 | godz.: 11:23)
    W porównaniu do ARM gdzie muszą byc użyte różne kompilatory nie ma żadnego oszutwa, po prostu kod dla x86 (a szczególnie tego Atoma) da się tak zoptymalizować by działał szybciej. To może być własnie dowód na siłę samej architektury.

    Natomiast na poletku x86 kompilator Intela nie robił (albo ciagle robi) tylko optymalizacji (co jest naturalne) ale celowo spowalniał układy konkurencji co jest jawnym oszustwem. Szczególnie jak okazywało się że procek AMD potrafił bez problemu wykonac kod optymalizowany pod Intela, czyli nie było podstawy do rozrózniania sposobu optymalizacji.


  13. @12 (autor: anemus | data: 17/07/13 | godz.: 18:02)
    Czy ja wiem czy na poletku x86 to oszustwo - procek amd raz pozwolił wykonać kod, raz nie, a kompilator optymalizuje pod intela i nikt nie karze płacić intelowi za sprawdzanie zgodności innych procków - po prostu założono, że nie działa i tyle.

  14. ps. (autor: anemus | data: 17/07/13 | godz.: 18:04)
    testującym zarzucono, że nie użyli optmalizacji neon w gcc dla arm ale w kontekście innych benchmarków nie wydaje sie to prawdziwe.

  15. 12 ma racje (autor: RusH | data: 17/07/13 | godz.: 18:24)
    anemus nie bardzo

    AMD nigdy nie wykonywal zoptymalizowanego kodu ICC bo AMD nie pozwalaja na zmiane cpuid, odkrycie bylo na procku VIA (lol) i VIA nie mial problemu z zoptymalizowanym kodem i dzialal zawsze
    nie slyszalem aby ktos przeoral kod w hexrays czy innym disasemblerze wycinajac sprawdzanie cpuid i probowal odpalac na amd

    gdyby antutu robil przekret z ICC vs GCC przy porownaniu ATOMa z telefonem na AMD to mozna by sie czepiac, ale mowa jest o ARM, o firmie ktora nie daje zlamanego grosza na optymalizacje GCC


  16. @bmiluch (autor: Promilus | data: 18/07/13 | godz.: 10:26)
    Chcesz się powołyywać na tamtą aferę? Proszę bardzo. Dokładnie chodziło nie tyle o to, że program skompilowany na ICC wykrywał AMD i specjalnie włączał jakieś opóźniacze. Chodziło dokładnie o to, że zamiast sprawdzać flagi procesora odnośnie obsługiwanych rozszerzeń (SSE, SSE2) skompilowany pod ICC program wykrywał możliwości rozszerzeń wyłącznie za pomocą cpuid - a dokładniej nr rodziny - czyt. jak wykrył P4 lub nowszy to włączał SSE2, jak nie wykrył P4 lub nowszego to włączał x87. I to właśnie spotkało VIA i AMD. Po krytyce z tym związanej intel dodał sprawdzanie flag procesora zamiast wyłącznie rodziny własnych produktów.
    Tutaj z tego co wyczytałem kod skompilowany na ICC robi dokładnie to co ma robić tyle, że nie tak jak ma robić. Tj. ustawia i zeruje bity w słowach ok, ale dyskusyjne jest jak to robi i dlaczego - tj. autor bencha twierdzi, że dla innych długości zmiennych taka optymalizacja intela albo by nie zaskoczyła w ogóle, albo działałaby niepoprawnie (czyli wnioskuje, że optymalizacji dokonano specjalnie na potrzeby aktualnej wersji benchmarka - oszustwo).


  17. nie drapcie sie dziewczyny (autor: pandy | data: 22/07/13 | godz.: 21:57)
    sprawa z ICC znana od wielu lat i zalatwiana patchem
    http://www.agner.org/...mize/blog/read.php?i=49#49
    https://github.com/jimenezrick/patch-AuthenticAMD

    http://www.amdzone.com/...c.php?f=532&t=138574


    
D O D A J   K O M E N T A R Z
    

Aby dodawać komentarze, należy się wpierw zarejestrować, ewentualnie jeśli posiadasz już swoje konto, należy się zalogować.