Jak to jest z tymi optymalkami?

[Norbert]

Rzekomo każdy projekt wgrywa sam optymalki do projektu w którym uczestniczymy a u mnie np przy optymalce w Milce dogranej automatycznie WU liczyło ponad 10h a jak doinstalowałem ręcznie inne optymalki czas zmalał do 4h. Przyznacie że różnica jest znacząca. Więc jednak warto szukać samemu optymalki pod inne projekty czy jednak nadal pozostawać przy tym co instaluje Manager  ???

[apohawk]

Projekt wgrywa to, co uważa za słuszne ;) Optymalki wgrywasz na własną odpowiedzialność. Ja optymalkami się nie przejmuję. 10h czy 4h, po co mi te komplikacje, jak na oficjalnej aplikacji MW liczy mi się w ok. 4 minuty na grafie :P

[ksysju]

Hi

Zdanie "Rzekomo każdy projekt wgrywa sam optymalki do projektu.." jest nie prawdziwe.

Są projekty, które szybko aktualizują aplikacje, a są takie co tego nie robią.

Na forum i na wiki stosowana informacja  jest :-)

[Norbert]

Projekt wgrywa to, co uważa za słuszne ;) Optymalki wgrywasz na własną odpowiedzialność. Ja optymalkami się nie przejmuję. 10h czy 4h, po co mi te komplikacje, jak na oficjalnej aplikacji MW liczy mi się w ok. 4 minuty na grafie :P

A skąd wiesz czy przy odpowiedniej optymalce twoja karta nie łyknie WU w jedną minute co daje 4x więcej przeliczonych próbek i 4x więcej punktów z korzyścią dla całego zespołu?

[tito]

Po to siedzimy na tym forum i czytamy posty innych, aby taką wiedzę posiadać. XD
Jedyną optymalką która dużo daje to optymalka Milky na CPU.
Inne projekty sporo dają, ale przecież nie tyle.
Zresztą projektów posiadających optymalki nie ma dużo.
Enigma, SETI, Einstein, Milky.
Coś jeszcze zapomniałem/nie wiem?

[eclipse99]

Jaką optymalkę dla Einsteina masz na myśli?

[Szopler]

Projekt wgrywa to, co uważa za słuszne ;) Optymalki wgrywasz na własną odpowiedzialność. Ja optymalkami się nie przejmuję. 10h czy 4h, po co mi te komplikacje, jak na oficjalnej aplikacji MW liczy mi się w ok. 4 minuty na grafie :P

A skąd wiesz czy przy odpowiedniej optymalce twoja karta nie łyknie WU w jedną minute co daje 4x więcej przeliczonych próbek i 4x więcej punktów z korzyścią dla całego zespołu?

Jaka grafa że aż 4 minuty?

[apohawk]

4850. W zależności od humorów sterowników (10.4) lub windowsa od 3:40 do 4:30.
Właśnie wgrywam 10.5.

[Gargul]

Optymalka do Einstaina, wgrywana jest już od dawna przez serwer projektu samoczynnie.

[AiDec]

Jedyną optymalką która dużo daje to optymalka Milky na CPU.

Jeszcze optymalka dla Enigmy, ta pod Core Duo daje bardzo duzo. Pozostale optymalki dla Enigmy daja sporo, choc nie jest to tak duzo jak optymalka pod kordulo.

[Ufol]

Dlaczego tak mało projektów posiada optymalizacje? Czy wynika to z charakteru obliczeń? Mam na myśli przede wszystkim projekty biologiczne. Czemu, pomimo tak znacznego zaplecza naukowego nie powstają optymalizacje dla nowoczesnych procesorów cpu? Czytałem na forum o różnicach w jakości obliczeń pomiędzy 32 a 64 bitowymi. Czy wogule jest szansa na przyspieszenie białkowców na 64 bitach. Poza tym, skoro już przy białkach jestem, to dlaczego nie używa się w tych projektach procesorów graficznych? Gpu przecież biją cpu na głowę, ale jakich obliczeń gpu przeprowadzić nie potrafi? Czy wogule można myśleć o napisaniu białkowych aplikacji na gpu? Wiele pisze się o ręcznym instalowaniu optymalizacji. Manager boinc przy instalacji zbiera podstawowe wiadomości o komputerze. Przy przyłączaniu się do projektu mógłby zwyczajnie pobierać najszybszą aplikację dla danego sprzętu. Taką, która maksymalnie wykorzystuje możliwości danej maszyny. Dlaczego większość aplikacji trzeba przyspieszać ręcznie?
Wiem, że moje pytania wydadzą się większości durne. Zdecydowałem się je zadać, ponieważ uważam, iż większym głupcem od tego, który nie wie, jest ten kto mądrego udaje.

