Projekt miesiąca SKB@P na CPU w grudniu 2012

Zaczęty przez Szopler, 29 Listopad 2012, 12:29

Czy SKB@P może liczyć na CPU projekt POEM skoro LHC nie daje próbek?

Tak
6 (42.9%)
Nie
8 (57.1%)

Głosów w sumie: 14

Głosowanie skończone: 01 Grudzień 2012, 12:29

Szopler

Jak większość z Was wie oba wybrane przez nas na 'Projekt Miesiąca' projekty mają problemy z karmieniem.
PM-CPU: LHC Classic (Test4Theory daje WU, ale maszyna wirtualna zajmuje tylko 1.5 Core)
PM-GPU: POEM - brak jednostek na GPU, projekt zapasowy - SETI marnie się liczy na GPU (prawie 0% load).

Czy w związku z tym SKB@P może liczyć na CPU projekt POEM?

Ania

Cytat: Szopler w 29 Listopad 2012, 12:29
Czy w związku z tym SKB@P może liczyć na CPU projekt POEM?

To jest pytanie "wprost" ?
Jeśli tak, to uważam, że nie powinniśmy liczyć POEM na CPU jeśli to samo (ale tu chyba tak nie jest) można liczyć na GPU.
W innym wątku wskazałam dlaczego.  Pewien wyłom robi fakt że chyba w POEM co innego liczy się poprzez CPU a co innego poprzez GPU.


Szopler

Tak, to pytanie wprost.
Z tego co ostatnio wyszło to ta "bardziej wartościowa" część POEM liczy nadal tylko na CPU. Na GPU były ponoć wykonywane obliczenia związane z krystalizacją związków organicznych co ma m.in. pomóc w wytwarzaniu lepszych wyświetlaczy typu OLED.

Ania

Jak dla mnie: nie powinniśmy liczyć na CPU.
Nie potrafię powiedzięć które z tych obliczeń są wartościowsze i które skończą się sukcesem (tzn. będzie efekt).

Ale w pewien sposób nie licząc na CPU tylko na GPU wskazujemy adminom projektu że powinnio pisać aplikacje na GPU. Lepiej żeby 20 osób napisało aplikacje na GPU i straciło na to miesiąc (strzelam) niż przez 6 misięcy 8000 (000) osób liczyło to na CPU.

Bezprym

Moje zdanie: powinniśmy liczyć eOn, skoro zajął drugie miejsce.
Identyczna sytuacja, jak rok temu (LHC->Yoyo) i dwa miesiące temu (Climate-> SZTAKI)

Czemu POEM ma być projektem miesiąca, skoro zajął piąte miejsce?
Straszny bałagan się w PM porobił...

krzyszp

Cytat: Ania w 29 Listopad 2012, 12:53
Ale w pewien sposób nie licząc na CPU tylko na GPU wskazujemy adminom projektu że powinnio pisać aplikacje na GPU. Lepiej żeby 20 osób napisało aplikacje na GPU i straciło na to miesiąc (strzelam) niż przez 6 misięcy 8000 (000) osób liczyło to na CPU.
To nietak. Admini dość wyraźnie wytłumaczyli na forum, że przeniesienie obliczeń aktualnie wykonywanych na CPU do GPU nie jest możliwe ze względu na specyfikę obliczeń i nie ma nic wspólnego z trudnością implementacji, a raczej z architekturą sprzętu (GPU się po prostu nie nadaje do tych obliczeń). Wytłumaczyli także, dlaczego aplikacje GPU wymagają także rdzenia CPU, gdyż w tych próbkach tylko część (i to nie dużą) obliczeń daje się przenieść do GPU.


Należę do drużyny BOINC@Poland
Moja wizytówka

Ania

