Kalray prezentuje procesor DSP zbudowany z 256 rdzeni

1. Kalray zawstydzil i7 (autor: rookie | data: 5/10/12 | godz.: 11:37)
   Moze 3-ci gracz namiesza na rynku CPU?
   
   
2. Chyba mylisz (autor: raczek70 | data: 5/10/12 | godz.: 12:59)
   rodzaje procesorów... ;).
   
   
3. @up (autor: agnus | data: 5/10/12 | godz.: 13:51)
   Sandy Bitch and Ivy już się pakują i do domu...
   ;-) ;-) ;-)
   Ale ok, dobrze się coś dzieje i EU też coś tam robi.
   
   
4. Witki opadają... (autor: TeXXaS | data: 5/10/12 | godz.: 15:50)
   "Układy klasy DSP, wykorzystują mechanizm przetwarzania sygnałów, takich jak fale dźwiękowe, zapis elektryczny obrazu itp; które są zapisywane w formie cyfrowej."
   DSP to rodzaj procesora, który jest zoptymalizowany do przetwarzania strumieni danych. W odróżnieniu od typowego CPU można odwoływać się równocześnie do rejestrów, obszaru danych, obszaru instrukcji... W ten sposób, w jednym takcie można wyknać kilka operacji. Dlaczego to takie ważne? Bo część operacji robi się w dziedzinie częstotliwości - np. cyfrowa korekcja dźwięku - FFT, nałożenie filtra, deFFT. Zamiast gonić w piętkę z częstotliwością - można sprzętowo obsługiwać pewne zadania. To trochę tak jak z kartami graficznymi, które sprzętowo wspierają mpega. Tutaj np. sprzętowo obsługuje się FFT... Ten mpeg to jakoś daleko od fft nie leży... Przede wszystkim architektura jest inna.
   
   
5. @TeXXaS (autor: Promilus | data: 5/10/12 | godz.: 16:25)
   " odróżnieniu od typowego CPU można odwoływać się równocześnie do rejestrów, obszaru danych, obszaru instrukcji"
   Dobry przykład - DARAM - dual access RAM w niektórych DSP TI - w jednym cyklu może być zapis i odczyt (bo podwojone są magistrale).
   "Zamiast gonić w piętkę z częstotliwością - można sprzętowo obsługiwać pewne zadania"
   No FFT to one sprzętowo nie robią, nadal jest to implementacja programowa. Ale...
   Załóżmy, że mamy 100 zebranych próbek, na każdej musimy zrobić dodanie poprzedniej i przemnożenie sumy przez czas próbkowania (czyli proste całkowanie iirc) - dsp pozwala jedną instrukcją i jej powtarzaniem x razy (druga instrukcja z argumentem) na jednoczesne zczytanie wartości komórki, jej modyfikację i inkrementację adresu do następnego wykonania.
   "które sprzętowo wspierają mpega"
   Jest ciut inaczej - w GPU są sztywne algorytmy przeniesione na krzem, w DSP w większości przypadków tak nie ma, bo odpowiednia elastyczność musi zostać. Np. konkretna aplikacja może wymagać nie FFT, a DFT, albo będą potrzebne wielowymiarowe transformaty a sztywny algorytm w krzemie do tego się nie dostosuje. DSP jak MCU musi być maksymalnie programowalny.
   
   
6. Europa nie ma sie czego wstydzic (autor: RusH | data: 5/10/12 | godz.: 18:36)
   ARM = Cambridge
   
   propo wielordzeniowych to
   http://www.kickstarter.com/...omputer-for-everyone
   
   wszystko pieknie, ale nikt sie nie chwali z jaka precyzja osiagaja te 200 Gflop (czy 100 w przypadku 64 rdzeni 1GHz adapteva)
   
   ostro podkrecony i7 dochodzi do 100 Gflops DP (150W)
   PS3 osiaga 100 Gflops DP (70W)
   HD 4850-70 osiaga 220-250 Gflops DP (150W)
   
   do tego wazna tez jest cena, adapteva planuje sprzedawac procki w okolicach $100 (rewelacja), maja dzialajace sample
   karlay wypuscilo notki prasowe i koniec, ani slowa o samplach albo cenie, za to pelno belkotu o patentach
   
   
