Zrobiliśmy porównanie między FPGA i CUDA. Jedna rzecz, w której cuda świeci, jeśli możesz naprawdę sformułować swój problem w sposób SIMD i możesz uzyskać dostęp do pamięci połączonej. Jeśli dostęp do pamięci nie jest połączony (1) lub jeśli masz inny przepływ sterowania w różnych wątkach, GPU może drastycznie stracić swoją wydajność, a FPGA może ją przewyższyć. Inną rzeczą jest, gdy Twoja operacja jest realnie mała, ale masz jej ogromną ilość. Ale nie można (np. z powodu synchronizacji) żadnego startu to w pętli w jednym jądrze, a następnie czasy wywołania dla jądra GPU przekraczają czas obliczeń.

Również moc FPGA może być lepsza (zależy od scenariusza aplikacji, np. GPU jest tylko tańsze (pod względem watów/Flop), gdy jego obliczenia cały czas).

Oczywiście FPGA ma również pewne wady: IO może być jeden (mieliśmy tutaj aplikację były potrzebne 70 GB / s, nie ma problemu dla GPU, ale aby uzyskać tę ilość danych do FPGA trzeba konwencjonalnych Zaprojektuj więcej pinów niż dostępnych). Kolejną wadą jest czas i pieniądze. FPGA jest znacznie droższy niż najlepszy GPU, a czas rozwoju jest bardzo wysoki.

(1) jednoczesny dostęp z różnych wątków do pamięci musi być do adresów sekwencyjnych. Czasami jest to naprawdę trudne do osiągnięcia.

Wybrałbym CUDA.
Pracuję w przetwarzaniu obrazów i od lat próbuję dodatków sprzętowych. Najpierw mieliśmy i860, potem Transputer, potem DSP, potem FPGA i direct-compliation-to-hardware.
Innevitably stało się to, że do czasu, gdy płyty sprzętowe były naprawdę debugowane i niezawodne, a kod został do nich przeniesiony - zwykłe Procesory awansowały, aby je pokonać, lub Architektura maszyny hostingowej się zmieniła i nie mogliśmy korzystać ze starych płyt lub twórców płyty zbankrutował.

Przyklejając się do czegoś takiego jak CUDA, nie jesteś przywiązany do jednego małego specjalistycznego producenta płyt FPGA. Wydajność GPU poprawia się szybciej niż procesory i jest finansowana przez graczy. Jest to technologia głównego nurtu, więc prawdopodobnie połączy się z procesorami wielordzeniowymi w przyszłości, a więc ochroni twoją inwestycję.

FPGAs

• What you need:
  • Learn VHDL/Verilog (and trust me you won ' t)
  • kupić sprzęt do testowania, licencje na Narzędzia syntezy
  • Jeśli wybierzesz jakiś dobry framework (np. : RSoC )
    • rozwiń projekt (a to może potrwać lata)
  Jeśli nie:
  • DMA, sterownik sprzętowy, ultra drogie narzędzia syntezy
  • mnóstwo wiedzy o autobusach, mapowaniu pamięci, syntezie hw
  • Zbuduj hw, kup ip rdzenie
  • rozwiń projekt

GPGPU (CUDA/OpenCL)

• masz już hw do przetestowania.
• Porównaj z FPGA:
  Wszystko jest dobrze udokumentowane .
Wszystko jest tanie]}
• Wszystko prace
• Wszystko jest dobrze zintegrowane z językami programowania

Rozwiązanie oparte na FPGA prawdopodobnie będzie znacznie droższe niż CUDA.

CUDA ma dość pokaźną bazę kodu przykładów i SDK , w tym back-end BLAS . Spróbuj znaleźć kilka przykładów podobnych do tego, co robisz, być może również patrząc na GPU Gems seria książek, aby ocenić, jak dobrze CUDA będzie pasować do Twoich aplikacji. Powiedziałbym, że z logistycznego punktu widzenia, CUDA jest łatwiejsze w pracy i znacznie, znacznie tańsze niż jakikolwiek profesjonalny zestaw narzędzi programistycznych FPGA.

