Android 5.0 i 64-bitowe procesory, czyli Nexus 9 i kolejna runda kompilowania

22
Mieszko Krzykowski
Android 5.0 i 64-bitowe procesory, czyli Nexus 9 i kolejna runda kompilowania

Wszystko wskazuje na to, że tegoroczny rynek smartfonów i tabletów będzie stał pod znakiem 64-bitowych procesorów ARMv8. Układy tego typu same w sobie nie są nowością, bo iPhone 5S ma już ponad rok, a od jakiegoś czasu w sprzedaży są androidofony ze Snapdragonami i Exynosami nowej generacji, jednak dopiero niedawno pojawił się duży brakujący element tej bitowej układanki, zwany Androidem 5.0, i to dopiero on umożliwia szersze wykorzystanie tego wszystkiego w praktyce. Dlatego gdy do naszej redakcji w końcu zawitał Nexus 9, czyli pierwszy gadżet z 64-bitowym procesorem i Androidem 5.0, zacząłem kombinować jak go podwędzić na kilka chwil.

Chęć wzięcia Nexusa 9 pod lupę miałem już w czasie przygotowania tego tekstu, w którym nawet zaznaczałem, że mam w planach sprawdzenie co da się wycisnąć z połączenia Androida 5.0 i 64-bitowego procesora ARM. Niestety, czasu na zabawę miałem mniej, niż bym chciał, przez co nie starczyło mi go na sprawdzenie wszystkiego w zadowalającym mnie stopniu i na rozwikłanie wszystkich zagadek napotkanych po drodze. Mimo wszystko, z tych kilku godzin spędzonych na zmienianiu flag kompilatora, udało mi się wycisnąć garść ciekawych wniosków na temat ARMv8, Androida 5.0 i przy okazji chyba się dowiedziałem, czemu Nvidia w następnej Tegrze planuje montować Corteksy-A57, zamiast zaprojektowanych przez siebie rdzeni Denver ;)

tegra

Korzyść z ARMv8

Korzyści wynikające z wykorzystywania pełni potencjału układów ARM nowej generacji można podzielić na dwie kategorie. Pierwsza z nich zawiera wszelkiego rodzaju wzrost wydajności wynikający z przejścia na kod 64-bitowy: procesor wykorzystuje wtedy więcej rejestrów, niektóre obliczenia może wykonywać szybciej i tak dalej. Żeby jednak wszystko działało jak powinno, programiści muszą przystosować swoje oprogramowanie do chipów tego typu, bo bez tego będzie ono działało tak samo szybko (ewentualnie nieznacznie szybciej), jak na procesorze 32-bitowym. Druga kategoria, to wzrosty wydajności wynikające z zaprzęgnięcia do pracy nowego zestawu instrukcji ARMv8, znacznie poprawiającego efektywność niektórych operacji (czasem nawet o rząd wielkości, o czym można się przekonać trochę niżej).

Najpierw chciałem sprawdzić ile może dać przejście na oprogramowanie 64-bitowe i żeby to zrobić spróbowałem przekompilować narzędzia używane przeze mnie od pewnego czasu do testowania smartfonowych procesorów, czyli x264, 7-Zipa i LAME. Ten pierwszy zwrócił w miarę przewidywalne wyniki, tego drugiego (niestety) jeszcze nie udało mi się okiełznać, a ten trzeci... do niego wrócę za chwilę.

x264 to bardzo wdzięczny kawałek kodu, bo jest on od dawna optymalizowany pod wszystko co się da, więc miałem pewność, że jeśli go właściwie skompiluję pod ARMv8, to wydarzy się coś ciekawego. I faktycznie tak było. Mniej więcej.

x264_kl

x264_1p

x264_2p

W dwóch testach widoczna jest kilkuprocentowa poprawa szybkości działania, czyli w nich wszystko poszło zgodnie z planem i podejrzewam, że dobrze reprezentują one średni zysk z przejścia na ARMv8 i 64 bity w większości aplikacji mających coś do czynienia z NDK. Jak wyjaśnić 3. wykres? Okazało się, że problemu trzeba było szukać w przegrzewaniu się Tegry K1. Teoretycznie procesor ten jest taktowany zegarem 2,3 GHz, jednak w czasie drugiego przejścia kodowania utrzymują się one na poziome około 1,5 GHz. Co ciekawe, w czasie kompresowania wideo za pomocą 64-bitowej wersji tego narzędzia, po kilku minutach zegary rdzeni były o około 100-200 MHz niższe niż w czasie używania wersji 32-bitowej. Gdyby się nad tym zastanowić trochę dłużej, to nawet ma to sens, bo 64-bitowe aplikacje wykorzystują większą część procesora, przez co wydziela on więcej ciepła przy tym samym taktowaniu, więc gdy załącza się limiter ciepła i poboru prądu, musi on mocniej zbić taktowanie i w tym tablecie robi to na tyle drastycznie, że niweluje wszelkie ewentualne korzyści wydajnościowe. Ach te współczesne chipy smartfonowo-tabletowe. Jak ich nie kochać zimą? ;)

Znacznie większych wzrostów wydajności należy jednak szukać wszędzie tam, gdzie do gry wchodzi szyfrowanie danych, które w procesorach ARMv8 dostało zestaw własnych instrukcji mających poprawić efektywność tego procesu. Czyli na przykład tutaj:

gb3_3

androsr

androsw

androrw

Wykresy te na pierwszy rzut oka mogą nie mieć zbyt wiele wspólnego z tematem tego wpisu, jednak to tylko pozory. Patrząc na pierwszy z nich należy pamiętać, że wśród testów cząstkowych Geekbencha 3 sprawdzających wydajność stałoprzecinkową procesora znajduje się kilka testów badającą szybkość szyfrowania danych, które (gdy mogą) korzystają z nowych instrukcji ARMv8. Efekt? Nexus 9 jest w tych testach cząstkowych nawet 20 razy (tak, to nie pomyłka) szybszy od urządzeń opartych na Snapdragonach 80x, co w bardzo dużym stopniu wpływa na wynik końcowy.

Co wspólnego z tym tematem ma test systemowego nośnika danych? W artykule o Nexusie 6 wspominałem, że ma on fabrycznie włączone szyfrowanie danych, niekorzystnie wpływającą na szybkość zapisu i odczytu plików, oraz ogólną responsywność systemu. Nexus 9 również ją ma, jednak dzięki dobrodziejstwom ARMv8, na sprzęcie nie robi ono żadnego wrażenia. Jeśli więc zależy Ci na bezpieczeństwie danych, to przesiadka na nowe procesory i Androida 5.0 da Ci wymierne i łatwo zauważalne korzyści, wykraczające poza dodatkowe gigabajty pamięci RAM.

No i ten nieszczęsny LAME...

Jak zauważyliście, do tej pory uciekałem od wątku testu LAME. Dlaczego? Dlatego:

lame

Ten wynik nie ma sensu albo ja nie mogę go znaleźć. Biblioteki LAME „dokompilowuję” do ffmpeg i to właśnie z poziomu ffmpeg odpalam ten test. Sprawdzałem skrypty kompilacyjne, czy przypadkiem gdzieś czegoś nie dopisałem albo nie usunąłem, jednak różnią się one jedynie rodziną procesorów, pod które ma być zoptymalizowany kod (ARMv7 + NEON vs ARMv8) i docelową wersją Androida (4.4 vs 5.0). Gdzieś w tych dwóch linijkach dzieje się niezrozumiała dla mnie magia, bo nie słyszałem o tym, aby w nowym zestawie instrukcji (lub w nowej wersji Androida) było coś, co mogłoby mieć aż taki wpływ na szybkość tworzenia plików MP3. Jeśli ktoś ma jakieś wyjaśnienie tego zjawiska, to z chęcią posłucham. 

Nvidia Denver w ARM-owym łańcuchu pokarmowym