Cytat: krzyszp w 29 Listopad 2012, 13:32
Cytat: Ania w 29 Listopad 2012, 12:53
Ale w pewien sposób nie licząc na CPU tylko na GPU wskazujemy adminom projektu że powinnio pisać aplikacje na GPU. Lepiej żeby 20 osób napisało aplikacje na GPU i straciło na to miesiąc (strzelam) niż przez 6 misięcy 8000 (000) osób liczyło to na CPU.
To nietak. Admini dość wyraźnie wytłumaczyli na forum, że przeniesienie obliczeń aktualnie wykonywanych na CPU do GPU nie jest możliwe ze względu na specyfikę obliczeń i nie ma nic wspólnego z trudnością implementacji, a raczej z architekturą sprzętu (GPU się po prostu nie nadaje do tych obliczeń). Wytłumaczyli także, dlaczego aplikacje GPU wymagają także rdzenia CPU, gdyż w tych próbkach tylko część (i to nie dużą) obliczeń daje się przenieść do GPU.

To własnie "tak" :)W tym przypadku przy tych tłumaczeniach (adminach) liczenie na CPU ma sens jeśli zależy nam na liczeniu tego konkretnego "podprojektu". Wydaje mi się że jest tego mniejszość (takich podprojektów).
Dobrym przykładem tych samych obliczeń jest SETI.




krzyszp

Cytat: Ania w 29 Listopad 2012, 16:07
Cytat: krzyszp w 29 Listopad 2012, 13:32
Cytat: Ania w 29 Listopad 2012, 12:53
Ale w pewien sposób nie licząc na CPU tylko na GPU wskazujemy adminom projektu że powinnio pisać aplikacje na GPU. Lepiej żeby 20 osób napisało aplikacje na GPU i straciło na to miesiąc (strzelam) niż przez 6 misięcy 8000 (000) osób liczyło to na CPU.
To nietak. Admini dość wyraźnie wytłumaczyli na forum, że przeniesienie obliczeń aktualnie wykonywanych na CPU do GPU nie jest możliwe ze względu na specyfikę obliczeń i nie ma nic wspólnego z trudnością implementacji, a raczej z architekturą sprzętu (GPU się po prostu nie nadaje do tych obliczeń). Wytłumaczyli także, dlaczego aplikacje GPU wymagają także rdzenia CPU, gdyż w tych próbkach tylko część (i to nie dużą) obliczeń daje się przenieść do GPU.

To własnie "tak" :)W tym przypadku przy tych tłumaczeniach (adminach) liczenie na CPU ma sens jeśli zależy nam na liczeniu tego konkretnego "podprojektu". Wydaje mi się że jest tego mniejszość (takich podprojektów).
Dobrym przykładem tych samych obliczeń jest SETI.
Bez sensu, tzn mają zlikwidować projekt, bo nie da się na GPU liczyć?
Zastanów się chwilkę, zanim coś napiszesz. Jeśli projekt ma app i na CPU i na GPU powinien być w obu kategoriach.
Ja widzę, że Ty uparcie dążysz do przestawienia wszystkiego na punkty  :bad:


Należę do drużyny BOINC@Poland
Moja wizytówka

Ania

Nie. Punkty są dodatkowym miernikiem.

Jeśli TE SAME DANE można przeliczyć na CPU i GPU (szybciej) . To nienależy danego projektu liczyć na CPU.

Jeśli TE DANE można liczyć tylko na CPU (nie da się przerobić na GPU). To trudno można liczyć na CPU

...albo poczekać na inne podejście do tych danych (inny sposób) co umożliwi ich liczenie w przyszłości na GPU.

... kto kiedyś myślał, że tak wiele danych można przeliczyć na GPU.  Kiedyś może się okazać że wszystko da się "przekompilować na GPU" (np, dodając do GPU dodatkowe rozkazy itp.)

krzyszp