W pewnym momencie zajrzałem do CUDA dla rezerwy roszczenia modelowanie Symulacyjne. Istnieje całkiem dobry cykl wykładów powiązanych z witryny internetowej do nauki. W systemie Windows musisz upewnić się, że CUDA działa na karcie bez wyświetlaczy, ponieważ podsystem graficzny ma zegar watchdog, który będzie nuke każdy proces uruchomiony przez więcej niż 5 sekund. To nie występuje w Linuksie.

Każdy mahcine z dwoma slotami PCI-E x16 powinien to obsługiwać. Użyłem HP XW9300, który można odebrać z ebay dość tanio. Jeśli tak, upewnij się, że ma dwa procesory (nie jeden dwurdzeniowy procesor), ponieważ gniazda PCI-e żyją na oddzielnych magistralach Hypertransport i potrzebujesz dwóch procesorów w maszynie, aby obie magistrale były aktywne.

Oczywiście jest to skomplikowane pytanie. Pytanie może również dotyczyć procesora komórki. I prawdopodobnie nie ma jednej odpowiedzi, która byłaby poprawna dla innych powiązanych pytań.

Z mojego doświadczenia wynika, że każda implementacja wykonywana w sposób abstrakcyjny, tj. skompilowany język wysokiego poziomu vs. implementacja na poziomie maszynowym, nieuchronnie będzie miała koszt wydajności, esp w złożonej implementacji algorytmu. Dotyczy to zarówno procesorów FPGA, jak i dowolnego typu. Zaprojektowany FPGA specjalnie zaimplementować skomplikowany algorytm będzie działać lepiej niż FPGA, którego elementy przetwarzania są generyczne, pozwalając mu stopień programowalności z rejestrów kontroli wejścia, danych i / O itp.

Innym ogólnym przykładem, gdzie FPGA może być znacznie wyższa wydajność jest w kaskadowych procesów, gdzie na wyjścia procesu stają się wejściami do innego i nie mogą być wykonywane jednocześnie. Procesy kaskadowe w FPGA są proste i mogą znacznie obniżyć wymagania We/Wy pamięci, podczas gdy pamięć procesora będzie używana do skutecznego kaskadowania dwóch lub więcej procesów, w których istnieją zależności od danych.

To samo można powiedzieć o GPU i CPU. Algorytmy zaimplementowane w C wykonujące na procesorze opracowane bez względu na nieodłączną charakterystykę wydajności pamięci podręcznej lub głównego systemu pamięci nie będą działać tak dobrze, jak jeden zaimplementowany, który to robi. Oczywiście, nie biorąc pod uwagę tych cech wydajności upraszcza wdrożenie. Ale na występie koszt.

Nie mając bezpośredniego doświadczenia z GPU, ale znając jego nieodłączne problemy z wydajnością systemu pamięci, również on będzie narażony na problemy z wydajnością.

Jestem programistą CUDA z bardzo małym doświadczeniem z FPGA: s, jednak próbowałem znaleźć porównania między nimi.

Co do tej pory wyciągnąłem:

GPU ma znacznie wyższą (dostępną ) szczytową wydajność Ma korzystniejszy stosunek FLOP/watt. To jest tańsze Rozwija się szybciej (dość szybko będziesz miał dosłownie "prawdziwy" TFLOP dostępny). Łatwiej jest zaprogramować (przeczytaj artykuł na temat tej Nie osobistej opinii)

Zauważ, że mówię, że prawdziwy / dostępny aby odróżnić od liczb, które zobaczysz w reklamie GPGPU.

Ale gpu nie jest bardziej korzystne, gdy trzeba zrobić losowy dostęp do danych. Miejmy nadzieję, że to się zmieni wraz z nową architekturą NVIDIA Fermi, która ma opcjonalną pamięć podręczną l1/l2.