Nvidia już na początku 2011 roku zapowiedziała, że pracuje nad własną architekturą 64-bitowych procesorów ARM kompatybilnych z zestawem instrukcji ARMv8 (wtedy też po raz pierwszy wymieniono nazwę kodową Denver). Mam wrażenie, że Nvidia decydując się na coś takiego liczyła, że uda się wyprzedzić konkurencję w wyścigu o pierwszeństwo na rynku 64-bitowych procesorów ARM, bo Qualcomm zdawał się mieć w planach tłuc kolejne Kraity do końca świata i o dwa dni dłużej (aż w końcu zaczęłyby one topić obudowy telefonów), a rdzenie Cortex-A57 były raczej traktowane jako pieśń odległej przyszłości i coś, co najpierw trafi do mikroserwerów. Czyli wystarczyło się sprężyć, trafić w odpowiedni moment i pracownicy zielonego producenta kart graficznych dowiedzieliby się jak się czuje Gaben po dużej wyprzedaży na Steam'ie.

„Niestety”, w międzyczasie znikąd pojawił się Apple A7 i wszystko się zmieniło: Nvidia już nie miała szansy na pierwszeństwo, a pracownicy Samsunga i Qualcomma musieli wziąć się do ostrej roboty. Co prawda to tylko moje spekulacje, jednak myślę, że nie są one zbyt dalekie od prawdy, bo tworzenie własnej architektury jest trudne, kosztowne i ryzykowne, więc robi się to tylko wtedy, gdy ma się plan jak ten cały proces potem przekuć na konkretne zyski. Do czego zmierzam? Do wydajności Tegry K1 64 (czyli tej z dwoma rdzeniami Denver) w Nexusie 9 i tego jak ona wygląda na tle innych układów ARMv7 i nowości ARMv8. A po uwzględnieniu wcześniejszej mojej wzmianki o tym, co się dzieje z zegarami tego procesora w czasie dłuższego obciążenia, nie wygląda to jakoś bardzo optymistycznie.

Garść porównań:

lame

7zip

x264_kl

x264_1p

x264_2p

gb3_5

gb3_6

gb3_4

gb3_8

3dmphys_u

Jednowątkowy test LAME pokazuje, że jeden rdzeń Denver ma wydajność porównywalną z jednym rdzeniem Cortex-A57. Test kompresji 7-Zip prawie nie skaluje się powyżej dwóch rdzeni, więc wychodzi nam na to, że dwa rdzenie Denver taktowane zegarem 2,3 GHz są trochę szybsze od dwóch rdzeni Cortex-A57 taktowanych zegarem 1,9 GHz. W x264 Tegra K1 64 radzi sobie słabo, co w dużej mierze jest wynikiem wzmożonej pracy spowalniacza cieplnego, jednak nawet bez niego nie byłoby jakoś rewelacyjnie. Czas na syntetyki. Geekbench? Po odrzuceniu mocno faworyzujących Nexusa 9 testów stałoprzecinkowych, a także wzięciu poprawki na to, że procesor ten ma bardzo dobry kontroler pamięci, przez co wyniki testu przepustowości także zawyżają uśredniony rezultat końcowy, zostajemy z testem wydajności zmiennoprzecinkowej i wychodzi nam na to, że przewaga Denvera nad Corteksem-A57 to głównie zasługa szybszego taktowania. 3DMark? Ten benchmark skaluje się z liczbą rdzeni niemal liniowo, więc po podwojeniu punktów zdobytych przez Nexusa 9 wygląda to nieźle. A potem się patrzy na rezultat iPhone'a 6 Plus, zegar jego procesora i bierze pod uwagę fakt, że ten phablet nigdy nie spowalnia swojej jednostki centralnej i... Sami sobie dokończcie ;)

Wielu z Was zapewne się teraz denerwuje na mnie, bo przecież „wystarczyłoby zrobić 4-rdzeniową Tegrę K1, która mogłaby konkurować z najnowszymi 4-rdzeniowymi Corteksami, więc z tą wydajnością wcale nie jest źle, prawda”? Nie do końca, bo tak jak pisałem, Tegra K1 już ma problem z utrzymaniem zegarów, więc wersja 4-rdzeniowa robiłaby pewnie z obudowami telefonów to samo, co krew Obcego z podłogą Nostromo. Teoretyzowanie? Może tak, ale dla mnie bardzo wymowne jest to, że Tegra X1 będzie miała 4 rdzenie Cortex-A57, a po Tegrę K1 64 nie ustawiają się kolejki. Nie chcę w ten sposób powiedzieć, że Tegra K1 jest słaba, bo wydajności jej nie brakuje i jak na pierwszą architekturę Nvidi-i nie wygląda źle, jednak wydaje mi się, że inżynierom tej firmy nie udało się osiągnąć zakładanego efektu. Tym bardziej, że jest to procesor bardzo chimeryczny: jego wydajność bardzo mocno zależy od sytuacji i wykonywanego kodu (co świetnie wyjaśniono w recenzji Nexusa 9 na AnandTechu), a na dodatek rezerwuje on sobie dodatkowe 128 MB pamięci RAM, którą wykorzystuje jako pamięć podręczną niezbędną do poprawienia swojej efektywności.

nvidia-tegra-x1-chip

Zupełnie odrębnym tematem jest satysfakcjonująca wydajność układu graficznego, w pełni kompatybilnego ze zwykłym Open GL-em, a nie tylko z jego namiastką z dopiskiem ES (choć Google wycięło z Nexusa 9 sterownik Open GL...), ale ja tu dziś nie o tym ;)

Krótkie podsumowanie

Na koniec szybkie podsumowanie i garść (wstępnych) wniosków:

  • przejście na 64-bitowy kod i podstawowa optymalizacja pod ARMv8 może dać kilka-kilkanaście procent dodatkowej wydajności
  • nowe instrukcje związane z szyfrowaniem działają i dają wymierne korzyści wszędzie tam, gdzie jest potrzebne bezpieczeństwo danych
  • rdzeń oparty na architekturze Denver ma wydajność zegar w zegar porównywalną z rdzeniem Cortex-A57, choć wygląda na to, że osiąga to kosztem większego zużycia energii, chimeryczności i odbierając użytkownikowi 128 MB pamięci RAM

Dziękuję za uwagę :)

Oceny (26)
Średnia ocena
Twoja ocena
SunTzu (2015.02.08, 17:39)
Ocena: 8
Weź się Ty za tablety... bo procedura testowania tabletów odbiega od telefonów i jest gorsza :P Pomijam tablety z windowsem gdzie już totalna olewka

6/5 niestety błąd suwaka nie pozwala mi dać wyższej oceny.
Jeśli ktoś ma jakieś wyjaśnienie tego zjawiska, to z chęcią posłucham.

Co do Lame to zdaję się podobny numer mieli na phoronix w innych sytuacjach. Ten test potrafi zaskoczyć :) Tylko tu to już faktycznie magia, a jak wygląda plik, który uległ przetworzeniu?
Tegra K1 już ma problem z utrzymaniem zegarów, więc wersja 4-rdzeniowa robiłaby pewnie z obudowami telefonów to samo, co krew Obcego z podłogą Nostromo.

Nie koniecznie. Kernel może przerzucać wątek pomiędzy rdzeniami, by te utrzymywały niższą temperaturę pracy. Natomiast jeśli aplikacja będzie 4 wątkowa to proszę o gaśnicę.
Edytowane przez autora (2015.02.08, 17:53)
BlackBishop (2015.02.08, 17:52)
Ocena: 6
ani słowa o użytym kompilatorze, użytych flagach kompilatora i linkera, czy było zastosowane jakieś profilowanie itp.
miekrzy (2015.02.08, 18:14)
Ocena: 2
BlackBishop (2015.02.08, 17:52)
ani słowa o użytym kompilatorze, użytych flagach kompilatora i linkera, czy było zastosowane jakieś profilowanie itp.