Cytat: Ania w 29 Listopad 2012, 16:18
Nie. Punkty są dodatkowym miernikiem.
Jeśli TE SAME DANE można przeliczyć na CPU i GPU (szybciej) . To nienależy danego projektu liczyć na CPU.
No to mi jeszcze napisz, jak ktoś, kto nie ma GPU ma przeliczyć bardziej wydajnie na GPU...
Nie próbuj innym zabierać wyboru przez wykreślanie projektu, bo TWOIM ZDANIEM tak trzeba! W zespole jest ponad 8k liczących (ponad 1,5k aktywnie) i zaledwie odsetek ma GPU zdatne do obliczeń... Jeśli w głosowaniu zażyczą sobie liczyć Seti na CPU, to niech tak będzie, co najwyżej możesz to zignorować i liczyć to co Ty wolisz i jak wolisz.


Należę do drużyny BOINC@Poland
Moja wizytówka

Szopler

Dlatego ta dyskusja nie ma sensu :)

Niech każdy liczy co chce i na czym chce. Nie będziemy przecież czekać z próbą znalezienia leku na raka do czasu aż nie pojawią się aplikacje na GPU - może coś uda się znaleźć wcześniej, albo chociaż ukierunkować przyszłe badania na GPU...

Problem można rozpatrywać co najwyżej w nawiązaniu do SKB@P...

Ania

Nikomu nie odbieram prawa wyboru. Ale nie wszyscy z 8k osób wiedzą że dany projekt dużo szybciej można przeliczyć na GPU.

Przykładowo:
jaki sens ma liczenie projektu X na CPU przez 1k osób. Jeśli te same wyliczenia może zrobić 5 osób z GPU w tym samym czasie.
Zmarnowany jest potencjał 1k CPU. To jest "ideowy" argument jak myślę.

Takie działania (optymalizację) powinien promować PM.

Ania

Cytat: krzyszp w 29 Listopad 2012, 16:26
No to mi jeszcze napisz, jak ktoś, kto nie ma GPU ma przeliczyć bardziej wydajnie na GPU...

No własnie. Spojrzenie na pojedynczą osobę. A nie na efektywność liczenia przez zespół.
Wyobrażmy sobie że te 8k osób staje się "jedną osobą" posiadającą cały zasób sprzętowy tych osób (dla ułatwienia przemyśleń). Czy ma sens wtedy liczyć ten sam projekt na CPU i GPU. W brzegowych warunkach pewnie tak (wyścigi, próbki daje tylko jeden projekt itp) ... ale generalnie nie byłoby to właściwe ... jest wiele innych pożytecznych projektów które proszą o CPU.
\
Osobiście: Jeśli liczę Collatz (właśnie liczę) na GPU to bez sensu byłoby liczyć go też na CPU. NA CPU liczę dlatego WCG.

krzyszp


Cytat: Ania w 29 Listopad 2012, 16:31
Nikomu nie odbieram prawa wyboru.
O really?
Cytat: Ania w 29 Listopad 2012, 16:18
Jeśli TE SAME DANE można przeliczyć na CPU i GPU (szybciej) . To nienależy danego projektu liczyć na CPU.

Więc proszę, nie wymagaj wyrzucania projektów z głosowania i nie manipuluj wypowiedzi  :whip:


Należę do drużyny BOINC@Poland
Moja wizytówka

Ania

Cytat: krzyszp w 29 Listopad 2012, 16:41

Cytat: Ania w 29 Listopad 2012, 16:31
Nikomu nie odbieram prawa wyboru.
O really?
Cytat: Ania w 29 Listopad 2012, 16:18
Jeśli TE SAME DANE można przeliczyć na CPU i GPU (szybciej) . To nienależy danego projektu liczyć na CPU.

Więc proszę, nie wymagaj wyrzucania projektów z głosowania i nie manipuluj wypowiedzi  :whip:

Odnośnie pierwszego - uważasz że Collatz powinien być w wyborze na CPU ?