[Troll81]

brak programistów GPU?

[AiDec]

Dlaczego tak mało projektów posiada optymalizacje? (...) Czemu, pomimo tak znacznego zaplecza naukowego nie powstają optymalizacje dla nowoczesnych procesorów cpu?

Dlatego ze nie w kazdym przypadku (nie dla kazdego projektu) sa one potrzebne/maja sens. Spora czesc optymalek zawiera instrukcje odwolujace sie do konkretnych procesorow (jak np. optymalki Enigmy dla Core Duo, czy PIII) badz do zestawow instrukcji (np. optymalizacja SSE3 dla projektu MilkyWay). Kazdy projekt jest inny, kazdy przetwarza inne dane. W przypadku niektorych projektow (badz podprojektow) optymalizacje np. pod konkretne procesory nie daja zauwazalnego (mierzalnego) przyspieszenia badz jedynie znikome (a pamietaj ze wklad pracy w pisanie optymalki jest calkiem spory, dodaj testowanie itp.), a zatem sens pisania optymalki jest czesto niewielki. Jesli zas chodzi o optymalizacje poprzez wykorzystanie konkretnych zestawow instrukcji (np. SSE2/SSE3) to w przypadku wielu projektow te `dodatkowe` instrukcje zupelnie maja sie nijak do danych przetwarzanych przez proca (SSE byly tworzone jako dodatki uzupelniajace podstawowe dzialania - co zatem jesli projekt takich dzialan nie podejmuje?). Jest jeszcze trzeci powod - w przypadku niejednego projektu ograniczeniem sa umiejetnosci admina. Przeciez nie kazdy `szef projektu` jest zarazem geniuszem programistycznym i sadze wielu woli (badz nie ma innego wyjscia...) zadowolic sie powolna ale calkowicie stabilna aplikacja, niz niestabilna i wysypujaca probki na wielu kompach optymalizacja.

Czy wynika to z charakteru obliczeń?

Bardzo czesto tak. Co nieco wyjasnilem juz powyzej.

Czy wogule jest szansa na przyspieszenie białkowców na 64 bitach.

I ponownie, co nieco napisalem powyzej. Z 64-ma bitami jest analogiczna sytuacja jak z dodatkowymi instrukcjami - po prostu nie zawsze jest sens stosowania czegos `dodatkowego`, skoro projekt z zalozenia wykonuje jedynie podstawowe operacje. O ile dobrze pamietam (choc moge sie mylic), TJM testowal 64-bity dla Enigmy (czy tez rozwazal uzycie 64 bitow...) i doszedl do wniosku ze po prostu nie ma to najmniejszego sensu.

Poza tym, skoro już przy białkach jestem, to dlaczego nie używa się w tych projektach procesorów graficznych? Gpu przecież biją cpu na głowę, ale jakich obliczeń gpu przeprowadzić nie potrafi?

Przede wszystkim brak jest programistow dla GPU. A szczegolnie doswiadczonych programistow GPU. Polecam lekture dzialu http://www.boincatpoland.org/smf/dnetchome/ , a zwlaszcza watku http://www.boincatpoland.org/smf/dnetchome/dnetc-net/ , gdzie sesef i OxyOne pisali nt. DNETC. Wiem, ze gdzies jeszcze byl watek o poczatkach programowania dla GPU (jak to sesef zaczynal - temat sprzed roku albo cos...), ale jakos nie moge znalezc - moze ktos inny poratuje.

Dodam tez, ze nie kazdy projekt nadaje sie na GPU (tutaj w gre wchodzi wlasnie kwestia co ma byc robione i z jakimi danymi). Wbrew pozorom GPU nie do wszystkiego super sie nadaje - pamietaj ze zamiast z jednym szybkim procesorem, musisz walczyc z np. ponad tysiacem wzglednie powolnych procesorow strumieniowych (masakra dla programisty od przetwarzania rownoleglego¹). Najlepszym przykladem jest projekt SETI, gdzie uzycie GPU jest (bedac uprzejmym) dyskusyjne.