GCC 4.9 + NDKr10d. To w tym momencie jedyna w miarę działająca kombinacja, która bez większych problemów mieli większe programy pod Androida z optymalizacjami pod AARCH64 i API level 21.
Z flag używałem w sumie tylko -march i -mfpu, bez włączania optymalizacji pod konkretne architektury (GCC nie ma optymalizacji pod Denvera, tylko pod Corteksy, ale na razie i tak nie mam jak sprawdzić ich działania).
Ale chyba właśnie znalazłem prawdopodobną przyczynę wyników w LAME. BRB :D

EDIT
E, pudło :(
Edytowane przez autora (2015.02.08, 18:39)
Tabalan (2015.02.08, 18:30)
Ocena: 4
Tegry nigdy sobie nie radziły z temperaturami, a biorąc pod uwagę, że Tegra X1 może jeść nawet 10W, to podejrzewam, że następca Nvidia Shield Tablet w wersji referencyjnej będzie miał pokaźną turbinę. Trzeba czekać na niereferenty :)
BlackBishop (2015.02.08, 19:52)
Ocena: 1
plus za dobre chęci :)

bez optymalizacji GCC generuje kod na 'pałę' mówię teraz o x86 ale w przypadku ARM będzie podobnie - różnice mogą być spore, naprawdę spore - samo -O2 czy -O3 to tylko połowa drogi bo jest sporo opcji, które mogą dać dodatkowe % jeśli będą użyte poprawnie - ale to wymaga kilku czy kilkunastu buildów z różnymi opcjami i sprawdzenie, które dają zysk a które stratę

druga sprawa, że sporo aplikacji jest napisanych tak, że nie da się uzyskać np. wektoryzacji (w przypadku ARM instrukcji NEON, x86 SSE) bo kod jest napisany ohydnie (wiem bo próbowałem poprawić kilka toolów do linuxa, których często używam a są napisane stylem sprzed 20 lat i bez przepisania całości g...o można zdziłać :( )
Edytowane przez autora (2015.02.08, 19:53)
SNC (2015.02.08, 20:07)
Ocena: 3
Trzeba w rozwazaniach nad arch. brac pod uwage fakt ze tegra k1 jest w 28nm a uklad w noych iphonach 20nm.
miekrzy (2015.02.08, 20:33)
Ocena: 3
BlackBishop (2015.02.08, 19:52)
...

Tylko w tym przypadku i w tych zastosowaniach nie było za bardzo sensu robić to inaczej. Na przykład GCC pod ARMv7 w ogóle nie ma -mtune dla Kraitów, a pod AARCH64 nie ma -mtune dla Denvera. Z tego powodu wyszło mi na to, że już lepiej dać wszystkim prockom tak samo niezoptymalizowany kod, jeśli mam wycisnąć z tego jakieś sensowne wnioski niezależne od kompilatora. Gdy dostanę jakiś sprzęt z Androidem 5.0 i Corteksami-A57 to sprawdzę kilka dodatkowych opcji, ale to bardziej z ciekawości.
skoti48 (2015.02.08, 20:41)
Ocena: 5
miekrzy
No i ten nieszczęsny LAME...

Prawdopodobnie częściowo to, że kompilatory zarówno GCC jak i LLVM mają napisane wsparcie dla ARMv8 od razu ze wspiarciem dla 128bitowe jednostki SIMD (chociaż z tego co wiem nie automatycznie, więc musiałbyś coś włączyć, lub lame wykorzystuje instrukcje simd bezpośrednio w taki sposób, że DCO rozrzuca je na 2x większe simd)... a cząściowo to, że GCC i LLVM przy targecie AArch64 mają standardowo włączone dodatkowe optymalizacje, które są standardowo wyłączone w ARMv7 (bo nie wszystkie ARMv7 to potrafią, albo jeśli potrafią to może być to ze szkodą dla wydajności).

Cortex A57 od ARM dalej ma 2x NEON 64bit (czyli łącznie SIMD mają 128 bit), ale Apple Cyclone i Nvidia Denver potrafią przetwarzać 2x więcej liczb zmiennoprzecinkowych (te mają 2x NEON 128bit... czyli 256bit - taka konkurencja dla AVX). To robi olbrzymią różnicę, a kompilatory tworzące kod jako target dla ARMv7 tego nie wspierają.

Denver w teorii potrafi liczyć 2.3x wydajniejszy w liczbach całkowitych niż A57 (7x instrukcji vs 3 instrukcje) i równe 2x wydajniejszy niż A57 w obliczeniach zmiennoprzecinkowych (SIMD liczy na raz 16 operacji zmiennoprzecinkowych zamiast 8). To że ma jest aż taka różnica ALU spowodowało, że muszą to być rdzenie in-order... jednak dzięki Dynamic Code Optimization czyli softwareowemu rozwiązaniu potrafi osiągać prawie to co sprzętowe ooo.

miekrzy (2015.02.08, 18:14)

GCC 4.9 + NDKr10d.

Najlepsze wsparcie dla ARMv8 ma obecnie LLVM (clang) i jest to dodatkowo dobry sposób na porównanie z rdzeniami Apple (głównie dlatego, bo LLVM jest tworem Apple i wykorzystuje się go w produktach Apple).

miekrzy (2015.02.08, 18:14)

Z flag używałem w sumie tylko -march i -mfpu, bez włączania optymalizacji pod konkretne architektury

Czyli bez rozwijania pętli, funckcji, bez ipo/lto czy profilowania kodu (pgo) itp? W takim razie generujesz bardzo kiepskiej jakości kod, który nie ma żadnego odzwierciedlenia w programach wypuszcznych na rynek.

miekrzy
Test kompresji 7-Zip prawie nie skaluje się powyżej dwóch rdzeni, więc wychodzi nam na to, że dwa rdzenie Denver taktowane zegarem 2,3 GHz są trochę szybsze od dwóch rdzeni Cortex-A57 taktowanych zegarem 1,9 GHz.

7-Zip pod mobilkami skaluje się prawie liniowo... Jako przykład podam tu Tegra K1 32 (4x 2.3 GHz A15) vs Exynos 5 Dual (2x 1.7 GHz A15) i wydajność Tegry K1 32 2.3x wyższy
http://www.phoronix.com/scan.php?page=arti...eview&num=3
Więc wychodzi na to, że dwa rdzenie w teście dobrze skalującym się na wątki i tak wyprzedza 4x cortex A57 (co ma potwierdzenie w teoretycznych możliwościach układu).

miekrzy
Jednowątkowy test LAME pokazuje, że jeden rdzeń Denver ma wydajność porównywalną z jednym rdzeniem Cortex-A57

Test Lame w 32bitach pokazuje, że pół rdzenia Denver (pierwsze 64bit z 128bit jednostek wektorowych) ma wydajność całego rdzenia A57 (który ma SIMDy o połowe mniejsze, ale są wykorzystane w całości). Podobnie wygląda sprawa z x264 (tylko połowa jednostek wektorowych jest wykorzystywana).

miekrzy
Geekbench? Po odrzuceniu mocno faworyzujących Nexusa 9 testów stałoprzecinkowych, a także wzięciu poprawki na to, że procesor ten ma bardzo dobry kontroler pamięci, przez co wyniki testu przepustowości także zawyżają uśredniony rezultat końcowy, zostajemy z testem wydajności zmiennoprzecinkowej i wychodzi nam na to, że przewaga Denvera nad Corteksem-A57 to głównie zasługa szybszego taktowania.

Taa... odrzućmy testy stałoprzecinkowe, bo to że Denver potrafi wykonać 2.3x więcej instrukcji na cykl go faworyzuje, weźmy poprawkę na to, że ma lepszy kontroler pamięci bo to też go faworyzuje i weźmy pod uwagę tylko testy wykorzystujące połowę możliwości jednostek wektorowych względem wykorzystania całości możliwości jednostek wektorowych A57 i wtedy dopiero się z twoimi założeniami zgodzi ;p. Denver na rdzeń ma możliwości w obliczeniach zmiennoprzecinkowych na zegar identyczne z Apple Cyclone - niestety Geekbench3 wspiera 2x większe SIMD na mobilkach jedynie pod iOS, a pod Androidem nie.
Edytowane przez autora (2015.02.08, 21:31)
michu_roztocz (2015.02.08, 22:06)
Ocena: 2
Zarówno w recenzji jak i we wpisie brakowało mi choćby wzmianki o tym, co porusza połowa artykułu na AnandTech - że Tegra K1-64 to bardzo specyficzny procesor, obecnie chyba jedyny wysokowydajny ARM wykonujący kod w kolejności (bez OoE)

Idąc dalej - jest to bardzo 'szeroki' układ w tym sensie, że jest w stanie przetworzyć wiele instrukcji w cyklu zegara, ale muszą one zostać wcześniej 'spreparowane' przez warstwę programową, która analizuje wykonywany kod i gdy ten się powtarza, zostaje przetworzony na wewnętrzne instrukcje, dające się bardzo szybko wykonywać. Tutaj jest o tym wzmianka, ale gdybym nie był po lekturze wspomnianego artykułu, nawet nie wiedziałbym o co chodzi z tą zarezerwowaną pamięcią.

A co do poboru prądu - podobno płytka deweloperska z Tegrą K1-64 potrafi wessać z gniazdka 33W. Nic dziwnego, że układ ma problemy z zachowaniem wydajności.
skoti48 (2015.02.08, 22:56)
Ocena: 4
michu_roztocz (2015.02.08, 22:06)
obecnie chyba jedyny wysokowydajny ARM wykonujący kod w kolejności (bez OoE)

Nie do końca można tak o nim powiedzieć, bo wykonuje kod poza kolejnością (Out-of-order), jednak robi to w mocno specyficzny sposób. Nie jest to klasyczny In-Order jak w wypadku Intel Atom Z2k czy ARM Cortex A53, które faktycznie wykonują kod w kolejności takiej jak dostają, ale też nie jest to klasyczne podejście do Out-of-order czyli sprzętowe rozwiązanie (które potrafi być większe niż cały procesor). Nvidia podeszła do sprawy w dość nowatorski sposób , który wcześcniej był stosowany chyba tylko przez Transmetę (też teoretycznie in-order VLIW, ale z Code Morphing Software który tłumaczył instrukcje i optymalizował wykonanie, aby przekolejkować je i wykonywać poza kolejnością)... i w sumie nic dziwnego, bo Nvidia zatrudnia byłych pracowników Transmeta.

To rozwiązanie to trochę taki kompromis, aby zjeść ciastko i mieć ciastko (czyli optymalizowac wykonanie tak, aby działało Out-of-order, ale bez energochłonnej sprzętowej implementacji, a w zamian za nią dać 2x więcej jednostek wektorowych, 2x więcej ALU stałoprzecinkowych). Z tego co widać po testach ten sposób implementacji OOO poza sprzętem wychodzi zaskakująco dobrze i daje sobie radę z uporządkowaniem tak instrukcji, aby obciążyć nowe ALU.
michu_roztocz (2015.02.08, 23:48)
Ocena: 1
skoti48 (2015.02.08, 22:56)
Z tego co widać po testach ten sposób implementacji OOO poza sprzętem wychodzi zaskakująco dobrze i daje sobie radę z uporządkowaniem tak instrukcji, aby obciążyć nowe ALU.

Testy wykonywane na Anandtechu i tutaj przez Mieszka zdają się mówić co innego - układ w zależności od zastosowań zapewnia bardzo nierówną wydajność. Bardzo fajnie widać to w testach Sunspider i Mozilla Kraken - ten pierwszy wykonuje się bardzo szybko i Tegra K1 nie radzi sobie najlepiej, podczas gdy ten drugi - być może dzięki temu, że przez dłuższy czas wykonania daje się zoptymalizować przez Dynamic Code Optimizer - wykazuje bardzo wysoką wydajność.
miekrzy (2015.02.08, 23:51)
Ocena: 1
skoti48 (2015.02.08, 20:41)
Prawdopodobnie częściowo to, że kompilatory zarówno GCC jak i LLVM mają napisane wsparcie dla ARMv8 od razu ze wspiarciem dla 128bitowe jednostki SIMD

Bawiłem się różnymi przełącznikami i one niewiele zmieniają. Może jest to kwestia nowego SIMD, a może nie, ale jakoś nie widzę tego jak by to miało się przekładać na aż 9-10 krotny wzrost wydajności.

skoti48 (2015.02.08, 20:41)
Denver w teorii...

Słowo klucz: w teorii. A jak mu coś nie wyjdzie albo mu kod nie leży, to robi 2 instrukcje na cykl. Nie bawmy się w teoretyczną maksymalną wydajność, bo wszyscy wiemy ile ona ma wspólnego z realnymi wynikami :)

