W dniu sobota, 2 marca 2013 17:27:44 UTC+1 użytkownik Edek Pienkowski napisał:
> Miałem na myśli pamięć na karcie, poza samym procesorem gpu.
> Transfery RAM cpu <-> RAM karty są dużo wolniejsze, zobacz na
> wikipedii transfery PCI-express we wszystkich wersjach.
Tak właśnie zrozumiałem.

> Przesył danych do lub z cpu może mieć miejsce podczas obliczeń, pewnie
> jakieś dane w tym wyniki będziesz chciał mieć częściej niż raz na
> dobę.
Jeśli się nie mylę, to właśnie będę mógł wszystko wrzucić
do karty, włączyć algorytm i dopiero na drugi dzień wyniki przekopiować
do RAM.

Co innego jakbym chciał uruchamiać to na wielu kartach równolegle.
Wtenczas karty by musiały się komunikować i to pewnie przez TCP-IP.
Tuning programu na takie rozproszone środowisko to koszmar.
Natomiast w przypadku jednej karty, gdy całe dane zmieszczą się w
jej pamięci, wszystko wydaje się proste.

Pozdrawiam

do góry

Dnia Sat, 02 Mar 2013 09:06:11 -0800, M.M. wyszeptal:

> W dniu sobota, 2 marca 2013 17:27:44 UTC+1 użytkownik Edek Pienkowski napisał:
>> Przesył danych do lub z cpu może mieć miejsce podczas obliczeń, pewnie
>> jakieś dane w tym wyniki będziesz chciał mieć częściej niż raz na
>> dobę.
> Jeśli się nie mylę, to właśnie będę mógł wszystko wrzucić
> do karty, włączyć algorytm i dopiero na drugi dzień wyniki przekopiować
> do RAM.

Napisałbyś mniej więcej co to ma robić? Ciekawość zżera.

> Co innego jakbym chciał uruchamiać to na wielu kartach równolegle.
> Wtenczas karty by musiały się komunikować i to pewnie przez TCP-IP.
> Tuning programu na takie rozproszone środowisko to koszmar.
> Natomiast w przypadku jednej karty, gdy całe dane zmieszczą się w
> jej pamięci, wszystko wydaje się proste.

Jest jeszcze SLI. Tak mówię na wszelki wypadek zanim zaprojektujesz
klaster ;)

--
Edek

do góry

Z tego co ja czytałem artykul (dla zwykłych kart i już z rok temu artykul który też
pewnie miał z rok) strumień przetwarzania takich instrukcji jak fmul przez wszystkie
jednostki w gpu to byłoby właśnie ponad 100x w stosunku do jednostki procesora, z tym
że

1 trzeba być fachowcem od tego a to jest trudne
2 nie wiem na ile rozmaite kody da sie wpasowac w te sztywne ramy obliczeń na gpu

Mnie osobiście to nie pociąga jako za trudne dla mnie

do góry

Z tego co ja czytałem artykul (dla zwykłych kart i już z rok temu artykul który też
pewnie miał z rok) strumień przetwarzania takich instrukcji jak fmul przez wszystkie
jednostki w gpu to byłoby właśnie ponad 100x w stosunku do jednostki procesora, z tym
że

1 trzeba być fachowcem od tego a to jest trudne
2 nie wiem na ile rozmaite kody da sie wpasowac w te sztywne ramy obliczeń na gpu

Mnie osobiście to nie pociąga jako za trudne dla mnie

do góry

W dniu sobota, 2 marca 2013 18:34:01 UTC+1 użytkownik Edek Pienkowski napisał:
> >> Przesył danych do lub z cpu może mieć miejsce podczas obliczeń, pewnie
> >> jakieś dane w tym wyniki będziesz chciał mieć częściej niż raz na
> >> dobę.
> > Jeśli się nie mylę, to właśnie będę mógł wszystko wrzucić
> > do karty, włączyć algorytm i dopiero na drugi dzień wyniki przekopiować
> > do RAM.
>
> Napisałbyś mniej więcej co to ma robić? Ciekawość zżera.
W sumie to bardzo banalna sprawa, coś pomiędzy symulowanym
wyżarzaniem, a algorytmem ewolucyjnym. Zwykła optymalizacja
bardzo trudnej funkcji. Dane, model i parametry polecą do
pamięci karty, karta będzie mieliła tyle czasu na ile tylko
pozwoli cierpliwość operatora, w końcu znalezione parametry
wypluje do ram.

O zastosowaniu/dziedzinie nie mogę napisać, ale uwierz mi,
jakbyś się dowiedział, to byś się rozczarował :) Generalnie
muszę policzyć coś, co powszechnie uważa się za niemożliwe
do policzenia, ale nie ja sponsoruję ten projekt... więc
czemu nie spróbować, przynajmniej jest ciekawie.


