Wynik testu nowego Atoma w AnTuTu został sfałszowany

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