skoti48 (2015.02.08, 20:41)
Najlepsze wsparcie dla ARMv8 ma obecnie LLVM

Nie napisałem, że to najszybsze i najefektywniejsze połączenie, a takie, które najbardziej działa. Wiem, że na przykład LLVM/Clang ma -tune dla Kraitów, czego nie ma w GCC i ogólnie pewnie dałby troch wyższą wydajność, jednak co z tego, skoro miałem problemy ze zmuszeniem go do skompilowania tego, co miałem do skompilowania. Może teraz by to ruszyło, ale wtedy, gdy się za to brałem pierwszy raz, to po prostu nie chciało zadziałać (po części z powodu dziwnych błędów w ffmpeg, które teraz chyba są naprawione).

skoti48 (2015.02.08, 20:41)
Czyli bez rozwijania pętli, funckcji, bez ipo/lto czy profilowania kodu (pgo) itp? W takim razie generujesz bardzo kiepskiej jakości kod, który nie ma żadnego odzwierciedlenia w programach wypuszcznych na rynek.

Bez przesady. Podstawowe rzeczy są i celowałem w kompatybilność od CortexA7/A15 w górę, tylko nie robię -mtune pod konkretne architektury, bo GCC zna tylko Corteksy.

skoti48 (2015.02.08, 20:41)
7-Zip pod mobilkami skaluje się prawie liniowo...

To zależy od wybranego algorytmu kompresji i rozmiaru słownika. Akurat ten test powyżej dwóch rdzeni się nie skaluje (i często jest limitowany szybkością eMMC, ale to już inna sprawa). Poza tym zupełnie inne wyniki wychodzą z wbudowanego benchmarka (to coś co podaje MIPS), a zupełnie co innego z testów kompresji pliku.

skoti48 (2015.02.08, 20:41)
Test Lame w 32bitach pokazuje, że pół rdzenia Denver (pierwsze 64bit z 128bit jednostek wektorowych) ma wydajność całego rdzenia A57 (który ma SIMDy o połowe mniejsze, ale są wykorzystane w całości). Podobnie wygląda sprawa z x264 (tylko połowa jednostek wektorowych jest wykorzystywana).

No i że niby czyj to problem? :P Chyba najbardziej Qualcomma, bo oni 128-bitowe SIMD-y mają już od czasów Scorpiona ;)

skoti48 (2015.02.08, 20:41)
Taa... odrzućmy testy (...)

Czytaj proszę uważnie i nie naciągaj. Test stałoprzecinkowy odrzucam nie dlatego, że nie lubię Nvidii, a dlatego, że jego wyniki są mocno zawyżone przez kilka testów szyfrowania i jakąś wartość będą mialy dopiero, gdy pojawi się sprzęt z Cortex-A57 i Androidem 5.0. Wzmianka o testach przepustowości też jest po to, że ten test ma wpływ na wynik końcowy Geekbencha, a tak naprawdę niewiele mówi o wydajności w jakimś konkretnym zadaniu. Z tego powodu na razie porównywanie Denvera w Geekbenchu z innymi procesorami ma sens tylko w przypadku testu zmiennoprzecinkowego. Chyba nie trudno zrozumieć o co mi chodzi :)