Wiele pisze się o ręcznym instalowaniu optymalizacji. (...) Dlaczego większość aplikacji trzeba przyspieszać ręcznie?

Polecam Ci przeczytanie calego dzialu o Enigmie ( http://www.boincatpoland.org/smf/enigmahome-78/ ) - padlo tam wiele pytan  i znajdziesz wiele odpowiedzi (nie sposob tego strescic), miedzy innymi o ile dobrze pamietam (moge sie mylic) nt. automatycznego pobierania optymalizacji. Od siebie dodam dwie informacje - po pierwsze implementacja takiego automatu do rozdzielania optymalizacji  jest o ile mi wiadomo b. trudna (zwlaszcza jesli wezmiesz pod uwage ze co chwila powstaja nowe proce z nowymi architekturami, co wymagaloby czestych zmian w automacie, a przeciez kazda zmiana kodu takiego `automatu` wymaga kolejnych testow itp.), a po drugie optymalizacje nigdy nie sa tak stabilne jak glowna podstawowa aplikacja. Zatem lepiej by ktos, kto chce optymalizacje sam podjal decyzje o jej uzyciu, niz wciskac na sile nieperfekcyjna aplikacje uzytkownikom ktorzy moga byc zupelnymi laikami komputerowymi.



Mam nadzieje ze odpowiedzialem z grubsza na najwazniejsze pytania. Co do szczegolow polecam lekture dzialow o Enigmie, MilkyWay, DNETC i PrimeGrid (zwlaszcza o aplikacji AP26 !).





¹  

W obliczeniach równoległych, aby rozwiązać dany problem wykorzystuje się wiele jednostek obliczeniowych jednocześnie. Można tak postąpić dzieląc problem na mniejsze, niezależne części, z których jedna może być wykonywana niezależnie od pozostałych. Jeśli uda się przeprowadzić taki podział, każda z części może być wykonana na innej jednostce obliczeniowej w tym samym czasie co pozostałe

- a nie dla kazdego projektu taki podzial jest mozliwy i nie dla kazdego projektu taki podzial ma sens. Niejednokrotnie okazuje sie, ze po podziale na powiedzmy 500 strumieni, kazdy z nich jest liczony zupelnie rozna ilosc czasu (specyfika projektu, danych...). Moze sie zatem okazac ze co prawda 499 prockow jednego GPU zakonczylo prace po minucie, ale czekaja na ostatni procek (strumien) ktory sie liczy pol godziny, po to zeby moc zaczac kolejny, nowy cykl.

Zrodlo: Obliczenia zależne, niezależne i granica ich przyspieszania: http://pl.wikipedia.org/wiki/Obliczenia_r%C3%B3wnoleg%C5%82e#Obliczenia_zale.C5.BCne.2C_niezale.C5.BCne_i_granica_ich_przyspieszania




PS. Nie staralem sie udawac madrego  XP, zdecydowalem sie napisac to co wiem, poniewaz uwazam, ze lepiej jest wiedzies cos, niz nic  :arrr:

[Ufol]

Wielkie dzięki za odpowiedź. Rozjaśniłeś mrok w mojej łepetynie.

[Ufol]

Czyż bym złamał etykietę? Zauważyłem xp w odpowiedzi.
:-[
A tak na poważnie: Napisałem o gpu dla białkowców bo przecież PS3GRID-GPUGRID jakoś na gpu liczy. Czy wogule można jakoś porównywać liczenie na gpu i cpu. Z artykułu, który mi poleciłeś zrozumiałem, iż są to całkowicie odmienne typy obliczeń. O ile gpu może być bardzo pomocne, to nie jest ono przysłowiowym świętym gralem boinca.
Pewnych obliczeń procesor graficzny poprostu wykonać nie może i z tego powodu wiele projektów liczy i będzie liczyć wyłącznie na cpu.
Czy mój tok rozumowania jest poprawny?

[Troll81]

po prostu GPUGrid dostało mocne wsparcie developerskie od NV i dlatego udało im sie stworzyć odpowiednią aplikację. Ale app dla ATI nie idzie się doprosić a źródeł też nie ujawniają. Myslę że gdyby otworzyli źródła to zyskałoby wiele białkowców (WCG, Rosetta, simap itp) ale nie chcą i mają do tego prawo.

[lolek]

Z białkowców na pewno SIMAP ma aplikację x64 i daje ona niezłego kopa- szczególnie na Windowsie

EDIT: A co do GPU jako "grala" BOINC`a to zależy od tego o jakim konkretnie projekcie myślimy. Na pewno znacznie on pchnął do przyodu wiele projektów, a nawet pokusił bym się że większość. Projekty które można liczyć na GPU bardzo żadko są uruchamiane na CPU co sprawia że te procki mielą inne projekty.

[AiDec]

Czyż bym złamał etykietę? Zauważyłem xp w odpowiedzi.

Nie, to po prostu Twoje zdanie `iż większym głupcem od tego, który nie wie, jest ten kto mądrego udaje` skusilo mnie do napisania odpowiedzi `z jajem` :) (nie chcialem zeby bylo ze udaje madrego he he). Ja juz taki jestem ze nielatwo mi byc zawsze powaznym ;). A jezyk byl wystawiony z usmiechem :).

Czy wogule można jakoś porównywać liczenie na gpu i cpu. Z artykułu, który mi poleciłeś zrozumiałem, iż są to całkowicie odmienne typy obliczeń. O ile gpu może być bardzo pomocne, to nie jest ono przysłowiowym świętym gralem boinca.

Mozna jedynie w konkretnych przypadkach. I dlatego wlasnie ze sa to zupelnie rozne rodzaje obliczen.

Wlasnymi slowami: Na CPU liczysz szeregowo, cyklicznie, krok po kroku, gdzie kazde kolejne dzialanie moze ale nie musi byc zalezne od wyniku poprzedniego dzialania. I nie ma znaczenia co sie dzialo w poprzednim kroku, bo zaczynasz w nowym cyklu nowe dzialanie, ktore moze byc zupelnie innym dzialaniem. W przypadku obliczen rownoleglych, gdzie np. grafa 5870 ma 1800 procesorow strumieniowych, obliczenia sa prowadzone rownolegle na wszystkich `prockach` i WSZYSTKIE `proce` musza zakonczyc swoje dzialania, zanim bedzie mozna rozpoczac nowy cykl. Zatem moze sie zdazyc ze dzialanie wykonywane na zaledwie jednym z 1800 prockow opozni zakonczenie cyklu dla wszystkich pozostalych prockow o 30 minut - wtedy uzywanie GPU nie ma sensu. A czasami jest to nawet niemozliwe...

Pewnych obliczeń procesor graficzny poprostu wykonać nie może i z tego powodu wiele projektów liczy i będzie liczyć wyłącznie na cpu.

...bo moze sie zdazyc ze w niektorych przypadkach proces musi korzystac z calego zbioru danych, zatem nie da sie puscic rownolegle 1800 procesow, bo nie moga one wszystkie na raz przetwarzac tego samego zbioru danych¹ (moze tylko jeden). Jest jeszcze wiele powodow dla ktorych uzycie GPU moze nie byc mozliwe badz oplacalne, ja tylko staralem sie przedstawic probke problemu.





¹ Przyszlo mi do glowy jeszcze jedno porownanie. Jesli szukasz szkla kontaktowego zgubionego na 1m² dywanu, to czy zatrudnienie 1800 pomocnikow na tym 1m² bardzo Ci pomoze?  :D

[Waldi]

>AiDec

czytelnie to napisałeś - szacun.
warto pisać/uswiadamiać, że GPU nie jest GRALEM na wszystkie projekty.

[Filu]

Wieloprocesorowość symetryczna (Symmetric Multiprocessing) czasem jest lepszym rozwiązaniem niż GPU. ;)

Dzisiejsze obliczenia na GPU mają swoje ograniczenia:
nie może być częstych odwołań do pamięci,
logika algorytmów nie może być zbyt złożona, czyli bez pętli i instrukcji warunkowych
zbiory danych nie mogą być zależne od pozostałych danych lub ta zależność musi być znikoma