Moje 2 centy

Jest to stary wątek rozpoczęty w 2008 roku, ale dobrze byłoby opowiedzieć o tym, co stało się z programowaniem FPGA od tego czasu: 1. C to gates w FPGA jest głównym nurtem rozwoju dla wielu firm z ogromną oszczędność czasu vs Verilog / SystemVerilog HDL. W C to gates projektowanie poziomu systemu jest trudną częścią. 2. OpenCL na FPGA jest dostępny przez ponad 4 lata, w tym wdrażanie zmiennoprzecinkowe i "chmurowe" przez Microsoft (Asure) i Amazon F1 (Ryft API). Z OpenCL projektowanie systemu jest stosunkowo łatwe ze względu na bardzo dobrze zdefiniowany model pamięci i API między hostem a urządzeniami obliczeniowymi.

Programiści muszą po prostu dowiedzieć się trochę o architekturze FPGA, aby móc robić rzeczy, które nie są nawet możliwe z GPU i procesorami, zarówno ze względu na to, że są stałe, jak i nie mają szerokopasmowych (100Gb+) interfejsów do świata zewnętrznego. Skalowanie geometrii wiórów nie jest już możliwe, ani pobieranie większej ilości ciepła z pojedynczego pakietu wiórów bez topienia go, więc wygląda to na koniec drogi dla pojedynczego wióra chipsy. Moja teza jest taka, że przyszłość należy do równoległego programowania systemów wieloprocesorowych, a układy FPGA mają wielką szansę wyprzedzić grę. Sprawdź http://isfpga.org / Jeśli masz obawy dotyczące wydajności, itp.

Na czym działasz? Kto jest twoim klientem? Nie znając nawet odpowiedzi na te pytania, nie użyłbym FPGA, chyba że budujesz system czasu rzeczywistego i masz inżynierów elektrycznych / komputerowych w swoim zespole, którzy znają języki opisu sprzętu, takie jak VHDL i Verilog. Jest w tym dużo i wymaga innego podejścia niż konwencjonalne programowanie.

FPGAs wypadły z łask w sektorze HPC, ponieważ są okropnym błędem w programowaniu. CUDA jest, ponieważ jest o wiele ładniejszy w programowaniu i nadal da Ci dobrą wydajność. Ja bym poszedł z tym, co społeczność HPC poszła z i zrobić to w CUDA. To łatwiejsze, tańsze, łatwiejsze do utrzymania.

Inni Dali dobre odpowiedzi, po prostu chcieli dodać inną perspektywę. Oto moja ankieta papier opublikowany w ACM Computing Surveys 2015 (jego permalink jest Tutaj), który porównuje GPU z FPGA i CPU na metryce efektywności energetycznej. Większość dokumentów donosi: FPGA jest bardziej energooszczędny niż GPU, który z kolei jest bardziej energooszczędny niż CPU. Ponieważ budżety mocy są stałe( w zależności od możliwości chłodzenia), efektywność energetyczna FPGA oznacza, że można wykonać więcej obliczeń w ramach tego samego budżetu mocy z FPGA, a tym samym uzyskać lepszą wydajność z FPGA niż z GPU. Oczywiście należy również uwzględnić ograniczenia FPGA, o których wspominają inni.

FPGA nie będzie faworyzowany przez osoby z tendencją programistyczną, ponieważ muszą nauczyć się HDL lub przynajmniej zrozumieć systemC.

Dla tych, którzy mają sprzętowy błąd FPGA będzie pierwszą opcją rozważaną.

W rzeczywistości wymagane jest mocne zrozumienie obu i wtedy można podjąć obiektywną decyzję.

OpenCL jest przeznaczony do pracy zarówno na FPGA i GPU, nawet CUDA mogą być przeniesione do FPGA.

Akceleratory FPGA i GPU mogą być używane razem