Odnośnie drugiego - Grube zarzuty :(
Nie wymagam - tylko proponuje (jak mam to opisywać ?), Przedstawiam swoje zdanie. Z każdą odpowiedzią mam więcej informacji - to jest forum wymiany wiedzy i informacji
Ile osób np. wiedziało że POEM liczy inne dane na CPU i na GPU ?   Może taka informacja powinna być podana przy wyborze PM.  Mam wrażenie - może mylne, że wiele osób z 8k nie wie co konkretnie liczy się w poszczególnych projektach.

Szopler

Piękny offtop nam się zrobił... :wth:

Ania

Cytat: krzyszp w 29 Listopad 2012, 13:32
...... Wytłumaczyli także, dlaczego aplikacje GPU wymagają także rdzenia CPU, gdyż w tych próbkach tylko część (i to nie dużą) obliczeń daje się przenieść do GPU.

[smg id=9771 type=full align=center caption="flops"]

To co oni jeszcze na GPU liczą jeśli większość ich obliczeń robi CPU ? (wielokrotnie słabsze !)

Ania

Trochę zły obrazek załaczyłam.... te powinny lepiej obrazować moje przemyślenia ...   (aktualniejszych nie znalazłam :( )

[smg id=9774 type=full align=center caption="f1"]

[smg id=9775 type=full align=center caption="f2"]

krzyszp

Aniu, słyszałaś kiedyś o przetwarzaniu strumieniowym?
A czy możesz mi powiedzieć, dlaczego Ati 5870 będące 100x szybsze od i5 nie jest montowane jako główne CPU w kompie?
Jeśli nie, to ja ci powiem - tylko część pracy CPU może być przerzucone do GPU, które doskonale radzi sobie z danymi strumieniowymi, ale gorzej z ogólnymi. Dodatkowym problemem jest transfer danych do CPU, a nie od niego...

Ale to dyskusja akademicka - programiści zwykle wiedzą, co robią...


Należę do drużyny BOINC@Poland
Moja wizytówka

Szopler

Niektórych zagadnień nie da się przenieść do GPU choćby w przypadki gdy dany problem musi być rozwiązywany sekwencyjnie, czyli musi być znany wynik poprzedniej iteracji żeby można było wykonać następną. Kiedy przesyłanie danych zajmuje dużo więcej czasu niż same obliczanie kolejnych kroków jest to po prostu nie opłacalne.

Ania

:) 

Jestem fanką liczenia strumieniowego ... uwielbiam aplikacje na GPU .... zapomniałeś ?  Aczkolwiek CPU tez potrafi i pracuje strumieniowo.

Ale nie znalazłam odpowiedzi na pytania:
1) Mając GPU i CPU do dyspozycji warto liczyć Collatz na CPU ?   
2) Co takiego liczy POEM na GPU jeśli sporo więcej danych liczy i tak CPU który jest kilkaset razy słabszy a procentowe obłożenie ich wydajności jest często powyżej 80%  ? 

Odpowiem od razu (tak jak się domyślam) ponieważ chce zakończyć ten podtemat który rzeczywiście zmierza do teorii programowania i jej zasad.

Ad.1) Jak już ktoś napisał - nie ma o czym dyskutować - nigdy taka sytuacja nie wystąpiła i miejmy nadzieję nie wystąpi.
Ad.2) Pewnie odpisali tak na odczepnego  ( i tak nie mamy szansy tego sprawdzić) lub jeszcze nie zoptymalizowali aplikacji GPU

Karlik

Cokolwiek może liczyć. Wystarczy, że liczy coś takiego:
wygeneruj N liczb (upraszczając - mogą to być jakieś bardziej skomplikowane modele matematyczne) - tym może zająć się GPU
wybierz najlepszą spośród tych N liczb - jakkolwiek by tego nie napisać, GPU się do tego po prostu średnio nadaje, ogólnie cokolwiek mającego if-elsey nie powinniśmy dawać na GPU, oczywiście, akademicko można coś takiego zrobić, ale wiesz, że w ten sposób wykorzystując GPU masz gorszą wydajność niż korzystając z CPU? Naprawdę, praktycznie każdy projekt można "przepisać" na liczenie za pomocą karty graficznej, czy to ma sens to już inna sprawa

Szopler

Wiemy już, że PM został ostatecznie eOn...