Reasumując, jeśli Denver dostanie odpowiednio przygotowany i pasujący mu kod, to potrafi być szybki. A jak go nie dostanie, to nie jest szybki. I wygląda na to, że nawet Nvidia to rozumie :)
Edytowane przez autora (2015.02.08, 23:55)
skoti48 (2015.02.09, 01:21)
Ocena: 2
michu_roztocz (2015.02.08, 23:48)
Testy wykonywane na Anandtechu i tutaj przez Mieszka zdają się mówić co innego - układ w zależności od zastosowań zapewnia bardzo nierówną wydajność. Bardzo fajnie widać to w testach Sunspider i Mozilla Kraken - ten pierwszy wykonuje się bardzo szybko i Tegra K1 nie radzi sobie najlepiej, podczas gdy ten drugi - być może dzięki temu, że przez dłuższy czas wykonania daje się zoptymalizować przez Dynamic Code Optimizer - wykazuje bardzo wysoką wydajność.

Powołujesz się na SunSpider i Mozilla Kraken? No dobra to teraz porównajmy wyniki wielowątkowego V8 (silnik JS w Chrome):

Jak widzisz 4x rdzenie A57 (SGN4) zostały praktycznie dogonione przez 2x rdzenie Denver (własnie ze względu na to, że DCO obciążył dodatkowe ALU, przez co znikła różnica 2x większej ilości rdzeni).
W wypadku testów Kraken czy Octane (specjalny test, aby testować wydajność V8 w chrome) wypada 4x A57 wypadają już zupełnie źle względem 2x denver





miekrzy (2015.02.08, 23:51)
Bawiłem się różnymi przełącznikami i one niewiele zmieniają. Może jest to kwestia nowego SIMD, a może nie, ale jakoś nie widzę tego jak by to miało się przekładać na aż 9-10 krotny wzrost wydajności.

Jak pisałem - nie tylko tego, ale też tego, że kompilatory standardowo włączone mają dla danej innego tagetu inne optymalizacje. 9-10 krotność to nic - kompilator mógł zoptymalizować nawet tak, że na 32bit miałbyć 211, a na 64bit czas byłby 0 i nie było by w tym nic dziwnego. Dlatego jeśli chcesz sensownie optymalizować to powinieneś zrobić optymalny dla platformy build (optymalny dla 32bit i dla 64bit - nie koniecznie dla konkretnego procka - możesz robić pod Cortexami). Dlatego powinieneś użyć profilowania i zoptymalizować kod tak jak to robią programiści w realnym świecie, a nie build bez optymalizacji, który nie świadczy o niczym.

miekrzy (2015.02.08, 23:51)
Słowo klucz: w teorii. A jak mu coś nie wyjdzie albo mu kod nie leży, to robi 2 instrukcje na cykl. Nie bawmy się w teoretyczną maksymalną wydajność, bo wszyscy wiemy ile ona ma wspólnego z realnymi wynikami :)

Wiem, że to słowo klucz i dlatego je zawarłem. W praktyce jest gorzej... jednak również gorzej jest z praktyką w wypadku Cortexów. Gdy kod Denverowi nie podpasuje to robi dwie instrukcje (to jest minimalna ilość)... gdy kod nie podpasuje Cortex A57 to może robić nawet tylko jedną instrukcję (przykładowo samo mnożenie intów). Tak to już jest i to nie zależne od tego czy jest softowo superskalarność rozwiązana, czy algorytm siedzi zaszyty w tranzystorach.

miekrzy (2015.02.08, 23:51)
Wiem, że na przykład LLVM/Clang ma -tune dla Kraitów, czego nie ma w GCC i ogólnie pewnie dałby troch wyższą wydajność

mtune nie ma żadnego znaczenia - mogło równie dobrze pogorszyć wydajność... na kraitach. Mtune to po prostu włączenie części optymalizacji, które standardowo są wyłączone... jednak w to zależy od kodu, czy ta optymalizacja pomoże szybciej wykonać czy wręcz przeciwnie sprawi, że będzie się wykonywać 10x dłużej.

miekrzy (2015.02.08, 23:51)
jednak co z tego, skoro miałem problemy ze zmuszeniem go do skompilowania tego, co miałem do skompilowania.

W takim razie napisałeś błędnie - nie jest to 'jedyna w miarę działająca kombinacja', a 'jedyna bezproblemowa kombinacja w wybranych przez ciebie programach', bo wszystkie te programy da się ofc skompilować dla ARM pod Clang, ale wybierając inny zestaw programów mógłbyś skompilować w clang bez problemu, a w GCC mieć problemy (to samo tyczy się innych kompilatorów - to co skompiluje się w microsoftowym kompilatorze niekoniecznie zadziała w GCC, Clang czy ICC (itp)).

miekrzy (2015.02.08, 23:51)

Bez przesady. Podstawowe rzeczy są i celowałem w kompatybilność od CortexA7/A15 w górę, tylko nie robię -mtune pod konkretne architektury, bo GCC zna tylko Corteksy.

Nie - praktycznie wszystkie flagi optymalizacyjne są kompatybilne nawet z ARMv5 (i tam też powinieneś te optymalizacje dostosowane do kodu stosować). Więc nie celowałeś w kompatybilność. Mtune to włączone 'standardowe' optymalizacje kodu dla danego procka... i częśto mogą nawet zaszkodzić (bo to bardziej zależy od rodzaju kodu, a nie procesora - zazwyczaj nawet dobre dla kodu flagi dla SandyBridge będą dawały kopa i ARMv5 (bo to czy opłaca się rozwijać pętle/funkcje do inline czy nie nie zalezy od procka, bo wszędzie skoki są ksztowne i wszędzie się prawdopodobnie będzie opłacać, a od kodu (jeśli dużo kodu wykonuje to może się opłacać skoczyć zamiast zwiększać rozmaiar kodu))). Dlatego właśnie powinieneś skompilować z profilowaniem i stworzyć kod optymalny, a nie tak kiepski kod, jakiego nigdy w praktyce nie uświadczysz.

[quote name='miekrzy' date='2015.02.08, 23:51' post='11120']No i że niby czyj to problem? :P Chyba najbardziej Qualcomma, bo oni 128-bitowe SIMD-y mają już od czasów Scorpiona ;)
Qualcomm od Scorpiona ma 2x 64bit (tak jak A15 czy Krait). Czyli mają 128bit, ale w sumie. W wypadku Apple i Nvidii mówimy o 2x 128 (czyli 256 bit).

miekrzy (2015.02.08, 23:51)
Czytaj proszę uważnie i nie naciągaj. Test stałoprzecinkowy odrzucam nie dlatego, że nie lubię Nvidii, a dlatego, że jego wyniki są mocno zawyżone przez kilka testów szyfrowania i jakąś wartość będą mialy dopiero, gdy pojawi się sprzęt z Cortex-A57 i Androidem 5.0.

Niby dlaczego? Szyfrowanie Geekbench robi w pełni softwareowo, niezależnie od wersji systemu i nie wykorzystuje żadnych sprzętowych jednostek szyfrujących - robią tak, a nie wykorzystują z jądra systemu, aby można było wyniki porównywać z iOS czy z Windowsem. No, ale skoro już chcesz rezygnować z części testów, to przynajmniej podaj te, które są interesujące przykładowo dla graczy - jak wydajność języka Lua (wykorzystywanego przez sporo gier).

miekrzy (2015.02.08, 23:51)
I wygląda na to, że nawet Nvidia to rozumie :)

Po czym wnosisz? Chyba nie po tym, że Nvidia wprowadziła coś na wzór Intelowego Intel Tick-Tock już w K1? Nvidia ma plan wydawania SoC w sposób taki
- Słabe CPU (Cortex A15) + nowe GPU Kepler (Tegra K1 32)
- Mocny Denver + GPU poprzednie (Tegra K1 64)
- Słabe CPU (Cortex) + Maxwell (Maxwell + Denver to zbyt skomplikowany układ na nowy proces technologiczny),
- mocniejszy Denver + Maxwell (już zapowiedziany - ma się pojawić po Tegra X1, gdy nowy proces technologiczny będzie bardziej dopracowany).