7. @RusH (autor: Promilus | data: 5/10/12 | godz.: 21:10)
   "PS3 osiaga 100 Gflops DP (70W)"
   W doopie maryny. Cell zwykły ma ~13GFLOPS DP, a jak czytałeś gdzieś o 100, to albo chodziło o zmodyfikowanego Cella w formie serwerowych PowerXCell i8 (który rzeczywiście tyle wyciąga), albo o "zoptymalizowany kompilator" - co sam wybiera czy double ma być double, czy float - zatem żaden benchmark DP z takimi "optymalizacjami" nie jest rzetelny.
   
   
8. faktycznie numerki z doopy (autor: RusH | data: 5/10/12 | godz.: 21:53)
   pewnie wyciaga ~100 SP na 6 SPE, no to jeszcze gozej
   
   
9. @7 ... (autor: pandy | data: 6/10/12 | godz.: 13:06)
   Jack Dongarra and his team demonstrated a 3.2 GHz Cell with 8 SPEs delivering a performance equal to 100 GFLOPS on an average double precision Linpack 4096x4096 matrix.
   
   http://en.wikipedia.org/...ocessor%29#Architecture
   http://www.netlib.org/lapack/lawnspdf/lawn175.pdf
   
   Co za roznica jak to robi SPE czy inteligetnie optymalizujac kod czy inaczej.
   Nie widze tu niczego nadzwyczajnego...moc obliczeniowa procesora nieodlacznie zwiazana jest z jakoscia kodu uruchamianego na procesorze.
   
   
10. @9. (autor: Mariosti | data: 6/10/12 | godz.: 21:00)
    Niema to jak wycinanie cytatów
    "Cell performance drops by an order of magnitude, but still reaches 20.8 GFLOPS (1.8 GFLOPS per SPE, 6.4 GFLOPS per PPE). The PowerXCell 8i variant, which was specifically designed for double-precision, reaches 102.4 GFLOPS in double-precision calculations."
    
    Specjalna wersja dla obliczeń podwójnej precyzji do serwerów tyle osiąga, ale teoretycznie.
    Teoretycznie to HD7970 1075GFlops, a cell z ps3 teoretycznie osiąga 20GFlops w DP. Prolimus wspominał o realnej do osiągnięcia mocy obliczeniowej.
    
    
11. @10 sprawdz tresc pdf (autor: pandy | data: 7/10/12 | godz.: 14:21)
    tam podaje sie sposob jak wykorzystac sprzet 32 bit do obliczen 64 bit bez tak wielkiej utraty predkosci - potwierdzaja to testy.
    
    "This means that on the Cell the iterative refinement technique fulfills its promise. It achieves performance which is
    4.7 times greater than the total double precision peak of the Cell including the PPU (21 GFLOPS), 6.7 times
    greater than the double precision peak of the SPUs (14.63 GFLOPS), and 8.3 times greater than the actual
    performance of the solve in double precision (11.8 GFLOPS)"
    
    Co do GPU to zrob kod na GPU z warunkami i rozgalezeniami - powodzenia - GPU jest szybkie tylko tam gdzie algorytm jest liniowy i nie ma warunkow. Pod tym wzgledem SPE oferuje znacznie wieksza elastycznosc - programisci z CPU narzekaja na SPE ale SPE blizej normalnym CPU niz GPU i to pisanie pod GPU jest problemem zwlaszcza ze wiele algorytmow nie wpisuje sie dobrze w specyfike dekompozycji wymagana by efektywnie wykorzystac GPU - gdyby tak bylo to juz dawno mielibysmy maszyny o architekturach SIMD/MIMD a tak sie nie dzieje i dalej SIMD/MIMD to roznego rodzaju koprocesory czy rozszerzenia (czy to jako dodatkowy sprzet poza CPU czy sprzet wewnatrz CPU).
    
    
