Na początku przyszłego roku do oferty AMD trafią nowe procesory z mikroarchitekturą Steamroller, która jest następcą Piledrivera i Bulldozera. Jednym z takich układów będzie APU Kaveri, którego budowę szerzej opisaliśmy TUTAJ. Z opublikowanych przez Usmana Pirzadę informacji wynika, że AMD projektując nową architekturę x86 postawiło na wzrost obliczeń dokonywanych na liczbach stałoprzecinkowych, kosztem operacji na liczbach zmiennoprzecinkowych. W pierwszym aspekcie, w porównaniu do Bulldozera, mamy do czynienia ze wzrostem o 34,5 punktu procentowego, a w drugim przypadku jest to spadek o 15,2 punktów procentowych.
Powodem tak drastycznych zmian w uzyskanych wynikach jest długa lista modyfikacji, jakie zostały wprowadzone do nowej architektury. O ile wzrost wydajności części stałoprzecinkowej był łatwy do przewidzenia, o tyle spadek wydajności w drugim z badanych aspektów wygląda dziwnie, zwłaszcza, że w Steamrollerze zostaną użyte nowe, wydajniejsze jednostki FPU. Być może słabsza wydajność podczas obliczeń z użyciem liczb zmiennoprzecinkowych związana jest z nieprawidłowym działaniem jednostek FPU we wczesnej wersji inżynieryjnej i zostanie wyeliminowana w wersji produkcyjnej. Za taką hipotezą częściowo przemawia spory wzrost wydajności odnotowany pomiędzy starszą, a nowszą próbką inżynieryjną testowanego przez AMD procesora.
Przypomnijmy, jedną z najważniejszych modyfikacji dokonanych w Steamrollerze jest wyposażenie pojedynczego modułu, składającego się z dwóch rdzeni, w dwa oddzielne, 4-drożne dekodery instrukcji dla procesora. Dla porównania w Bulldozerze/Piledriverze mieliśmy tylko jedną taką jednostkę na cały moduł, a teraz każdy rdzeń ma własny dekoder.
Poprawiono również o 20% system predykcji i działanie planisty instrukcji stałoprzecinkowych (Integer Scheduler), który teraz dysponuje oknem instrukcji większym o ¼, co przyczyni się do zoptymalizowania wykorzystania jednostek procesora. Wśród ważnych zmian nie sposób pominąć też dwóch nowych, 256-bitowych jednostek zmiennoprzecinkowych (wcześniej była jedna, współdzielona przez oba rdzenie), większej pamięci podręcznej na dane oraz usprawnionych jednostek stałoprzecinkowych, które w ciągu jednego taktu zegara są w stanie przetworzyć nawet o 30% więcej instrukcji.
K O M E N T A R Z E
Go Go AMD :-) (autor: Krzem | data: 29/10/13 | godz.: 15:17) Naprawdę chciałbym, żeby Locco miał rację i żeby walec wjechał z marką FX na desktopy... Sam bym był skłonny go nabyć - szczególnie biorąc pod uwagę specyfikację nowych konsol - wydaje się, że siła pojedynczego wątku zacznie tracić na znaczeniu w stosunku do wielowątkowości. Tym bardziej, że port gry z konsoli będzie portem z x86 na x86. Faktycznie najbliższe lata w świecie gier zdają się należeć do AMD.
@ Wedelek wkradł się błąd (autor: Krzem | data: 29/10/13 | godz.: 15:19) link ze zdania "Jednym z takich układów będzie APU Kaveri, którego budowę szerzej opisaliśmy TUTAJ" miał chyba prowadzić do http://twojepc.pl/...data-premiery-APU-Kaveri.html
@Krzem (autor: Wedelek | data: 29/10/13 | godz.: 15:34) Dzięki za uwagę, poprawione.
nie uwierzę (autor: Markizy | data: 29/10/13 | godz.: 15:54) w aż taką poprawę wyników dla tego procesora bo testy są robione na próbkach których nikt nigdy nie widział, a dodatkowo sam test może nie być specjalnie wiarygodny.
A moze to wersja serwerowa? (autor: rookie | data: 29/10/13 | godz.: 16:13) Opteron?
@wedelek (autor: Promilus | data: 29/10/13 | godz.: 16:23) arytmetyka stałoprzecinkowa to fixed point arithmetic i tak gdzie mamy wydajne FPU nikt z tego nie korzysta (bo rozdzielczość jest stała i przy mnożeniu/dzieleniu wkradają się przekłamania przez zaokrąglenia).
To na czym operują ALU to arytmetyka stałoliczbowa/całkowitoliczbowa (integer arithmetic) i nie ma tam absolutnie nic po przecinku!
wracając do newsa - skoro ulepszyli FPU dając dwie potężne 256 bitowe jednostki na moduł (w przeciwieństwie do 2x 128bit dzisiaj) to czemu wydajność spada? I czemu wg tej tabelki vishera (piledriver) jest gorsza w float od zambezi (bulldozer) skoro, jak dobrze wiemy, jest odwrotnie.
ale to właśnie plan AMD (autor: Teriusz | data: 29/10/13 | godz.: 18:34) by w heterogenicznym układnie z czasem całkowicie zastąpić FPU układem GPU i tam przeprowadzać obliczenia zmiennoprzecinkowe. To pozwoli na zredukowanie wielkości modułów w CPU.
Jak dla mnie to AMD konsekwentnie dąży do tego co sobie wcześniej obrało za plan.
@5. (autor: Kosiarz | data: 29/10/13 | godz.: 18:35) ciezko powiedziec co to jest ale raczej nie wypuszcza 2x.1.8GHz jako produkt konsumencki - chyba ze do kalkulatora.
pozyjemy zobaczymy, wazne ze cos sie dzieje i miejmy nadzieje ze jeszcze zobaczymy walke na szczycie niebieskich i czerwonych.
FPU? (autor: Conan Barbarian | data: 29/10/13 | godz.: 19:05) AMD chyba oszalało z tym FPU - Intel właśnie dlatego wygrał rodziną Core, że wpakował tam bardzo silne FPU.
@Teriusz (autor: VP11 | data: 29/10/13 | godz.: 20:12) Zanim zrobi to i programy zaczna wykorzystywac to w kodzie minie pare ladnych lat jak w ogole nie zostana zoptymalizowane programy. I AMD przejedzie sie jak z Buldozerami.
Potrzebuje w obliczeniach 80% zmiennoprzecinkowe obliczenia, a AMD je olewa od jakiegos czasu. Wiec nie dziwie sie ze zaczynaja tracic i raczej bedzie trudno im odgryzc cos sensownego.
VP11 (autor: Markizy | data: 29/10/13 | godz.: 20:45) amd ma taką koncepcje, że obliczenia stało przecinkowe zajmą się rdzenie w module (INT) a obliczeniami zmienno przecinkowymi zintegrowane IGP. Ale takie coś dopiero zobaczymy po Ex, więc spokojnie przez dwa lata zobaczymy jeszcze FPU w procesorach AMD. Chociaż na to co pisze nie ma oficjalnego potwierdzenia a jest to tylko moje przypuszczenie.
A sam przyznasz żeby użycie 512SP w takim już kaveri jako FPU dało by wymierne korzyści na tle standardowych rozwiązań.
@11 (autor: Plackator | data: 29/10/13 | godz.: 21:24) Standard hUMA który ma obsługiwać excavator, obsługuje też kaverii z steamrollerem.
Plackator (autor: Markizy | data: 29/10/13 | godz.: 21:28) zgoda, mi bardziej chodzi o coraz bardziej zaawansowane HSA, dzięki któremu na poziomie sprzętowym już role FPU pełniło by IGP.
@Markizy (autor: Conan Barbarian | data: 29/10/13 | godz.: 21:35) Chyba śnisz. Jakim cudem kod dla x86 poleci na zintegrowanym GPU? Takie myki pochłoną z nawiązką ewentualny zysk z GPU. Procek ze słabym FPU jest zwyczajnie słaby i niestety AMD oddala się takim sposobem od procesorów Core Intela.
nono (autor: piwo1 | data: 29/10/13 | godz.: 22:00) slaby wynik dla zmiennych przecinkow moze powodowac mniejsza ilosc kesza porownywanych prockow. fxy maja 16mb (8mb l2 i 8mb l3) a kaveri ma tylko 8mb l2.
@Conan (autor: PrEzi | data: 29/10/13 | godz.: 22:01) ...z drugiej strony trzeba by bylo byc idiota ze samemu sobie galaz podcinac... Mysle, ze maja wlasnie cos z HSA jako Asa w rekawie...
Ale to i tak dopiero sprawdzimy w przyszlosci.
Ja tylko licze na to, ze w koncu AMD stanie na nogi w CPU, bo -- jak pokazuja ostatnie przyklady z AMD<->NV - konkurencja to baaardzo dobra rzecz.
tfu (autor: piwo1 | data: 29/10/13 | godz.: 22:02) nawet nie bo to przeciez dwa moduly. 4mb cache l2 kontra 4mb cahe l2 +8mb cache l3.
<10 Potrzebuje w obliczeniach 80% zmiennoprzecinkowe (autor: RusH | data: 29/10/13 | godz.: 22:40) naucz sie opencl to dostaniesz szoku, nagle na starej karcie za 150zl bedziesz miec wydajnosc 8 rdzeniowego Xeona.
Conan takim cudem jak teraz te obliczenia leca na 2x 128bit moduly FPU. dekoder i scheduler wszystko w tle ladnie rozbijaja, kolejkuja i miela
Jesli GPU bedzie na tym samym kawalku krzemu to dodawanie FPU jest tylko strata realestate jesli mozna te obliczenia zroutowac do graficznej czesci cpu
przyszlosc to zmiennoprzecinkowe obliczenia TYLKO na gpu, fpu jest legacy dla milosnikow testowania wydajnosci w superpi
no mam nadzieje (autor: pawel1207 | data: 29/10/13 | godz.: 23:03) ze to jednak jakis blad wersji inzynieryjnej bo inaczej intel znowu zacznie cene.
@18 nie obraz sie ale FPU w CPU (autor: pandy | data: 29/10/13 | godz.: 23:26) i FPU w GPU maja rozne przeznaczenie - FPU ma zazwyczaj 64 i/lub wiecej bitow - np 80 bitow - GPU zazwyczaj nie potrzebuje wiecej niz 32 bity FPU za to potrzebuje ich duzo tak by przetwarzac rownolegle duza ilosc danych - w tym kontekscie wstawianie do GPU FPU o extended rpecision nie ma wiekszego sensu bo bedzie uzywane to tylko w obliczeniach ale narzut czasu na obsluge tych 80 bitow bedzie niekorzystnie wplywal na wydajnosc w obliczneiach typowych dla GPU.
Tak FPU jak GPU maja troche inne klasy algortmow - pokrywaja sie tylko czesciwo i nie da sie latwo zrobic uniwersalnego i szybkiego FPU a pozniej powielic go w 64 czy 256 blokach.
Nawet jak sobie zrobisz extended w kilku przebeigach to wydajnosc bedzie scisle zalezec od stopnia faktoryzacji algorytmu a sama wydajnosc bedzie rzad mneisjza niz mozliwa do usykania w FPU - owszem mozna myslec o wyszuikanych archtekturach ktore dynamicznie skaluja dlugosc slowa, potrafia scalac i symulowac szerokosc operacji ale to znow komplikuje sterowanie i wprowadza znow narzut tak czasu ja powierzchni zajmowanej na krzemie.
Nie zebym mial cos przeciwko GPGPU ale komputery klasy SIMD/MIMD istnieja od co najmniej 40 lat i wiadomo ze nie sa panaceum na wszystki porzeby obliczeniowe.
gpu od dawna maja DP (autor: RusH | data: 30/10/13 | godz.: 00:17) wiec to nie jest kwestia dodawania czegos, tylko uzycia tego co juz istnieje
1@. (autor: loccothan | data: 30/10/13 | godz.: 03:27) Dzięki Bratan, Ja poprostu trzymam za nich kciuki ;-) i wiem że coś wydajnego (wielordzeniowego) będzie dane na czip 1100FX. ALe zobaczymy w przyszłym roku, jak bedzie premiera. Osobiście uważam że FX Piedriver jest bardzo udanym procem, świadczą o tym Testy Crysis 3 w CF 2x7970, w WinRar i 7Zip jak również > 10000 w 3D Mark11 też jest niczego sobie.
Największą zmianą jest to że gpu będzie samo mogło sobie dodawać pracy lub zlecać też prace cpu. Nawet jak kod zostanie przygotowany tylko pod x86 to przez dekoder i obróbkę w cpu będzie mógł trafić na gpu, które zajmie się wykonaniem konkretnych obliczeń i zwróci wynik do cpu.
Oczywiście kaveri nie będzie tak łatwo, ale za 2 generacje (licząc z kaveri) takie rozwiązanie może już się pojawić, bo samo AMD dąży do tego aby jak najwięcej wykorzystać cześć IGP, podobnie myśli intel rozwijający swoje IGP.
@pandy
masz częściową racje ale AMD też będzie rozwijać gpu po to żeby jak najlepiej spełniało role FPU, zresztą obecnie działania czy to nvidii czy amd mają na celu jak najlepsze wykorzystanie architektury graficznej do obliczeń stąd koncepcje cuda i opencl i odpowiedni rozwój rdzeni graficznych.
@RusH (autor: Promilus | data: 30/10/13 | godz.: 09:18) Zamiast tak się wymądrzać zauważ, że GPU mają też wydajność całkowitoliczbową o rząd wielkości większą od CPU a jakoś AMD cały czas zwiększa możliwości CPU w tym zakresie. Nie, to nie jest tak, że olewają FPU bo chcą go zastąpić IGP - to jest niewykonalne, głównie dlatego, że stare rozkazy x87 są stricte szeregowo wykonywane i tego zrównoleglić się nijak nie da, zaś jeśli chodzi o SIMD to one mają szerokość z 4x mniejszą niż 1CU w radkach przy częstotliwości 3x większej - KONIECZNA jest szybka jednostka zmiennoprzecinkowa do kodu którego zrównoleglić się NIE DA. Intel to wie. AMD wygląda na to, że nie bardzo.
Promilus (autor: Markizy | data: 30/10/13 | godz.: 11:27) ale jak by nie patrzyć kod programów się zmienia, jeśli aplikacje przejdą na x64 to nikt nie będzie korzystać z x87. Tym bardziej że największy spowalniacz migracji z 32 na 64 zostanie niebawem ściągnięty, mowa o grach.
Dodatkowo nie wiemy jak sobie AMD wyobraża przyszłość po Exa, ale jeśli olali by x87 i innych archaicznych to i tak by wiele nie stracili bo te nisze zapełni by sobie intel. A każde nowe oprogramowanie działo by szybciej i efektywniej na procach AMD. Pod warunkiem że złączenie CPU z IGP było by efektywne.
@markizy (autor: Promilus | data: 30/10/13 | godz.: 12:52) x87 to rozkazy FPU i w zasadzie każde skalarne działanie na float/double którego w żaden sposób nie da się zwinąć do SIMD niezależnie czy w trybie legacy (32bit) czy long (64bit) kompilator zawsze przetłumaczy właśnie na nie. Nie na SSE, nie na AVX, a już z całą pewnością nie na CAL/IL. SSE/AVX ma szanse jeśli mamy w pętli ten sam rodzaj obliczeń a wyniki są całkowicie od siebie niezależne tj. np. mamy wybór 2 elementów z tablicy i ich mnożenie i zapis do innej tablicy - zatem w drugiej iteracji nie ma danych zależnych od pierwszej itp. itd - da się pętlę skalarnych obliczeń rozwinąć w wektorowe. Tak samo jeśli mamy kilka następujących po sobie tych samych działań bez pętli, albo działania na wektorach do max 4 elementów - wtedy autowektoryzacja itp. mogą zadziałać i otrzymamy kod SSE. Właśnie ze względu na to, że dużo trudniej rozwinąć w wektory 8 elementowe (256bit avx) to samo rozszerzenie SIMD mało daje w obecnych aplikacjach a wy uważacie, że simd 16 elementowy (16x32bit GCN) tutaj może zastąpić FPU. Bzdura! To co się teraz liczy to coraz nowsze rozszerzenia pokroju FMA, XOP, AVX - ale nie ze względu na 256bit, a...
FMA - mnożenie i dodawanie (multiply and accumulate - typowe do DSP) w 1 cyklu - 2 op i zachowana precyzja (brak zaokrąglania jak w fp madd), do tego 4 argumentowe. AVX 3 argumentowe (bez nadpisywania źródła) rozszerzenie SSE (tak, to jest właśnie większość AVX z Sandy Bridge). Szersze możliwości przetłumaczenia efektywnie działań na liczbach zmiennoprzecinkowych do instrukcji FPU. I Compute Units z GPU nawet się możliwościami nie umywają do tego. Zwróć uwagę, że 1CU z 16x32bit simd mając za zadanie przemnożyć ledwie 2 floaty i podać wynik jest wykorzystany w ~6% a pracuje z częstotliwością 3-4x niższą niż FPU. Właśnie z tego powodu szybki szeregowy FPU jest i przez jeszcze długi czas będzie lepszy (bo bardziej uniwersalny i efektywny) niż wolny, szeroki i równoległy SIMD. Za 10 lat może przejdzie wywalenie FPU i zastąpienie SIMD z IGP - gdy SP w IGP będą miały możliwości bliskie do obecnych implementacji FPU, ale jeszcze w cholerę im brakuje więc to jest kolejny krok w tył.
Jeśli coś moge polecić to ściągnięcie np. netbeans albo codeblocks z mingw (chyba, że na linuksie to nie trzeba), zrobić prosty program w C/C++, skompilować i później w debugerze sprawdzić jak został przetłumaczony. Potem bawić się w inne konstrukcje i flagi optymalizacji i porównać. Ręczę, że cholernie ciężko będzie osiągnąć duży stopień wektoryzacji. Z tego samego powodu jeśli już developerzy optymalizują pod SSE to tam gdzie to przynosi największe zyski najmniejszym kosztem czasu - a NIE WSZĘDZIE GDZIE SIĘ DA. Dlatego x87 ma się dobrze i będzie się miało dobrze.
x87 nie ma sie dobrze (autor: RusH | data: 30/10/13 | godz.: 14:15) tylko jest uzywane tam gdzie nie liczy sie szybkosc
problemem nie sa kompilatory slabo radzace sobie z wektoryzacja, bo tylko idiota bedzie polegac na kompilatorze zamiast dobierac odpowiedni algorytm
idiota albo spryciarz taki jak NVidia wciskajaca jeleniom przez lata PhysX skompilowany pod x87 :-)
albo intel z jego magicznym kompilatorem, ciekawe czy ICC nadal wylacza wszystkie optymalizacje na AMD
prawda jest taka ze jesli chcesz pomnozyc dwie nie zwiazane ze soba liczby zmiennoprzecinkowe to w 90% przypadkow nie zalezy ci na wydajnosci
optymalizacja rozpoczyna sie gdy twoj program musi mnozyc 2Mpixele danych kilkadziesiat razy na sekunde, a w tym GPU przebija wszystko
AMD moze grac dlugoterminowo - kastracja FPU + latwe w implementacji biblioteki opencl
z drugiej strony FPU na tej fotce wcale nie zmalalo, wiec mozliwe ze to jednak sa jakies bolaczki eng sampla :)
A Pentium IV ktoś pamięta? (autor: Atak_Snajpera | data: 30/10/13 | godz.: 15:18) Pamiętacie co Intel zrobił z FPU w tym procku? Tylko z mocną optymalizacją pod SSE2 był wstanie rywalizować z Athlonem lecącym tylko na FPU. Kolega Promilus ma rację że wiele algorytmów nie da się tak poprostu wrzucić na GPU i wszystko automagicznie przyspieszy pierdyliard razy. Nawet najnowsze silniki gier (CryEngine,Unreal Engine 4 itd ) nadal silnie są uzaleźnione od wydajności FPU.
@RusH (autor: Promilus | data: 30/10/13 | godz.: 16:25) "problemem nie sa kompilatory slabo radzace sobie z wektoryzacja, bo tylko idiota bedzie polegac na kompilatorze zamiast dobierac odpowiedni algorytm"
Weź kod źródłowy Jedi Knighta (tak, jest udostępniony, a w miarę działający jest pod OpenJK) i zrób tak by x87 stanowiły mniej niż 20% wszystkich operacji zmiennoprzecinkowych. Nie chcesz? Nie dasz rady? To uspokój się proszę, odetchnij i zrozum, że SSE wykorzystuje się w specyficznych przypadkach i nie każdy przypadek wykorzystania typu float kwalifikuje się do wektoryzacji. Baaa, wcale tych co się kwalifikują nie ma tak dużo, a jeśli są to niekoniecznie ładują cały 4 elementowy wektor. I tutaj GCN i inne GPU wynalazki zupełnie NIC nie wniosą. Co do tego po przecinku - rzuciłem Ci wyzwanie. Napisz prosty program, np. 2 wektory 4 elementowe a[] i b[] z losowymi wartościami oraz wektor c z elementami będącymi różnicą odpowiadających im elementów a i b (czyli c[1]=a[1]-b[1]), skompiluj i zobacz czy automagicznie masz SSE :) Nie? A czemu? Przecież to kilka instrukcji SSE bez pętli. A jednak kompilator domyślnie zrobi pętlę i fsub czyli odejmowanie x87. Zrozum, że tylko idiota będzie poświęcał stanowczo zbyt dużo czasu by każda jedna instrukcja operująca na float/double była SSE.
"idiota albo spryciarz taki jak NVidia wciskajaca jeleniom przez lata PhysX skompilowany pod x87 "
Nie. Ten najnowszy nadal ostro korzysta z x87 mimo wykorzystania SSE2 - dlaczego? Bo właśnie physx mimo akceleracji GPU korzysta też z szeregu obliczeń niemożliwych do zrównoleglenia - stąd wyniki mocno zależały też od wydajności CPU. Zresztą to samo dotyczy obecnie sterowników nv i amd. NV mocno wykorzystuje wielordzeniowość i niekoniecznie potrzebuje najmocniejszego jednego wątka, tymczasem radki koniecznie potrzebują najmocniejszego jednego wątka by rozwinąć skrzydła. Nie wierzysz w to co piszę? To weź kilka konfiguracji i potestuj nowsze fluidmarki.
"optymalizacja rozpoczyna sie gdy twoj program musi mnozyc 2Mpixele danych kilkadziesiat razy na sekunde, a w tym GPU przebija wszystko"
Rzecz w tym, że tego CPU od bardzo dawna nie liczy bo i po co. Natomiast liczy np. pozycje przeciwnika, tor lotu pocisku, prędkość poruszania itp. itd. Z czego wiele obliczeń wpakować do SSE się nie da bądź nie warto. Zresztą tak samo w filtrach obrazu - znaczna większość po prostu szybko przelicza ileś tam wartości sąsiednich pikseli i modyfikuje aktualny. W sam raz robota dla GPU. Ale co jest gdy algorytm zaczyna się rozgałęziać, sam siebie modyfikować itp? GPU wysiadają, a CPU targa dalej. Gdyby GPU było lekiem na wszystkie bolączki to od 4 lat mielibyśmy eldorado w obliczeniach, a wszędzie łącznie z superkomputerami GPU są tylko DODATKIEM.
"AMD moze grac dlugoterminowo - kastracja FPU + latwe w implementacji biblioteki opencl"
Nie może. Dlatego, że jeśli FPU w SR będzie jeszcze słabsze to praktycznie dla domowego użytkownika jest to spalony produkt. Co ci po wydajności K8 w dzisiejszych czasach? No właśnie.
@Atak_Snajpera - niezupełnie o to chodziło w P4. Tam miałeś długi potok i o ile ALU działały na początku z podwójną prędkością rdzenia (fast alu - rapid execution engine), to FPU nie. W związku z tym wydajność x87 per MHz była gorsza niż w Pentium III (a ta była nawet w tualatinie delikatnie gorsza niż K7). SSE2 mocno Intel reklamował ze względu na to, że miałeś floaty i double zaimplementowane w SIMD - to było pierwsze rozsądne FP SIMD, 3DNow! było delikatnie nierozsądne bo mapowało rejestry na MMX (a te na FPU) i ograniczało się do packed float (2x32bit) ale i tak bywało szybsze od x87 co skwapliwie AMD wykorzystywało przy współpracy z 3dfx nad sterownikami. 3DNow! teoretycznie mogło być do 4x szybsze od x87 iirc - ale gry z optymalizacją 3DNow! były ledwie kilka góra kilkanaście % szybsze (niż na K6) a do tego i tak wolniejsze niż bez 3DNow! za to na intelu. Więc... FPU było jest i będzie czynnikiem niezmiernie ważnym w grach. A AMD coś sprawę olewa. Równie dobrze mogą w ogóle buldożera zakopać i klepać ARMy.
Promilus (autor: Markizy | data: 30/10/13 | godz.: 18:45) przy czym jak widać po tym teście instukcje x87 można emulować i jedyny zysk jaki mamy po aktywacji tego to lepszy wynik w superpi http://www.xtremesystems.org/...e-2-%28SuperPI-x87
więc wniosek jest jeden albo amd emuluje tylko jedna instrukcje, albo x87 jest mniej popularne niż się wydaje. Z twojego postu też wnioskuje że problem leży w kompilatorze który wykorzystuje nagminne przestarzałe instrukcje. Bo w pewnym sensie ARM daje sobie rade bez instrukcji x87 o które toczy się powyżej batalia, więc dlaczego nowsze programy muszą z tego korzystać? Premiera kaveri przed nami a wraz z nim pierwsze rozwiniecie HSA czy tam huma (do wyboru do koloru) więc możliwe że przedstawią jakąś alternatywę dla wykorzystani FPU.
Wiadomo że niektórych obliczeń co obecnie wykonuje FPU nie da się łatwo wykonać na GPU o ile w ogóle, ale spora cześć jest z sukcesem realizowana co widać chociażby po tym że centra badawcze kupują rozwiązania tesli na czysto procesory x86 z typowym FPU.
Większość dodawanych obecnie rozwiązań takich jak FMA, XOP, AVX co wspomniałeś ma na celu głównie przyspieszenie skomplikowanych zadań, ale to i tak w specyficznych działaniach się przydaje często.
Czy AMD zrezygnuje z FPU na rzecz rozbudowanego GPU dowiemy się w przyszłości, tym bardziej że po Ex-a nie wiadomo co będzie dalej. Jeszcze kilka lat wstecz moc akceleratorów graficzna nie była prawie w cale wykorzystywana do obliczeń innych niż grafika 3d/2 a obecnie może wspierać procesory w znacznej cześć obliczeń.
O tym co będzie w przyszłości można gdybać jedynie.
@Markizy (autor: Promilus | data: 30/10/13 | godz.: 20:36) To do czego dałeś link to nie żadna emulacja x87 a włączenie części rejestrów zablokowanych z niewiadomego powodu. Od bardzo długiego czasu nie ma w prockach prawdziwej jednostki x87 i jej rejestrów (która to chyba się skończyła jeszcze przed pentiumami) a jednostka kompatybilna z rozkazami - ale nadal jest to sprzętowo robione, a nie emulowane. Różnica w SPI między intelem a amd całkiem nieźle oddaje co się dzieje w grach. Gry co prawda aż tak intensywnie nie używają x87, ale nadal używają i to wystarczająco dużo by słaba wydajność u AMD była problemem.
"Z twojego postu też wnioskuje że problem leży w kompilatorze który wykorzystuje nagminne przestarzałe instrukcje. "
Niezupełnie. Jeśli kompilator wykryje coś takiego:
float c=float a * float b to wykorzysta na 99% instrukcję fmul/fmulp, a nie mulss z tym, że to chyba zasadniczo bez różnicy jeśli chodzi o czas wykonania. MULSS to instrukcja SSE, gdyby to było szybsze od x87 to od Pentium III już by było wykorzystywane cały czas, a nie jest. Widocznie nie warto SIMD używać jako SISD.
"Bo w pewnym sensie ARM daje sobie rade bez instrukcji x87 o które toczy się powyżej batalia"
ARM ma własne FPU i własny SIMD, z tym że ARM zazwyczaj daje wybór, albo FPU, albo Neon. W przypadku x86 mamy oba naraz. W przypadku POWER też i jakoś nikt FPU nie zwalcza mimo potężnego altiveca.
"ale spora cześć jest z sukcesem realizowana co widać chociażby po tym że centra badawcze kupują rozwiązania tesli na czysto procesory x86 z typowym FPU"
Centra badawcze kupują też knights ferry co nie zmienia faktu, że na milion gpu przypada 2x tyle rdzeniu cpu :) To są tylko i wyłącznie akceleratory dość specyficznych obliczeń i jeszcze długo pozostaną. Ty pewnie nie pamiętasz tych czasów, ale ja mam dobrą pamięć - FPU kiedyś było zabawką dla profesorów, grafików itp - normalny użytkownik nic takiego nie miał. Amiga, PC XT, PC AT - wszędzie FPU było czymś ekstrawaganckim. Dopiero boom na FPSy zapoczątkował zmiany - większe zapotrzebowanie na FPU. Stąd 486 już miał wbudowane (w DX) i od tej pory zawsze już tak intel miał, AMD różnie kombinowało - tzn. też był FPU ale przez dłuuuugi czas słabszy (bo na riscowym jądrze innego proca, a nie projektowanym pod wykonywanie x86/87), NexGen nie miał wewn. fpu, a zewnętrzny był też do bani.
"Większość dodawanych obecnie rozwiązań takich jak FMA, XOP, AVX co wspomniałeś ma na celu głównie przyspieszenie skomplikowanych zadań, ale to i tak w specyficznych działaniach się przydaje często"
tak, c-ray lubi FMA i AVX, natomiast jest wiele aplikacji kompilowanych z tymi samymi flagami gdzie zysk jest dużo mniejszy, albo jest nawet gorzej! I co, programista ma siedzieć i kombinować jak zrobić, żeby na AMD jednak było szybciej? Ma gotowy i sprawny produkt, kompiluje i sprzedaje. A jak szpece od AMD i GCC dojdą do przyczyny i pomogą z rozwiązaniem to ewentualnie łatkę wyda. A jak nie to po co sam ma się trudzić. Na intelu działa ok.
"a obecnie może wspierać procesory w znacznej cześć obliczeń"
Jeśli chodzi o robótki graficzne - ok, jeśli chodzi o archiwa - tu różnice nie są wielkie, bo nadal większość pracy spada na CPU stąd aktualnie i3/i5 z hd graphics w winzipie przegania richlandy itp. gdy w 16.5 (ocl amd exclusive) APU potrafiło dorównać mocniejszym intelom (ale wtedy IGP w intelach nie wspierało OCL).
Intel jest liderem w tworzeniu narzędzi do programowania x86 (pomaga w gcc, tworzy icc) i to on narzuca co jest potrzebne, przydatne, ważne, a co nie. x87 nadal jest ważne i odchodzenie ot niego przez AMD będzie bolesne - bo nie dają programistą nic w zamian oprócz zwiększonego nakładu pracy by "dobrze działało na AMD".
@22 powtarzam FPU to FP on GPU (autor: pandy | data: 31/10/13 | godz.: 23:21) double precision to dalej za malo - dobre w multimediach ale nie w obliczeniach inzynierskich - w x87 masz 80 bitow - niektore FPU uzywaja wewnetrznie 96 i wiecej bitow by minimalizowac bledy zaokraglen, poza tym ilosc bitow to jeden z elementow FPU, inne to np normalizacja liczb - obsluga wszystkich aspektow zapisu zmniennoprzecinkowego, traktowanie NaN, kazda taka rzecz obniza wydajnosc FPU a np w grafice jest kompletnie zbedna.
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ć.