Ot taki jeden krok na raz - raz GPU raz CPU.
Edytowane przez autora (2015.02.09, 01:42)
miekrzy (2015.02.09, 09:01)
Ocena: 1
skoti48 (2015.02.09, 01:21)
Jak pisałem - nie tylko tego, ale też tego, że kompilatory standardowo włączone mają dla danej innego tagetu inne optymalizacje. 9-10 krotność to nic - kompilator mógł zoptymalizować nawet tak, że na 32bit miałbyć 211, a na 64bit czas byłby 0 i nie było by w tym nic dziwnego.

Jakoś x264 mocno korzystające z SIMD i skompilowane z dokładnie tymi samymi optymalizacjami widzi znacznie mniejsze różnice i to dlatego nie wierzę w to, że ten wzrost wynika tylko ze sposobu obciążenia SIMD.

skoti48 (2015.02.09, 01:21)
Wiem, że to słowo klucz i dlatego je zawarłem.

Dlatego zostawmy w spokoju jakieś dziwne określenia typu 2,3x, bo jeszcze ktoś uwierzy, że tak faktycznie jest i będzie problem :)

skoti48 (2015.02.09, 01:21)
W takim razie napisałeś błędnie (...)

Jak zwał tak zwał. Skrót myślowy happens.

skoti48 (2015.02.09, 01:21)
Więc nie celowałeś w kompatybilność.

Oj celowałem, celowałem. Na przykład -mfpu może przyjmować różne wartości niekompatybilne ze wszystkimi procesorami, więc...

skoti48 (2015.02.09, 01:21)
Qualcomm od Scorpiona ma 2x 64bit (tak jak A15 czy Krait). Czyli mają 128bit, ale w sumie. W wypadku Apple i Nvidii mówimy o 2x 128 (czyli 256 bit).

Skąd informacja o tym, że Scorpion ma 2x64, a nie 1x128?

skoti48 (2015.02.09, 01:21)
Niby dlaczego?

Nie chce mi się kolejny raz pisać tego samego :) Porównanie wyniku końcowego i wyników stałoprzecinkowych Geekbencha będzie wtedy, gdy pojawi się pierwszy telefon z Cortex-A57 i Androidem 5.0, bo dopiero wtedy oba procki będą startowały z tej samej pozycji. Dla mnie EOT.

skoti48 (2015.02.09, 01:21)
Chyba nie po tym, że Nvidia wprowadziła coś na wzór Intelowego Intel Tick-Tock już w K1?

Po tym, że Nvidia uważa przejście z 2 x Denver na 4 x A57 za upgrade. Dla mnie to po prostu wygląda tak, że 2 x Denver miało konkurować z 4 x A15, a nie 4 x A57 i miało dać czas Nvidi-i na przygotowanie Parkera, czyli 4 x Denver (albo następca Denvera). Oczywiście to jest moje gdybanie, ale gdyby wszystko poszło zgodnie z planem (czyli i wydajność, i czas wprowadzenia na rynek), to nie byłoby potrzebne tworzenie Eristy, tylko na roadmapie Nvidi-i nadal byłby Parker, który jednak z niej magicznie zniknął. Ale to już tylko kwestia interpretacji zaistniałej sytuacji, więc każdy może sobie patrzeć na to tak jak chce.

Poza tym ( i tutaj pytam serio), której magicznej optymalizacji/flagi kompilatora/czegokolwiek innego tu brakuje, przez co Denver ma nie móc pokazać maksimum swoich możliwości? Tylko nie wyskakuj mi z modyfikowaniem źródeł ffmpeg/x264/Lame :P
Edytowane przez autora (2015.02.09, 09:01)
skoti48 (2015.02.09, 12:15)
Ocena: 1
miekrzy (2015.02.09, 09:01)
Jakoś x264 mocno korzystające z SIMD i skompilowane z dokładnie tymi samymi optymalizacjami widzi znacznie mniejsze różnice i to dlatego nie wierzę w to, że ten wzrost wynika tylko ze sposobu obciążenia SIMD.

x264 to zupełnie inny algorytm i co z tego, że korzysta z SIMD? W wypadku x264 te dodatkowe optymalizacje mogą dla wydajności być negatywne. Widzę, że dalej nie rozumiesz, że jak działają optymalizacje i to jaki wpływ mają na wydajność zależy w minimalnym stopniu zależy od CPU, a praktycznie w całości zależy od tego jaki konkretnie to jest kod (i czy kod pasuje do danej optymalizacji). Po to właśnie wykorzystuje się profilowanie - aby ustalić które optymalizacje są dla danego programu szkodliwe, a które są pozytywne. Ta sama optymalizacja może być dobra dla lame... a być tragiczna dla x264.

miekrzy (2015.02.09, 09:01)

Oj celowałem, celowałem. Na przykład -mfpu może przyjmować różne wartości niekompatybilne ze wszystkimi procesorami, więc...

Ty mówisz o mało znaczących w sumie dla wydajności optymalizacjach pod sprzęt https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
Ja mówię o optymalizacji kodu niezależnie od sprzętu (które potrafią dać wielokrotność tego co flago dla sprzętu (te optymalizacje działają zarówno na MIPS/PPC/x86/ARM...) i sprawiają, że kod jest dobry i można porównywać)
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
Główną przyczyną wzrostu wydajności optymalizacji o których ty mówisz to to, że gdy dasz -march=armv8-a to z optymalizacji o których ja mówię (niezależnych od sprzętu) inne opcje są domyślnie włączone.
Ogólnie tak jak ty testujesz to wychodzi inny kod dla innych arch (inne optymalizacje), a przy okazji tragiczny kod z jakim nie spodkają się procki nigdy w praktyce. Dla przyzwoitości kompilowałbyś przynajmniej z flagą -Ofast (optymalizacjami poprawiającymi jakość większości programów) i włączyć optymalizacje podczas linkowania (-flto), ale żeby dobrze przetestować powinieneś zrobić profilowanie i wypluć z kodu programu najlepszy kod jaki można, aby porównywać podobny kod jaki jest faktycznie używany w realnym świecie.

[quote name='miekrzy' date='2015.02.09, 09:01' post='11122']Skąd informacja o tym, że Scorpion ma 2x64, a nie 1x128?
Z diagramów pipeline qualcomma - obok int alu mają 2x neon (nie jeden duży). Zresztą nawet nie o to chodzi, a o to, że instrukcje NEON od zawsze są max 128 bit (na Cortex do A15 wykonywane w 2ch cyklach), jednak nie potrafią zapełnić 256bit (jak u Apple/Nvidia).

miekrzy (2015.02.09, 09:01)
Nie chce mi się kolejny raz pisać tego samego :) Porównanie wyniku końcowego i wyników stałoprzecinkowych Geekbencha będzie wtedy, gdy pojawi się pierwszy telefon z Cortex-A57 i Androidem 5.0, bo dopiero wtedy oba procki będą startowały z tej samej pozycji. Dla mnie EOT.

Ech i jeszcze raz, bo nie zrozumiałeś. Geekbench nie korzysta w tych testach z jednostek do obliczeń zmiennoprzecinkowych (w końcu to test możliwości stałoprzecinkowych i nie korzysta z neon z rozszerzeniami crypt - ps nawet nie jestem pewien, czy akurat Nvidia te rozszerzenia crypt zaimplementowała, bo nie są obowiązkowe, a mają własny projekt simd), a imlementuje wszystko sam na liczbach całkowitych. Gdy pojawią się telefony z A57 i Androidem 5... to nic się nie zmieni, bo nie ma to nic wspólnego z Androidem 5 czy z ARMv8, a po prostu to, że A57 w intach jest słaby.
Zresztą po co czekać, gdy Geekbench ma już testy Cortex A57 pod 64bit Android 5.0.1
http://browser.primatelabs.com/geekbench3/1639448
I Snapdragon 810 (4x A57 z wyższym taktowaniem niż w SGN4) wypada jeszcze gorzej niż SGN4 pod Androidem 4.x. Nie wiem na co liczyłeś w związku z Androidem 5 w tym teście, ale to raczej było liczenie na marzenia niż opieranie się faktycznie o jakieś przesłanki, że będzie lepiej (bo patrząc realistycznie nie miałeś najmniejszej przesłanki pozwalającej tak sądzić).