12. @pandy (autor: Promilus | data: 7/10/12 | godz.: 18:18)
    Nie dociera i nie dotrze. Nie bez powodu jest używany typ double i FPU bezpośrednio w sprzęcie implementujące taką dokładność. Wszystkie sztuczki programowe albo o rząd wielkości obniżają wydajność, albo obniżają dokładność więc nie, to NIE JEST TO SAMO. Dlatego nikt w tym pdf nie pisze "delivers performance of 100GFLOPS DP" tylko "equals to 100GFLOPS DP" - bo to NIE jest liczone jak być powinno!
    
    
13. Promilus nie zgodze sie (autor: RusH | data: 7/10/12 | godz.: 21:07)
    praktycznie standardem jest emulacja DP na SP na kartach nvidii. Dostajesz za darmo minimum >2x wzrost predkosci zachowujac dokladnosc.
    
    
14. @RusH (autor: Promilus | data: 8/10/12 | godz.: 16:34)
    Nie masz żadnej emulacji DP na kartach nvidii - wszystkie Fermi na poziomie sprzętu przetwarzają DP w kilku cyklach, GF100/110 zajmuje to normalnie 2 cykle - tyle, że producenci przycinają. Tak samo u AMD w GCN masz natywną obsługę DP i obcinanie wydajności sztuczne, w VLIW masz DP natywnie na pojedynczym SP i blokada przetwarzania sprzętowego lub nie (jedynie top). W przypadku emulacji programowej jest to przynajmniej 1/8.
    Teraz jeśli chodzi o niedokładną optymalizację - weź skompiluj sobie klienta milkyway w cuda na karcie co DP nie obsługuje sprzetowo (np. G92 - 8800GT) i zobacz jak ładnie na forum cie obsmarują. Pewnie, że w wielu przypadkach ludziska na wyrost stosują double, ale bez przesady. Nie ma cudów, że przeliczasz bez straty wydajności na floatach i jest ten sam wynik ;) Mam dla ciebie propozycję - weź sobie podstaw pod float a=sin(pi/30); a później double b=sin(pi/60) przy czym pi musisz zdefiniować dla preprocesora (3.14159 zazwyczaj wystarcza). Potem tylko zrób printf z, hmm, 16 miejscami po przecinku przedstaw obie zmienne i zobacz gdzie się zaczyna różnica. Będzie? Będzie. A im częściej będziemy tego floata mnożyć/dzielić/dodawać/odejmować/pierwiastkować itp. tym te różnice względem double będą się pogłębiać. Żadne cuda wianki tego nie zmienią!
    
    
15. Kalray prezentuje procesor DSP zbudowany z 256 rdzeni (autor: Marucins | data: 8/10/12 | godz.: 20:00)
    Grafen, grafen, polski grafen a nie jakieś zabawki od żabojadów.
    
    
16. Promilus (autor: RusH | data: 8/10/12 | godz.: 20:12)
    emulacja nie polega na zastapieniu dp przez sp :)) tylko na uzyciu kilku operacji sp aby uzyskac ta sama precyzje co jedna instrukcja dp
    
    