Więc nie chodzi o to, co jest lepiej jedno albo drugie. Istnieje również debata na temat CUDA vs OpenCL

Ponownie, chyba że zoptymalizowałeś i porównałeś oba do konkretnej aplikacji, nie możesz wiedzieć ze 100% pewnością.

Wielu po prostu pójdzie z CUDA ze względu na jego komercyjny charakter i zasoby. Inni pójdą z openCL ze względu na jego wszechstronność.

Najpóźniej w GTC'13 Wiele osób z HPC zgodziło się, że CUDA zostanie tutaj. FGPA są uciążliwe, CUDA staje się coraz bardziej dojrzałe wsparcie Python / C / C++ / ARM.. tak czy inaczej, to było pytanie datowane

Układy FPGA są bardziej równoległe niż układy GPU o trzy rzędy wielkości. Podczas gdy dobry GPU zawiera tysiące rdzeni, FPGA może mieć miliony programowalnych bramek.
• podczas gdy rdzenie CUDA muszą wykonywać bardzo podobne obliczenia, aby być produktywne, komórki FPGA są naprawdę niezależne od siebie.
• FPGA mogą być bardzo szybkie w przypadku niektórych grup zadań i są często używane, gdy milisekunda jest już postrzegana jako długi czas trwania.
[1]}Rdzeń GPU jest o wiele mocniejszy niż komórka FPGA i znacznie łatwiej zaprogramować. Jest rdzeniem, może dzielić i mnożyć bez problemu, gdy komórka FPGA jest zdolna tylko do dość prostej logiki logicznej. Ponieważ GPU core jest rdzeniem , wydajne jest programowanie go w C++. Nawet to jest możliwe, aby programować FPGA w C++, to jest nieefektywne (po prostu "produktywne"). Należy używać języków specjalistycznych, takich jak VDHL lub Verilog - są one trudne i trudne do opanowania.
• Większość prawdziwych i wypróbowanych instynktów inżyniera oprogramowania jest bezużyteczna z FPGA. Chcesz pętlę dla z tymi bramkami? Z której galaktyki pochodzisz? Musisz zmienić sposób myślenia inżyniera elektronika, aby zrozumieć ten świat.

Programowanie GPU w CUDA jest zdecydowanie łatwiejsze. Jeśli nie masz żadnego doświadczenia z programowaniem FPGA w HDL, prawie na pewno będzie to dla Ciebie zbyt duże wyzwanie, ale nadal możesz je programować za pomocą OpenCL, który jest trochę podobny do CUDA. Jednak jest to trudniejsze do wdrożenia i prawdopodobnie o wiele droższe niż programowanie GPU.

Który jest szybszy?

GPU działa szybciej, ale FPGA może być bardziej wydajny.

GPU ma możliwość pracy na prędkość wyższa niż FPGA może kiedykolwiek osiągnąć. Ale tylko dla algorytmów, które są specjalnie do tego przystosowane. Jeśli algorytm nie jest optymalny, GPU straci dużą wydajność.

FPGA z drugiej strony działa znacznie wolniej, ale możesz zaimplementować specyficzny dla problemu sprzęt, który będzie bardzo wydajny i zrobi wszystko w krótszym czasie.

To tak jakby jeść zupę widelcem bardzo szybko, a jeść łyżką wolniej.

Oba urządzenia opierają swoje działanie na paralelizacja, ale każda w nieco inny sposób. Jeśli algorytm może być granulowany na wiele elementów, które wykonują te same operacje (słowo kluczowe: SIMD), procesor graficzny będzie szybszy. Jeśli algorytm może być zaimplementowany jako długi potok, FPGA będzie szybszy. Ponadto, jeśli chcesz użyć zmiennoprzecinkowego, FPGA nie będzie z niego zbyt zadowolony:)

Temu tematowi poświęciłem całą pracę magisterską. przyspieszenie algorytmu na FPGA z OpenCL