miekrzy (2015.02.09, 09:01)
Po tym, że Nvidia uważa przejście z 2 x Denver na 4 x A57 za upgrade. Dla mnie to po prostu wygląda tak, że 2 x Denver miało konkurować z 4 x A15, a nie 4 x A57 i miało dać czas Nvidi-i na przygotowanie Parkera, czyli 4 x Denver (albo następca Denvera).

Nie bardzo - Nvidia uważa, to za utrzymanie wydajności 2x Denver 2.5GHz, aby wejść z Maxwellem, bo z denvera byłby za mały uzysk na początku nowego procesu technologicznego. Bardzo prawdopodobne, że w poprawionym TX1 zamiast 4x A57 wymieni na 2x Denver 3GHz. Nvidia z Tegra X1 zapowiada tylko poprawę GPU, a poprawa CPU ma być po pół roku dopiero z Denverem + Maxwell.

miekrzy (2015.02.09, 09:01)
Oczywiście to jest moje gdybanie, ale gdyby wszystko poszło zgodnie z planem (czyli i wydajność, i czas wprowadzenia na rynek), to nie byłoby potrzebne tworzenie Eristy, tylko na roadmapie Nvidi-i nadal byłby Parker, który jednak z niej magicznie zniknął. Ale to już tylko kwestia interpretacji zaistniałej sytuacji, więc każdy może sobie patrzeć na to tak jak chce.

Parker jest zaplanowany w 16nm, a do tego jeszcze droga daleka, aby opłacało się tam robić skomplikowane układy jak Denver + Maxwell w ramach jednego SoC. A czymś trzeba rynek zapchać - A57 + Maxwell wypełniają po prostu lukę - słaby procek, ale GPU nadgania i konkurencja nie powinna nawet bardzo się zbliżyć do wydajności GPU do wprowadzenia Denver + Maxwell.

miekrzy (2015.02.09, 09:01)
Poza tym ( i tutaj pytam serio), której magicznej optymalizacji/flagi kompilatora/czegokolwiek innego tu brakuje, przez co Denver ma nie móc pokazać maksimum swoich możliwości? Tylko nie wyskakuj mi z modyfikowaniem źródeł ffmpeg/x264/Lame :P

Nie ma konkretnej magicznej flagi (no ok jest -Ofast ;p), i nie chodzi o samego Denvera, a o wszystkie procki (być może nawet po optymalizacji to Denver straci).
Chodzi tu o optymalizacje niezależne od architektury, a pod konkretny kod, dlatego przydałoby się PGO (kompilacja z -fprofile-generate, wiele razy uruchom (za każdym razem inne optymalizacje są włączane i testowany czas działania) i później kompilujesz z -fprofile-use, aby użyć optymalnych flag). Chodzi o to, że testujesz kod zupełnie bezsensowny, który w praktyce się nie zdaża. Przykładowo jeśli testowany program ma małą funkcje pomocniczą czy małą pętlę i ją wykonuje to całą superskalarność trafia szlak (wykonuje skok (do funkcji lub na początek pętli) i niezależnie czy sprzętowy czy softowy out-of-order masz N cyklów w plecy, bo musi wszystkie alu muszą czekać na zapakowanie nowymi instrukcjami (tym więcej im więcej jest jednostek w procku - czyli przykładowo najgorzej będą znosiły to Haswelle, Cyclony czy Denvery, a lepiej Atomy, AMD czy ARM... im większa superskalarność tym gorzej się znosi jej brak ;])). Dlatego właśnie rozwija się pętle (przykładowo -funroll-loops) czy nakazuje się kompilatorowi, nie skakania do funkcji, a przepisanie funkcji w miejsce wywołania (-finline-functions). Jednak nie ma magicznego 'zrób optymalny kod', bo zależy od kodu (funkcja ma bardzo dłuży kod na kilkaset instrukcji i wykonywana jest często, to przepisując za każdym razem w miejscu wykonania kod rozrośnie się i będzie negatywnie dla wydajności względem kilku cyklów w skoku)... dlatego używa się PGO (program wykonuje się X razy i w ten sposób zbiera informacje na temat tego czy dana optymalizacja jest dobra czy zła w wypadku tego konkretnego programu).
miekrzy (2015.02.09, 14:00)
Ocena: 1
skoti48 (2015.02.09, 12:15)
Widzę, że dalej nie rozumiesz, że jak działają optymalizacje

Pozwól, że nie skomentuję, bo z nieznanego mi powodu zakładasz z góry jakieś dziwne rzeczy i nadinterpretujesz rzeczy, które piszę.

skoti48 (2015.02.09, 12:15)
Ty mówisz o mało znaczących w sumie dla wydajności optymalizacjach pod sprzęt

Nie. Cały czas zarzucasz mi, że czegoś nie rozumiem, a sam nawet nie próbujesz zrozumieć co do Ciebie piszę.
Napisałeś, że nie celuję w kompatybilność. Tę flagę pokazałem jako przykład, że jednak to robię, przez co te kompilacje nie uruchomią się na wszystkim. Tylko i aż o to chodziło i nie ekstrapoluj tego w kosmos.

Spokojnie, znam te dokumenty, więc mnie nie zaskoczyłeś nimi.


skoti48 (2015.02.09, 12:15)
Dla przyzwoitości kompilowałbyś przynajmniej z flagą -Ofast (optymalizacjami poprawiającymi jakość większości programów) i włączyć optymalizacje podczas linkowania (-flto)

No patrz, czyli jednak przyzwoity ze mnie człowiek, bo miałem to zrobione :) No dobrze, nie do końca, bo miałem -O3 + -fast-math (czyli prawie to samo), ale zdaję sobie sprawę z tego, że bez -fast-math kompilowanie pod NEON-a często jest średnim pomysłem.

skoti48 (2015.02.09, 12:15)
Z diagramów pipeline qualcomma

Masz gdzieś do nich link?

skoti48 (2015.02.09, 12:15)
Zresztą nawet nie o to chodzi, a o to, że instrukcje NEON od zawsze są max 128 bit (na Cortex do A15 wykonywane w 2ch cyklach), jednak nie potrafią zapełnić 256bit (jak u Apple/Nvidia).

Dobra, inaczej. Skąd przekonanie, że 'pół rdzenia Denver (pierwsze 64bit z 128bit jednostek wektorowych) ma wydajność całego rdzenia A57 (który ma SIMDy o połowe mniejsze, ale są wykorzystane w całości). Podobnie wygląda sprawa z x264 (tylko połowa jednostek wektorowych jest wykorzystywana).' i nie jest to robione w przypadku Denvera inaczej? Czyli skąd wniosek, że w tym przypadku instrukcje są rozbijane na 2 x 64, pomimo tego, że mają do dyspozycji szersze jednostki? Wiem, że optymalizacja pod Denverowy układ i kształt jednostek pozwoliłaby na lepsze ich wykorzystanie, jednak zastanawia mnie skąd takie twierdzenie.

skoti48 (2015.02.09, 12:15)
Ech i jeszcze raz, bo nie zrozumiałeś. Geekbench nie korzysta w tych testach z jednostek do obliczeń zmiennoprzecinkowych (w końcu to test możliwości stałoprzecinkowych i nie korzysta z neon z rozszerzeniami crypt a imlementuje wszystko sam na liczbach całkowitych.

http://support.primatelabs.com/discussions...-arm-a64-vs-a32
Dotyczy to także Androida.


skoti48 (2015.02.09, 12:15)
Geekbench ma już testy Cortex A57 pod 64bit Android 5.0.1

Chociażby po to czekać, że finalny sprzęt na finalnym sofcie może działać inaczej. Nie wiem jak to dokładnie u nich działa i co jaki może mieć tam wpływ na wyniki, więc wolę poczekać wnioskami, a nie zakładać z góry, że coś się stanie albo się nie stanie.

skoti48 (2015.02.09, 12:15)
Nie bardzo - Nvidia uważa(...)

Jak mówiłem - kwestia interpretacji, a interpretacja mocno zależy od tego jakie testy uważa się za 'prawidłowe' i nie mam zamiaru o tym dyskutować :)