17. @14 nie bardzo rozumiem (autor: pandy | data: 9/10/12 | godz.: 09:11)
    dlaczego uwazasz ze obliczanie DP przy omocy sprzetu SP ma byc zawsze 10x wolniejsze.
    We wskazanym juz artykule podano przepis jak obliczac DP przy pomocy hardware SP srednio 4x wolniej, nie wiem czy jestes programista ale ci programisci ktorych znam raczej nie interesuja sie tym jak zostala zaimplementowana hipotetyczna FMUL w CPU. I tak, trzeba sie pogodzic z faktem ze czasem trzeba pokombinowac czyli wykazac sie swietna znajomoscia sprzetu i zrozumieniem tego jak dziala by obejsc niektore ograniczenia.
    
    Jeszcze raz cytat:
    Exploiting 32 bit floating point arithmetic for performance reasons and obtaining full precision (64 bit results) are
    desirable goals. The results described here are fairly general and can be applied to various problems in linear
    algebra such as solving dense and large sparse systems using direct or iterative methods and some eigenvalue
    problems. There are limitations to the success of this process, such as when the conditioning of the problem exceeds the reciprocal of the accuracy of the single precision computations. In that case the double precision
    algorithm should be used.
    
    Jak widac ta gdzie potzeba DP to jest 10x wolniej ale tam gdzie nie wychodzi sie poza SP jest szybciej, srednio uzyskuje sie spowolnienie 4x.
    Tyle i tylko tyle - kluczem jest tu slowo SREDNIO.
    
    grafika w zasadzie nie potrzebuje DP - AMD i NVidia dodaly DP z powodu GPGPU, wiekszosc algorytmow DSP rowniez moze spokojnie zmiescic sie na 32 bitach zwlaszcza jesli programista rozumiem problem ktory implementuje.
    
    
18. @RusH (autor: Promilus | data: 9/10/12 | godz.: 16:14)
    " tylko na uzyciu kilku operacji sp aby uzyskac ta sama precyzje co jedna instrukcja dp"
    No i jak wygląda wtedy wydajność? No właśnie. Teraz weź HD3650 i zobacz jak dużo traci na softwarowym przetwarzaniu double. To nie jest 4x współczynnik.
    @pandy
    "dlaczego uwazasz ze obliczanie DP przy omocy sprzetu SP ma byc zawsze 10x wolniejsze."
    Nie uważam, że ZAWSZE. Natomiast ZAWSZE jest duży narzut względem natywnej obsługi i tak jak trzeba kilka operacji więcej by long inta liczyć na 32bit ALU, tak trzeba kilka operacji by double liczyć na 32bit FPU. Ile dokładnie - to zależy od tego jak chcemy być poprawni oraz jaką operację emulujemy.
    Jeszcze raz napiszę - wielu programistów x86 stosuje double z przyzwyczajenia. Double na FPU działa praktycznie tak samo szybko jak float więc jest to mało ważne. Double na SSE działa 2x wolniej, ale dotyczy to już kodu, który kompiler do SIMD może zwinąć - a w takim wypadku średnio ogarnięty programista to już zauważy. W przypadku GPU DP nie jest używany praktycznie nigdzie, wyjątkiem jest milkyway w zasadzie i aplikacje zw. z HPC. Poza tym nie ma aktualnie nic wymagającego takiej precyzji, ale do API jest już okienko otwarte (DX11+, OGL4.2+, OCL1.1+), niemniej nie od tego ta dyskusja się zaczęła, a od mocy obliczeniowej Cella - a tutaj nie ma się co oszukiwać - nawet na maksymalnie zgodnych z FP64 bibliotekach jest dużo wolniej niż deklarowane gdzieś 100GFLOPS (co odpowiada mniej więcej połowie wydajności w FP32) i rzeczywiście wielordzeniowe x86 mają obecnie więcej (inna sprawa - powerxcell i8 gdyby pojawił się w 22nm z taktowaniem rzędu 5GHz zmiótłby konkurencję w oka mgnieniu).
    
    
19. @18 Niestety musze sie z toba zgodzic w jednym (autor: pandy | data: 10/10/12 | godz.: 14:14)
    programisci w znaczacej wiekszosci to techniczni dyletanci nie rozumiejacy ani algorytmu ani sprzetu... niestety ale kazda generacja programistow jest gorsza od poprzedniej...