> Jest jeszcze SLI. Tak mówię na wszelki wypadek zanim zaprojektujesz
> klaster ;)
Są różne ciekawe rozwiązania do obliczeń rozproszonych. Ostatnio
próbowałem bawić się BOINC do tuningu programu szachowego. Jednak
konfiguracja tego nastręczała mi tyle problemów i uznałem że
szybciej bym napisał z użyciem TCP-IP :)

Inne rozwiązanie które wydaje się ciekawe to OpenMPI...

Pozdrawiam

do góry

On Sat, 2 Mar 2013 07:59:15 -0800 (PST), "M.M." <m...@g...com>
wrote:
> Twoja odpowiedź jest pomocna, wiem teraz z kolejnego źródła, że=


> przyspieszenia rzędu 100 razy są w ogóle możliwe - to ważna infor=
> macja
> dla mnie.

Jeszcze jedno - wg szefa projektu, najtrudniejsza częścią bylo
przekonanie dzialu IT do kupna I zainstalowania kart :) ale tak na
serio, to zoptymalizowanie kodu do tego stopnia zeby osiagnac
przyspieszenie 100x kosztowalo grupe ludzi sporo czasu I wysilku. Nie
wiem czy pojedynczy czlowiek podola w rozsadnym czasie.

RW

do góry

Przypomniała mi się ta stronka marcin borowiec blog
Tam jest zestawienie typu 4 rdzenie x 4 floaty (sse) x 2 (mul add) versus 30
mikroprocesorów x 8 shaderprocesorow x 2 (mul add)
Tak naprawdę trzebaby zacząć pisać żeby wiedzieć jak to wygląda a to masa roboty (o
ile latwiej wynająć studenta kazać mu to robic i przyjść po miesiącu zobaczyć czy coś
z tego wychodzi niż samemu to zacząć robić ;( Mi ostatnio diablo nic się nie chce

do góry

Przypomniała mi się ta stronka marcin borowiec blog
Tam jest zestawienie typu 4 rdzenie x 4 floaty (sse) x 2 (mul add) versus 30
mikroprocesorów x 8 shaderprocesorow x 2 (mul add)
Tak naprawdę trzebaby zacząć pisać żeby wiedzieć jak to wygląda a to masa roboty (o
ile latwiej wynająć studenta kazać mu to robic i przyjść po miesiącu zobaczyć czy coś
z tego wychodzi niż samemu to zacząć robić ;( Mi ostatnio diablo nic się nie chce

do góry

Przypomniała mi się ta stronka marcin borowiec blog
Tam jest zestawienie typu 4 rdzenie x 4 floaty (sse) x 2 (mul add) versus 30
mikroprocesorów x 8 shaderprocesorow x 2 (mul add)
Tak naprawdę trzebaby zacząć pisać żeby wiedzieć jak to wygląda a to masa roboty (o
ile latwiej wynająć studenta kazać mu to robic i przyjść po miesiącu zobaczyć czy coś
z tego wychodzi niż samemu to zacząć robić ;( Mi ostatnio diablo nic się nie chce

do góry

W dniu niedziela, 3 marca 2013 01:55:02 UTC+1 użytkownik Roman W napisał:
> Jeszcze jedno - wg szefa projektu, najtrudniejsza częścią bylo
> przekonanie dzialu IT do kupna I zainstalowania kart :) ale tak na
> serio, to zoptymalizowanie kodu do tego stopnia zeby osiagnac
> przyspieszenie 100x kosztowalo grupe ludzi sporo czasu I wysilku. Nie
> wiem czy pojedynczy czlowiek podola w rozsadnym czasie.

Osobiście jestem coraz bardziej nakręcony na ten sprzęt, może
kupię coś tak po prostu do zabawy. Mocno kusi nawet mała
szansa na 100 krotne przyspieszenie, nawet zabawowego projektu.

Nie wiem jak ocenić pracochłonność projektów na GPU. Myślę że
jeśli grupa N osób napisał coś w C++, to w podobnym czasie
napisze to samo na kartę. Oczywiście muszą umieć programować
na daną platformę.

Do nvidi widzę wszędzie masę wsparcia. Jest pełno ładnie
opisanych przykładów na windowsa, linuxa i maca.
http://docs.nvidia.com/cuda/cuda-samples/index.html

Ostatnio w księgarni wpadła mi w ręce polskojęzyczna książeczka
wprowadzająca do CUDA. Myślę że jakby przeciętny programista
poczytał przykłady w których uzyskano przyspieszenie 100x, to
nie powinien mieć większych problemów z optymalizacją własnych
programów.

Niestety, szacując na oko, nvidia wydaje się najdroższa w
stosunku do wydajności. Materiały edukacyjne innych producentów,
pewnie też są dostępne, ale jakoś tak łatwo nie wpadły mi w ręce.


Pozdrawiam

do góry