skoti48 (2015.02.09, 12:15)
przydałoby się PGO (kompilacja z -fprofile-generate, wiele razy uruchom (za każdym razem inne optymalizacje są włączane i testowany czas działania) i później kompilujesz z -fprofile-use,

Obiecuję, że się tym pobawię i jeśli znajdę jakieś ogromne różnice w wydajności to dam znać :P

BTW, przez jakiś czas będę poza internetami, więc na razie dyskusja jest chyba zakończona z mojej strony.
skoti48 (2015.02.09, 19:00)
Ocena: -1
miekrzy (2015.02.09, 14:00)

Spokojnie, znam te dokumenty, więc mnie nie zaskoczyłeś nimi.
...
No patrz, czyli jednak przyzwoity ze mnie człowiek, bo miałem to zrobione :) No dobrze, nie do końca, bo miałem -O3 + -fast-math (czyli prawie to samo), ale zdaję sobie sprawę z tego, że bez -fast-math kompilowanie pod NEON-a często jest średnim pomysłem.

O czyli jednak - uspokoiłeś mnie trochę, bo nie wiesz jak źle wyglądały twoje słowa:
miekrzy
Z flag używałem w sumie tylko -march i -mfpu

Czyli już kod nie tak tragiczny testujesz jak się zdawał po twoich słowach. Cieszyłbym się bardziej gdybyś używał jeszcze LTO i PGO.

miekrzy (2015.02.09, 14:00)

Masz gdzieś do nich link?

Niestety nie. Slajdy były z okolic 2007, ale ich nie mam, a google nie wypluwa przy łatwych pytaniach. Możez jednak poszukać, że VeNum (wektorowe jednostki w Skorpionach i Kraitach) to sprzętowo 2x 64bit VFPv3 sprzęgnięte w pipeline, aby instrukcje NEON wykonywać w jednym cyklu (tak jak w A15 czy A57).

miekrzy (2015.02.09, 14:00)
Czyli skąd wniosek, że w tym przypadku instrukcje są rozbijane na 2 x 64, pomimo tego, że mają do dyspozycji szersze jednostki?

Nie są rozbijane (dlaczego tak przyjąłeś?). Instrukcje NEON 128bit są wykonywane w całości. Jednak Nvidia nie ma 128bit, a 256bit. Standardowe instrukcje NEON w wypadku Apple czy Nvidii wyglądają jakbyś chciał wykorzystać całe AVX za pomocą instrukcji SSE (czytaj - działa tylko połowa AVX... pierwsze 128 bit).

miekrzy (2015.02.09, 14:00)
Chociażby po to czekać, że finalny sprzęt na finalnym sofcie może działać inaczej.

Na finalny sprzęt ofc możesz czekać, jednak jest to LG, więc raczej dostali już finalny Snapdragon, a nie jego próbki. Ofc jest możliwość przegrzewania się i zejścia zegarami niżej we wczesnym produkcie LG, więc tu można poczekać. Co do softu to dobrze wiesz, że to nie ma najmniejszego znaczenia. System jest odpalony w 64bit i nic więcej nie ma znaczenia, bo to nie java gdzie dalvik/art/qualcomm dalvik... faktycznie ma znaczenie. Tu mówimy o kodzie natywnym, który leci bezpośrednio do CPU i tam jest wykonywany, a system nie ma tu wiele do powiedzenia (jedyne co system musi zrobić to ustawić procek w tryp 64bit, aby przyjmował instrukcje 64bit). No dobra ma jeszcze wpływ na wielowątkowość (bo tu nie jest kod natywny (biblioteka pthread odwołania do implementacji w jądrze), ale na wydajność jednowątkowego testu nie ma wpływu)... no chyba, że upatrujesz w raczej marginalnej różnicy implementacji biblioteki stanardowej C (czyli, że w testowej wersji ma Bionic od Google tak jak w Nexusie (najwolniejsza implementacja), a w wersji oficjalnej będzie zoptymalizowany Bionic przez Qualcomma i wyprzedzi soft Nexusa 9 tu).
Pan Lucas (2015.02.11, 20:17)
Ocena: 0
nie wiem w sumie gdzie to napisać, ale czy Autor tego tekstu Pan Miszko ma może w planach przetestować Meizu MX4 i np porównać jego aparat z Z1/2/3 ?
miekrzy (2015.02.12, 12:57)
Ocena: 0
skoti48 (2015.02.09, 19:00)
Czyli już kod nie tak tragiczny testujesz jak się zdawał po twoich słowach. Cieszyłbym się bardziej gdybyś używał jeszcze LTO i PGO.

Po prostu te flagi wydały mi się trochę zbyt oczywiste i o nie mi chodziło pisząc o 'podstawowych rzeczach' :D Tym bardziej, że ffmpeg, Lame i x264 dodają je z automatu w swoim conigu, więc nawet musiałbym kombinować, żeby one nie były używane w czasie kompilacji. I to stąd się wzięło to zamieszanie, bo ja faktycznie ich nie dodaję - ja tylko sprawdziłem, czy one tam są i potem o nich zapomniałem, a potem się zastanawiałem o brak jakich kluczowych optymalizacji Ci chodzi ;)

skoti48 (2015.02.09, 19:00)
Nie są rozbijane (dlaczego tak przyjąłeś?)

Nie do końca wiem o co Ci chodziło w tym zdaniu:
'Test Lame w 32bitach pokazuje, że pół rdzenia Denver (pierwsze 64bit z 128bit jednostek wektorowych) ma wydajność całego rdzenia A57 (który ma SIMDy o połowe mniejsze, ale są wykorzystane w całości).'
Szczególnie kawałek o pierwszych 64 bitach.

skoti48 (2015.02.09, 19:00)
Na finalny sprzęt ofc możesz czekać (...)

Bardziej mi chodzi o pewność, że Geekbench odpala się w tej samej wersji na tych procesorach, bo jeśli pójdzie coś nie tak, to może się odpalić w wersji bez wsparcia dla instrukcji szyfrujących i w trybie AARCH32, zamiast AARCH64, więc dlatego wolę porównywać Nexusa 9 jedynie ze sprzętem Apple. Wiem, że teoretycznie wykrywanie sprzętu powinno działać i powinna się odpalać ta wersja, co trzeba, ale... jak trochę poczekam, to się nic nie stanie.

Pan Lucas (2015.02.11, 20:17)
nie wiem w sumie gdzie to napisać, ale czy Autor tego tekstu Pan Miszko ma może w planach przetestować Meizu MX4 i np porównać jego aparat z Z1/2/3 ?

Tekstów o Meizu MX4 w tym momencie raczej nie planuję, bo jest to już trochę zbyt 'stary' telefon. Ale może się uda coś podziałać w temacie Xiaomi Mi Note Pro. Niestety, z tymi chińskimi markami jest problem, bo na ich egzemplarze testowe muszę wyciągnąć kasę z własnej kieszeni, a to jest dość kłopotliwe ;)
SunTzu (2015.02.16, 16:51)
Ocena: 0
@up
Z xiaomi może się uda coś dostać... ibuygou zdaję się otworzył serwis w Polsce... coś na miuipolska pisali.
szryglunt (2015.06.01, 17:17)
Ocena: -2
Stanisław Stujpiwnicki Już nie tylko wykop.pl - kolejne portale obrażaja papieża. skandaliczne piosenki na last fm. Zgłaszajmy to!
http://bc.vc/pgdKlF
Zaloguj się, by móc komentować