Aktualności:

Nowy polski projekt BOINC - Universe@Home

Menu główne

[Pomysł] Poradnik - Efektywne liczenie na GPU

Zaczęty przez AiDec, 23 Grudzień 2008, 10:19

AiDec

Poradnik dla wlascicieli kart Nvidia dla projektu GPUGrid:



Zalecane karty graficzne: wszystkie powyzej 8800GT
Zalecana przeze mnie minimalna karta graficzna: 9600 GT


Wersja BM zalecana przeze mnie: 6.11.7
Wersje BM calkowicie odradzane: 6.6.1 - 6.6.20 (http://www.gpugrid.net/forum_thread.php?id=1045)
Wersje dodatkowo odradzane przeze mnie: 6.6.21 - 6.6.35

Stery zalecane (!!!) przeze mnie:
Stery zalecane dla Linuksa: 185.xx, a jesli nie zadzialaja, to mozna probowac wyzszych niz 185.xx, badz tez 180.44, 180.60, lub 173.1420.

OS zalecany przeze mnie do GPUGrid: Jesli macie jedna grafe w kompie - W7x64/ew. Vistax64, a jesli wiecej niz jedna - Xp (ze wskazaniem na XPx64). Najlepszym systemem do GPUGrid jest Linux64, choc wiem ze niestety nie dla kazdego jest to dobry wybor. Pamietajcie aby w przypadku liczenia na wiecej niz jednej grafie w kompie wylaczyc SLi (nie dotyczy sterownikow 190.38). Ja zalecam dodatkowo wylaczenie PhysX na czas liczenia projektow CUDA (PhysX jest oparta o technologie CUDA, a zatem byloby lepiej aby grafa nie obslugiwala dwoch CUDA-softow na raz).


Gdyby ktos mial klopot z pobieraniem WU dla GPU to stosowac sie do ponizszych zalecen (a jesli ponizsze info nie pomoze, to prosze pisac w watku GPUGrid - http://www.boincatpoland.org/smf/gpugrid/gpugrid/):

1. Zresetowac projekt.
2. Po resecie (po np. 3-5 min w zaleznosci od szybkosci lacza) zatrzymac wszystkie projekty poza GPUGrid. Nie zatrzymywac pobierania, tylko zatrzymac PROJEKTY - czyli przetwarzanie WU :).
3. Aktualizacja GPUGrid az do skutku - nie przejmowac sie dziwnymi komunikatami.

Uwaga, wprowadzone zostaly WU roznej dlugosci! Serwer ma eksperymentalne oprogramowanie ktore `bedzie sie uczylo` (choc to moze za duzo napisane ;) ) kto i ile moze przeliczyc. Nalezy zatem zaciagnac probke, przeliczyc niezaleznie od wszystkiego (nawet po przekroczeniu deadline!), odeslac i zaraportowac. Serwer ma sie uczyc ze np. probka byla za dluga i przyznac krotsza :). Osobom ktore maja troszke wolnego czasu (i niestety powolne grafy) zalecam na poczatku sprawdzanie czasu przeliczania probek. Jezeli z gory wiadomo (musi byc wiadomo na 100%!) ze WU nie zmiesci sie w deadline - mozna od razu ja anulowac i zaciagac nastepna. Patrzcie na nazwy probek (nie znam wszystkich) - mozna po nazwach dojsc ktore sa dluzsze, a ktore krotsze.


I drobne przypomnienie dla `nowych` w GPUGrid:

This is performance guide of nVidia graphic cards on GPUGrid:
1. GeForce 280GTX: 25000 sec/WU
2. GeForce 260GTX: 28000 sec/WU
3. GeForce 9800GTX+: 44000 sec/WU
4. GeForce 9800GTX: 47000 sec/WU
5. GeForce 8800GTS512: 50000 sec/WU
6. GeForce 8800GT: 58000 sec/WU
7. GeForce 9600GT: 70000 sec/WU
8. GeForce 8800GS: 74000 sec/WU
This is estimated time (+/-2000 seconds ) of what you should expected from this cards when they operate at normal values. This data was taken from statistic of users who crunch. Although this comparison is not 100% correct due to different CPU, and RAM clocks, but this give some lights on GeForce performance.


BOINC GPU - Porownanie kart graficznych w GFLOPS`ach

Ponizsze naleza do grupy Compute Capability 1.1:

Nie uzywac do GPUGrid - nie zmieszcza sie w deadline!
GeForce 8400 GS PCI 256MB, est. 4GFLOPS
GeForce 8400 GS PCIe 256MB, est. 5GFLOPS
GeForce 8500 GT 512MB, est. 5GFLOPS
Quadro NVS 290 256MB, est. 5GFLOPS
GeForce 8600M GS 256MB, est. 5GFLOPS
GeForce 8600M GS 512MB, est. 6GFLOPS
Geforce 8500 GT, 512MB PCIe, 6GFLOPS

Nie zalecane do GPUGrid, chyba ze pracuja 24/7
GeForce 9600M GT 512MB, est. 14GFLOPS
GeForce 8600 GT 256MB, est. 14GFLOPS
GeForce 8600 GT 512MB, est. 15GFLOPS
GeForce 9500 GT 512MB, est. 15GFLOPS
GeForce 8600 GTS 256MB, est. 18GFLOPS

Entry Performance cards for GPUGrid
GeForce 9600 GT 512MB, est. 34GFLOPS
GeForce 9600 GT 512MB, est. 37GFLOPS
GeForce 8800 GTS, 640MB, est. 41GFLOPS [CC 1.0]
Geforce 9600 GSO, 768MB (DDR2) 46GFLOPS
Geforce 9600 GSO, 384MB (DDR3) 48GFLOPS

Average Performance Cards for GPUGrid
GeForce 8800 GT 512MB, est. 60GFLOPS
GeForce 8800 GTX 768MB, est. 62GFLOPS [CC 1.0]
GeForce 9800 GT 1024MB, est. 60GFLOPS

Good Performance Cards for GPUGrid
GeForce 8800 GTS 512MB, est. 77GFLOPS
GeForce 9800 GTX 512MB, est. 77GFLOPS
GeForce 9800 GTX+ 512MB, est. 84GFLOPS
GeForce GTX 250 1024MB, est. 84GFLOPS

Compute Capability 1.3 [wiekszosc]:

High End Performance Cards for GPUGrid
GeForce GTX 260 896MB (192sp), est. 85GFLOPS (120)
Tesla C1060 1024MB, est. 93GFLOPS (131)
GeForce GTX 260 896MB, est. 100GFLOPS (141)
GeForce GTX 275 896MB, est. 123GFLOPS (173)
GeForce GTX 285 1024MB, est. 127GFLOPS (179)
GeForce GTX 280 1024MB, est. 130GFLOPS (183)
GeForce 9800 GX2 512MB, est. 138GFLOPS [CC 1.1]
GeForce GTX 295 896MB, est. 212GFLOPS (299)

CC=Compute Capability

Cyfry w nawiasach oznaczaja efektywnosc w GFLOPS, po uwzglednieniu 41% zwiekszonej efektywnosci wynikajacej z zastosowania zaawansowanych zestawow instrukcji CC 1.3, zaimplementowanych w GT200/GT200b (wykorzystywanych oczywiscie przez GPUGrid).




Jesli ktos chce wiedziec wiecej nt. specyfikacji kart graficznych Nvidia, to polecam linka: http://en.wikipedia.org/wiki/Comparison_of_Nvidia_Graphics_Processing_Units


Powyzszy poradnik dla GPUGrid powstal dzieki wspolpracy z najbardziej zaangazowanym liczydlowym GPUGrid`a (obecnie juz testerem i moderatorem) ETA, ktoremu jestem bardzo wdzieczny za wielki wklad w ogolnie pojety rozwoj GPUGrid.





Efektywne liczenie jednoczesnie GPUGrid na GPU i innych projektow na CPU - rowniez dla `Milkowcow`



Wprowadzenie:

Ten temat jest dosc trudny do napisania z uzyciem jedynie `czystych formulek`. Bede sie tutaj mocno posilkowal przykladami, a wiele kwestii wyjasnie wlasnym jezykiem. Z poczatku moze sie to wydawac dosc chaotyczne, jednak w miare wolnego czasu postaram sie dopieszczac tekst, aby byl jak najbardziej zrozumialy. Uwaga, jesli wyraznie nie zaznacze ze jest inaczej, to wszystkie przyklady odnosza sie do XP32ProEngSP3. Zaznaczam tez, ze ponizsze przyklady w ok. 85% sa podawane na podstawie efektow testow, a w 15% na podstawie obliczen osob godnych zaufania.

Przeczytanie tej czesci poradnika zalecam rowniez Milkowcom, ktorym dzieki zebranym tutaj informacjom latwiej bedzie zrozumiec znacznie bardziej skomplikowane zagadnienie efektywnego liczenia Milki.


Kilka faktow i wspomnienie historii:

Zacznijmy od tego ze projekty dla GPU wykorzystuja procesor. To nie jest tak, ze projekt dla GPU chodzi tylko i wylacznie na GPU. Zawsze proc jest w mniejszym, badz wiekszym stopniu wykorzystywany. Czasami moze to byc 1% bo proc jedyne co robi to przesyla dane do grafy, a czasami moze to byc 50% jednego rdzenia bardzo, bardzo szybkiego procesora, np. jesli projekt wciaz wykonuje czesc obliczen na CPU. Wiele zalezy od szybkosci proca, szybkosci grafy, uzytego systemu operacyjnego, jak i od samego projektu. GPUGrid nalezy do tych projektow, ktore w najmniejszym mozliwym stopniu wykorzystuja procesor. Musze tutaj napisac ze programisci odwalili w tej kwestii naprawde kawal niesamowitej roboty - zejsc z 40% w przeciagu trzech miesiecy do srednio 1,5%! I w tej chwili czesc z Was moglaby juz przestac czytac dalej - myslicie po co sie zajmowac tak niewielkim problemem? Poltora procenta i walczyc o taki drobiazg? Mam nadzieje ze po dalszej czesci tekstu nie bedziecie zalowac poswieconego czasu.


Od czego zalezy stopien obciazenia procesora:

Kazda jednostka GPUGrida przetwarzana na grafie wykorzystuje procesor. I w pierwszej kolejnosci to od procesora zalezy w jak duzym stopniu jest obciazony - od jego szybkosci i architektury. Dla 260GTX: Q6600@2.4GHz (stock) bedzie wykorzytywany w 3%, Q6600@3.42GHz w 2%, QX9770@4.2GHz w 1%, a dla odmiany C2D T5450@1.66 (stock) - 8%, AthlonXP 1700+ stock 25-35%. Gdyby to byl 280 GTX i to po mocnym OC, to wymagalby od proca o wiele wiecej danych w tym samym czasie, a zatem byloby to: Q6600 stock - 5%, Q6600@3.42GHz - 3%, QX9770@4.2GHz - 2%, C2D T5450 (stock) - 15%, AthlonXP 1700+ stock 40-70%. A teraz drobny prztyczek: ilu z Was majac niezbyt szybka grafe i niezbyt szybkiego jedno-dwujajowego proca, odpalalo GPUGrida + jeden-dwa projekty na CPU + korzystalo w tym samym czasie z kompa do codziennego uzytku... ilu z Was narzekalo ze nie moze zdazyc do deadline`u?

XP

Dobra, jedziemy dalej. Stopien wykorzystania procesora zalezy rowniez w duzej mierze od systemu operacyjnego. Jesli dla Q6600 stock + Win32 bedzie to 5% to dla Lin32 bedzie to 2%, a dla Lin64 1%. Roznica na korzysc Linuksa jest tym wieksza, im wolniejszy (gorszy technologicznie) jest procesor. Dla przykladowego A XP1700+ bedzie to XP32 - 40%, Lin64 - 6%. (Ubuntu8.10AMD64 i Suse64). Tutaj musze mocno zaznaczyc, ze pod wzgledem obciazania proca GPUGridem, Linuks zawsze masakrowal Xp (obecnie bardzo duza przewage maja rowniez wszystkie systemy 64-bitowe). Juz w starych czasach (prawie rok temu) gdy obciazenie pod Win32+Q6600@3.42+280GTX wynosilo 40%, pod Lin64 bylo to 3%. Pomiedzy XP32 a XPx64 na starszych sterownikach nie ma mierzalnej roznicy w obciazaniu proca, jednak na najnowszych roznica jest ogromna. W ramach przykladu; po przeliczeniu jednej jednostki wykorzystanie proca pod XP32 wynioslo 40minut, a pod XPx64 15minut. Dodatkowo jest ok. 10% roznica w czasie przetwarzania WU na korzysc XPx64 (Linux64 zyskuje w stosunku do XP32 10-40% w zaleznosci od jednostki).

Obciazenie procesora zalezy rowniez od czegos, na co nie mamy wiekszego wplywu - od konkretnych jednostek. Niektore WU moga obciazac proca w 1%, a inne w 5%. Obecnie moj komp (QX9770@4.2GHz+XP32) liczy mi dwie jednostki z serii GIANNI i jedna z serii IBUCH. Jedna jednostka GIANNI obciaza kompa 1-1.5%, a druga non-stop jedynie 0.5%. A IBUCH bierze 2-4% he he. Generalnie jednostki IBUCH zabieraja do pieciu razy wiecej proca niz np. KASHIF, czy GIANNI.


Dlaczego te informacje sa wazne:

Dlatego ze chcac efektywnie liczyc na GPU, musicie zostawic grafie kawalek proca. I byloby dobrze gdybyscie wiedzieli ile tego proca pozostawic. Jesli nie dacie troche oddechu prockowi zeby mogl obslugiwac grafe, to automatycznie ja przydlawicie. Grafa nie bedzie chodzila na 100% (a np. na 50-60%, czyli najczesciej spotykany przypadek), bo proc nie nadazy przesylac danych. Jesli zas pozostawicie za duzo, badz pozostawicie niepotrzebnie kawalek proca, to stracicie na tym (w szczegolnych przypadkach nie ma sensu pozostawianie wolnych mocy przerobowych proca specjalnie dla GPUGrida).


Jak wykorzystac nabyta wiedze w praktyce:

Na przykladzie mojego `Kosmosa` (QX9770@4.2GHz + 3x 280GTX). Proc czterordzeniowy, zatem ustawiam wykorzystanie 75% rdzeni. Dzieki temu licze 3 projekty na CPU + 3 na GPU (ktore mi biora w sumie 5%). W efekcie GPUGrid dostaje dane natychmiast i nie musi czekac w kolejce, co w idealnych warunkach (jakbym nie mial wakacji i nie gral na kompie tylko siedzial po 12-16h w pracy he he he) skutkowaloby mi 3.000 pkt. z CPU + 70.000+ pkt. z GPU na dobe. Owszem, trace niewykorzystujac 20% mocy przerobowych proca. Ale jakbym ustawil 4xCPU + 3XGPU to nie dosc ze zdlawilbym GPUGrida z powodow obecnie juz ogolnie zrozumialych, ale co wiecej - zmusilbym proca do ciaglego przelaczania sie miedzy zadaniami, co spowodowaloby jeszcze wieksza strate wydajnosci (czesc z Was zapewne wie jak bardzo spada wydajnosc proca jesli notorycznie i blyskawicznie musi sie przelaczac miedzy zadaniami, gdzie kolejnych rzadan od kolejnych zadan nie da sie przewidziec - instruction prefetch w takich sytuacjach daje strate zamiast zysku!). Majac 4xCPU + 3xGPU mialbym dzienny utarg 3.500 + 40.000. Nieekonomiczne. Przyznaje, ze sa sytuacje w ktorych korzystam z takiej konfiguracji. Na przyklad wczorajszy wyscig. W ramach aktywnego udzialu w 24-godzinnym wyscigu wlaczylem wszystkie cztery jajka na PrimeGrid. Niech strace te 10k z GPUGrid (i tak mam tam sporo), byleby zyskac te 500 ekstra do wyscigu. I jakby to byl wyscig tygodniowy, to tez bym tak zrobil. Ale nie zrobie tego np. dla Projektu miesiaca.

Sa tez sposoby wykorzystania wolnych mocy przerobowych kompa, nieprzeszkadzajace GPUGridowi. Mam tutaj na mysli projekty non_cpu_intensive. Projekty takie jak AlmereGrid czy FreeHAL w zaledwie minimalnym stopniu wykorzystuja procesor (np. 1-3%), a zatem mozna sobie dodatkowo policzyc jakiegos Almera czy FreeHALa wykorzystujac wolne moce przerobowe proca  i dopchac go deczko (pod warunkiem ze macie dosc pamieci i odpowiednio szybkie HDD na takie operacje). Idealnym dla mnie rozwiazaniem bylo zawsze 3xCPU + 3xGPU + 20xAlmere + 10xFreeHAL. Obciazenie rdzeni wynosilo wtedy 98% 97% 98% 97%. Ideal - przy takim obciazeniu proc jeszcze chodzi na luzie i nie spowalnia GPUGrida (do 98% wlacznie, prefetch jeszcze dziala zgodnie z zalozeniami). Zaznaczam, ze projekty te polecam tylko i wylacznie zaawansowanym uzytkownikom komputerow, majacym juz spora wiedze nt. BOINC`a.

W niektorych przypadkach nie warto odciazac proca specjalnie dla grafy i GPUGrida. Jesli na przyklad Wasza 8800 majac `luzno` chodzacego proca Q6600 liczy WU GPUGrida 3 dni, to zapchajcie proca do fulla. Zamiast 3 dni bedzie to 3 i pol dnia - i tak zdazycie przed deadlinem. A ile za to ten jeden dodatkowy rdzen nachapie punktow? W tej kwestii postepujcie z rozwaga, bo z kolei majac powolny procesor (powiedzmy Athlon64 3000+) nie oplaca sie zapychac proca zadaniami na CPU, bo on i tak wiele punktow nie narobi. To juz niech lepiej kreci na grafie tego GPUGrida, bo lepiej na tym wyjdziecie.

Btw, przy wykorzystaniu systemow 64-bitowych (a zwlaszcza Linuksa 64bit), wzrasta szybkosc przetwarzania WU. Wzrost ten jest zalezny od Work Unitow i dla kazdego WU moze byc inny. Nie mam aktualnych danych (do aktualnie dostepnych WU), ale dla starszych serii wydajnosc przetwarzania wzrastala o 10-40%.


May the GeForce be with you young padawan ;)




Poradnik dla wlascicieli kart ATI dla projektu Milkyway:  


Poradnik dostepny jest na PM u OxyOne.







Pytania i odpowiedzi:



1. Milke da się poustawiać tak, aby na kliencie 6.10.18 liczył na wgranych opto tak jak na domyślnej aplikacji? tzn 4+1?


a). Przede wszystkim, optymalizacja zawiera dokladnie ta sama aplikacje liczaca, co aplikacja domyslnie sciagana z projektu przez BM. Zatem nie jest to stricte optymalizacja.

b). `Optymalizacja` rozni sie tym (od zwyklej app) ze zawiera plik konfiguracyjny, umozliwiajacy zmiane ustawien aplikacji liczacej (zmiane sposobu liczenia/obciazenia grafy itp.). Domyslne ustawienie `optymalizacji` jest identyczne z domyslna aplikacja, a zatem samo wgranie optymalizacji nic nie zmienia w sposobie liczenia.

c). Jesli cos zmieniliscie w konfigu, wystarczy ponownie wgrac (nadpisac) optymalizacje, dzieki czemu zostana przywrocone domysle ustawienia liczenia Milky.

d1). Za obciazenie procesora odpowiada linia <avg_ncpus>0.05</avg_ncpus>. Wartosc okresla jaka czesc jednego rdzenia ma zabrac sobie grafa na potrzeby liczenia Milky. Moze to byc 0,05 co bedzie skutkowalo na czterordzeniowcu liczeniem 4CPU+1GPU, mozna tez wpisac 1 w wyniku czego bedzie liczone 3CPU+1GPU, a cale jedno jajo zostanie przeznaczone na potrzeby grafy.

d2). Jesli macie grafe dwurdzeniowa (np. 4870x2), to wpisanie 1 na czterojajowcu bedzie skutkowalo liczeniem 2CPU+2GPU.






Od Autora:

Staralem sie opisywac przygotowanie komputerow do uzytkowania projektow dla GPU w sposob rzetelny i dokladny, jednak w zwiazku z wypiciem zaledwie dwoch piwow przed rozpoczeciem `Poradnika` i jedynie trzech kolejnych podczas tej katorzniczej pracy, nie jestem w stanie zagwarantowac ze powyzsze opisy sa wolne od bledow. W razie watpliwosci zachecam do kontaktu poprzez PM, badz osobistego przekazywania piwnych datkow na rzecz rozwoju poradnika  :arrr:.


Zastrzegam sobie rowniez prawo do edycji powyzszego poradnika w zaleznosci od humoru, pogody, swieta panstwowego czy tez religijnego (dowolnej, wybranej przeze mnie na chybil trafil religii), fazy ksiezyca, badz stanu upojenia alkoholowego itp.  %)






Plany rozwoju poradnika: Efektywne liczenie jednoczesnie MilkyWay na GPU i innych projektow na CPU i wykorzystanie klientow HAL`owych do liczenia jednoczesnie z MilkyWay.



Bo jest paru kumpli :),
Bo jest parę w życiu dobrych chwil...


Moja wizytowka i sygnaturka

matti_tm

Mili państwo, a czy koleżanki/koledzy liczący już od jakiegoś czasu na GPU mogliby zrobić jakowyś poradnik, tak od podstaw, jak włączyć liczenie na GPU? Chętnie co nieco zaprzęgnę, ale nie mam czasu i siły, żeby od zera szukać info.
Bo góry mogą ustąpić
i pagórki się zachwiać,
ale miłość moja nie odstąpi od ciebie
i nie zachwieje się moje przymierze pokoju,
mówi Pan, który ma litość nad tobą. (Iz 54,10)

Sprawdź:
www.koinoniagb.pl/
www.bialystok.koinoniagb.pl


Troll81

Padaj jaką masz kartę graficzną :D to pomożemy.

matti_tm

Ja mam dość starą kartę: Ati Radeon X550
Bo góry mogą ustąpić
i pagórki się zachwiać,
ale miłość moja nie odstąpi od ciebie
i nie zachwieje się moje przymierze pokoju,
mówi Pan, który ma litość nad tobą. (Iz 54,10)

Sprawdź:
www.koinoniagb.pl/
www.bialystok.koinoniagb.pl


sesef

#4
Cytat: matti_tm w 17 Lipiec 2009, 12:44
Ja mam dość starą kartę: Ati Radeon X550

Niestety ta karta się nie nadaje.

Tu jest spis wszystkich kart na których można liczyć

ATI: http://developer.amd.com/gpu/ATIStreamSDK/pages/ATIStreamSystemRequirements.aspx#cards i nie dodana jeszcze do listy karta 4730
NV: http://www.nvidia.com/object/cuda_learn_products.html

Do Collatz powinny nadawać się wszystkie, do milky tylko te które nie mają indeksu 2

Troll81

Jakiegoś taniego radka dokup :D i styknie :D

AiDec

Cytat: matti_tm w 15 Lipiec 2009, 15:34
Mili państwo, a czy koleżanki/koledzy liczący już od jakiegoś czasu na GPU mogliby zrobić jakowyś poradnik, tak od podstaw, jak włączyć liczenie na GPU? Chętnie co nieco zaprzęgnę, ale nie mam czasu i siły, żeby od zera szukać info.

Nie ma sposobu aby napisac taki typowy poradnik :(. Poradnik musialby uwzgledniac zbyt wiele kombinacji - wszystko zalezy od tego jaka karte graficzna masz, jakiego systemu operacyjnego uzywasz (i juz tutaj mamy mnogosc opcji...). A aktualizowanie takiego poradnika to juz by byla masakra (biorac pod uwage ze codziennie wychodza jakies nowe stery dla jakiegos systemu, ukazuja sie nowe aplikacje dla GPU...).

Ale gdybym chcial Ci najprosciej odpowiedziec, to napisalbym: `podepnij sie do projektu w ktorym Twoja grafa moze dzialac (ATI = MilkyWay, Nvidia = GPUGrid)`. I tyle :). Jak sie podepniesz i wszystko dziala ok, to super. A jesli sie podepniesz i cos nie dziala, to wtedy czytaj info w pierwszym poscie tego watku, poczytaj watki o przetwarzaniu na GPU (http://www.boincatpoland.org/smf/milkywayhome-113/optymalki-gpu-cpu-pod-milke/  i  http://www.boincatpoland.org/smf/gpugrid/). Jesli mimo takiej wiedzy jaka w tych watkach zebralismy nie uda Ci sie rozwiazac problemu, to pisz i pytaj w odpowiednich watkach.

Jednak wracajac `czysto` do Twojej wypowiedzi `Chętnie co nieco zaprzęgnę, ale nie mam czasu i siły, żeby od zera szukać info.`, to niestety ale bez pracy nie ma kolaczy. Bez obrazy oczywiscie, ale chcac cokolwiek zrobic w jakimkolwiek temacie, to trzeba sie uczyc. Nikt nie wie tak naprawde jaka jest konfiguracja Twojego komputera, jakie stery masz zainstalowane, jaki soft tam siedzi... Sam wiesz to najlepiej.



Bo jest paru kumpli :),
Bo jest parę w życiu dobrych chwil...


Moja wizytowka i sygnaturka

sesef

#7
Cytat: AiDec w 23 Grudzień 2008, 10:19Compute capability 1.3:

GeForce GTX 260 896MB (192sp), est. 85GFLOPS
Tesla C1060 1024MB, est. 93GFLOPS (only)?
GeForce GTX 260 896MB, est. 100GFLOPS
GeForce GTX 260 896MB, est. 104GFLOPS (OC)?
GeForce GTX 260 896MB, est. 111GFLOPS (OC)?
GeForce GTX 275 896MB, est. 123GFLOPS
GeForce GTX 285 1024MB, est. 127GFLOPS
GeForce GTX 280 1024MB, est. 130GFLOPS
GeForce GTX 295 896MB, est. 106GFLOPS (X2=212)?

To są dane z forum GPUGRID-a? bo trochę mnie dziwią te dane, 280 lepszy niż 285.

Wzór na wydajność GFlopsach przy double dla GF GTX jest taki 2x30xsharder clock co dla
280 daje 2x30x1.29=77,4 GFlops
285 daje 2x30x1.47=88.2 GFlops

GPUGRID cześć operacji może robi na single precision dlatego wydajność jest te 100+ GFlops, ale wtedy 285 nie ma prawa zanotować takich strat, żeby była słabsza ni 280.

Brawa za poradnik :)

Troll81

może prosta pomyłka się im zdarzyła??

OxyOne

Czekam na poradnik o ATI :fright:
Powyższy post wyraża jedynie opinię autora w dniu dzisiejszym. Nie może on służyć przeciwko niemu w dniu jutrzejszym, ani każdym innym następującym po tym terminie.

[/url]

Troll81

Może sam taki stwórz... :D

OxyOne

nie znam sie...
Powyższy post wyraża jedynie opinię autora w dniu dzisiejszym. Nie może on służyć przeciwko niemu w dniu jutrzejszym, ani każdym innym następującym po tym terminie.

[/url]

AiDec

Cytat: OxyOne w 20 Lipiec 2009, 16:27
nie znam sie...

Ja tez nie.


Cytat: sesef w 20 Lipiec 2009, 14:54
To są dane z forum GPUGRID-a? bo trochę mnie dziwią te dane, 280 lepszy niż 285.

Tak, te dane sa z GPUGrida. I faktycznie 285 jest wolniejsza od 280. Wolniejsza w znaczeniu `mniej wydajna`. Sprawdzalem. W wielu sklepach nawet podniesiono ceny 280-ek, zwazywszy ze zaczyna to byc towar deficytowy wypychany przez wolniejsze, choc nowoczesniejsze 285-ki. 285 ma co prawda wyzsze standardowe zegary (280@600MHz 285@648MHz), jednak okazala sie mniej wydajna konstrukcja (za to o wiele chlodniejsza), a ma to szczegolnie duze znaczenie dla OC - obie grafy mozna podciagnac do ponad 700MHz, przy ktorych 280-ka jest o blisko 20% szybsza.



Bo jest paru kumpli :),
Bo jest parę w życiu dobrych chwil...


Moja wizytowka i sygnaturka

sesef

Cytat: AiDec w 23 Grudzień 2008, 10:19
a) Zmodyfikowac wpis <flops>1.0e11</flops> tak, aby wartosc flops byla rowna GFlops`om double precision waszej grafy np:
dla 4870 <flops>1.2e11</flops>
dla 4870x2 <flops>2.4e11</flops>
dla dwoch 4870x2 <flops>4.8e11</flops>

Teraz dopiero zauważyłem pewną gafe powielaną już od jakiegoś czasu, 1.0e11 to jest 100 GFlops więc te liczby mają się nijak do działania, ba nawet nie wiem czy jakoś to jest używane ale jakbyśmy chcieli być dokładni to dla single precision powinno być:

dla 4870 <flops>1.2e12</flops>
dla 4870x2 <flops>2.4e12</flops>
dla dwoch 4870x2 <flops>4.8e12</flops>

dla double:

dla 4870 <flops>2.4e11</flops>
dla 4870x2 <flops>4.8e11</flops>
dla dwoch 4870x2 <flops>9.6e11</flops>

ale raczej wydajność powinna być tam podawana w single, dwa tzreaby sprawdzić czy zmiana tych liczb coś daje :)

AiDec

Tez to zauwazylem, podczas pisania poradnika - moje szczescie ze nie przepisywalem bezmyslnie, ale pisalem z glowy, wiec wlaczyl mi sie tryb myslenia :). Sam sie zaczalem zastanawiac po cholere taki wpis, skoro nijak sie ma do app. Mam ochote potestowac, ale nie dam rady tego zrobic w najblizszych tygodniach.

Dlatego pozostawilem to tak jak jest, skoro do tej pory dzialalo, to na chwile obecna (do czasu potwierdzenia ze jakiekolwiek inne rozwiazanie jest lepsze), zdecydowalem sie pozostac przy tym co jest. Jest i dziala.



Bo jest paru kumpli :),
Bo jest parę w życiu dobrych chwil...


Moja wizytowka i sygnaturka

matti_tm

Cytat: Troll81 w 17 Lipiec 2009, 14:01
Jakiegoś taniego radka dokup :D i styknie :D

Wstyd się przyznać, ale to firmowy sprzęt... tylko ćśśśśśś.....

A poradnik na samej górze - genialne... Gratuluję!
Bo góry mogą ustąpić
i pagórki się zachwiać,
ale miłość moja nie odstąpi od ciebie
i nie zachwieje się moje przymierze pokoju,
mówi Pan, który ma litość nad tobą. (Iz 54,10)

Sprawdź:
www.koinoniagb.pl/
www.bialystok.koinoniagb.pl


AiDec

#16
Zmodyfikowano w poradniku:


BOINC GPU - Porownanie kart graficznych w GFLOPS`ach

Ponizsze naleza do grupy Compute Capability 1.1:

Nie uzywac do GPUGrid - nie zmieszcza sie w deadline!
GeForce 8400 GS PCI 256MB, est. 4GFLOPS
GeForce 8400 GS PCIe 256MB, est. 5GFLOPS
GeForce 8500 GT 512MB, est. 5GFLOPS
Quadro NVS 290 256MB, est. 5GFLOPS
GeForce 8600M GS 256MB, est. 5GFLOPS
GeForce 8600M GS 512MB, est. 6GFLOPS
Geforce 8500 GT, 512MB PCIe, 6GFLOPS

Nie zalecane do GPUGrid, chyba ze pracuja 24/7
GeForce 9600M GT 512MB, est. 14GFLOPS
GeForce 8600 GT 256MB, est. 14GFLOPS
GeForce 8600 GT 512MB, est. 15GFLOPS
GeForce 9500 GT 512MB, est. 15GFLOPS
GeForce 8600 GTS 256MB, est. 18GFLOPS

Entry Performance cards for GPUGrid
GeForce 9600 GT 512MB, est. 34GFLOPS
GeForce 9600 GT 512MB, est. 37GFLOPS
GeForce 8800 GTS, 640MB, est. 41GFLOPS [CC 1.0]
Geforce 9600 GSO, 768MB (DDR2) 46GFLOPS
Geforce 9600 GSO, 384MB (DDR3) 48GFLOPS

Average Performance Cards for GPUGrid
GeForce 8800 GT 512MB, est. 60GFLOPS
GeForce 8800 GTX 768MB, est. 62GFLOPS [CC 1.0]
GeForce 9800 GT 1024MB, est. 60GFLOPS

Good Performance Cards for GPUGrid
GeForce 8800 GTS 512MB, est. 77GFLOPS
GeForce 9800 GTX 512MB, est. 77GFLOPS
GeForce 9800 GTX+ 512MB, est. 84GFLOPS
GeForce GTX 250 1024MB, est. 84GFLOPS

Compute Capability 1.3 [wiekszosc]:

High End Performance Cards for GPUGrid
GeForce GTX 260 896MB (192sp), est. 85GFLOPS (120)
Tesla C1060 1024MB, est. 93GFLOPS (131)
GeForce GTX 260 896MB, est. 100GFLOPS (141)
GeForce GTX 275 896MB, est. 123GFLOPS (173)
GeForce GTX 285 1024MB, est. 127GFLOPS (179)
GeForce GTX 280 1024MB, est. 130GFLOPS (183)
GeForce 9800 GX2 512MB, est. 138GFLOPS [CC 1.1]
GeForce GTX 295 896MB, est. 212GFLOPS (299)

CC=Compute Capability

Cyfry w nawiasach oznaczaja efektywnosc w GFLOPS, po uwzglednieniu 41% zwiekszonej efektywnosci wynikajacej z zastosowania zaawansowanych zestawow instrukcji CC 1.3, zaimplementowanych w GT200/GT200b (wykorzystywanych oczywiscie przez GPUGrid).



Bo jest paru kumpli :),
Bo jest parę w życiu dobrych chwil...


Moja wizytowka i sygnaturka

AiDec

Poradnik zaktualizowano o:

Efektywne liczenie jednoczesnie GPUGrid na GPU i innych projektow na CPU



Bo jest paru kumpli :),
Bo jest parę w życiu dobrych chwil...


Moja wizytowka i sygnaturka

sesef

cena 4770 wróciła w miarę do normalnego poziomu. W esc.pl kosztuje 439-449 zł co już jest w miarę rozsądną ceną, mam nadzieje, że jak będę teraz przez tydzień na wakacjach to mi to nie podrożeje i będę mógł sobie kupić ją bez problemów za 2 tyg. Jest to w tej chwili najlepsza oferta dla mniej zamożnych i do tego nie trzeba jakiegoś super zasilacza bo karta ciągnie tylko 80W więc do kompów ze słabszym zasilaczem też się nada, markowa 400-450 powinna spokojnie starczyć.

X X X

#19
Jeden drobiazg: "Towar niedostępny / Termin dostawy nieznany"  XD

Polecam świetne narzędzie do porównywania kart graficznych:
http://www.benchmark.pl/zestawienie_gpu.html

4850 = 1000 GFlops = 343,44n = 34 grosze za GFlopsa
4770 = _960 GFlops = 359,84n = 37 grosze za GFlopsa

4850 najtańszą kartą!  :book:

sesef

Cytat: Zawecki w 25 Lipiec 2009, 22:28
Jeden drobiazg: "Towar niedostępny / Termin dostawy nieznany"  XD

Polecam świetne narzędzie do porównywania kart graficznych:
http://www.benchmark.pl/zestawienie_gpu.html

4850 = 1000 GFlops = 343,44n = 34 grosze za GFlopsa
4770 = _960 GFlops = 359,84n = 37 grosze za GFlopsa

4850 najtańszą kartą!  :book:

Policz sobie 4850 VAPOR-X (ta karta jest podobnie cicha jak ta 4770) bo referencyjny 4850 jest owszem troszeczkę tańszy, ale sporo głośniejszy i te 50W prądu więcej bierze niż 4770.

X X X

1. Z tym hałasem to chyba tak nie do końca, bowiem benchmarki twierdzą, że ciszej jest póki nie ma większego obciążenia w 3D. Czy nasze obliczenia to "3D"?  :-\
http://www.benchmark.pl/testy_i_recenzje/W_duecie_czy_w_pojedynke._CrossFire_z_dwoch_Radeonow_4770-1918/strona/5283.html

2. Z porównaniem ceny 4770 jest pewien kłopot, bo wciąż jest to słabo dostępna karta, a różnice wykonania/ chłodzenia są znaczące. Z tego co zebrałem:
302,46 zł    0,338    R4730   896 GFlops
359,84 zł    0,375    R4770   960
343,44 zł    0,343    R4850  1000
441,80 zł    0,368    R4870  1200

3. Dzięki, że zwróciłeś uwagę na pobór W. Wg danych jakie znalazłem jest tak:
R4770  _960  _80W   12,0 MFlops/W
R4850  1000  110W   _9,1 MFlops/W !!!

Zatem do mojego nowego kompa wybieram teraz jednego R4770, a na gwiazdkę drugiego. To chyba najlepszy wybór?
2x80W= 160W da 1920 GFlopsów a 160W R4870 daje ledwie 1200!  :book:

sesef

Cytat: Zawecki w 26 Lipiec 2009, 00:04
1. Z tym hałasem to chyba tak nie do końca, bowiem benchmarki twierdzą, że ciszej jest póki nie ma większego obciążenia w 3D. Czy nasze obliczenia to "3D"?  :-\
http://www.benchmark.pl/testy_i_recenzje/W_duecie_czy_w_pojedynke._CrossFire_z_dwoch_Radeonow_4770-1918/strona/5283.html

U nas jest gorzej niż w "3D", bo chodzi 3D i to na 100% Projekty wykorzystują tylko jednostki SP i to praktycznie przez cały czas na 100% natomiast gry mają jeszcze do dyspozycji ROP i TMU więc to obciążenie się rozkłada no i gry z reguły nie potrzebują non stop 100%. W dużym przybliżeniu odpalenie projektu to jak odpalenie jakiegoś Crysiss-a czy STALKER-a tylko tak np przez pół dnia. Oxy liczy prawie 24/7 więc kompa wystawił na balkon bo te 2x 4870x2 nieźle potrafią pobeczeć. Miałem brać 4850 Vapor-x ze względu na cisze, ale obecnie wezmę 4770 bo i ciszej i pobór mniejszy a 40 nm to też źle się kręcić nie będzie. Podniosę leciutko takty i mam już wydajność referencyjnego 4850.

X X X

No dobra, po ostatnim wyścigu i moich słabych wynikach, postanowiłem nabyć nowego kompa ściśle sprofilowanego do liczenia na konto naszego zespołu i uczestniczenia w wyścigach. Doradźcie, czy moja koncepcja konfiguracji jest słuszna. Chciałbym być gotów na następny wyścig i wejść do pierwszej 100 teamu!
:attack:

1. AMD Phenom Quad-Core 9650 2,3GHz/95W + RAM 4 GB

2a. ATI R4770 (960GFlp, 80W)
2b. na gwiazdkę druga taka sama lub ciut lepsza (spadek cen)

3. HD na 3 partycje/systemy:
a) Win XPH (32)- do pracy na dziś
b) Win 7 (64)- do pracy na przyszłość
c) "NEMO"

Jako Nemo widziałbym przygotowany przez guru teamu wariant jakiegoś systemu operacyjnego, który na czas wyścigu pozwoliłby uzyskać maksymalne rezultaty - pewnie byłaby to jakaś wersja Linuxa, ale w życiu żadnej nie widziałem, więc czekam na propozycje. Uważam, że taki teamowy pakiet systemowy mógłby być wykorzystywany do pracy "nocnej". Przykładowo, wychodzimy z biura do domu, to odpalamy tego NEMO, wyłączamy monitor i niech sobie liczy dla dobra ludzkości i naszego teamu. Rano robimy restart i znów wszystko jest jak dawniej, a punkciki przyzwoicie przyrosły.

Nie mam doświadczenia w BOINCu a na kartach graficznych nie znam się zupełnie, więc proszę, dajcie znać, czy ta konfiguracja będzie optymalnie naliczać? Do potrzeb własnych (Excel+WWW) potrzebuję jedno core, reszta (3 CPU+1 GPU) niech kręci dla "sprawy".
8)

Troll81

#24
http://www.youtube.com/watch?v=14njUwJUg1I filmik proszę :D

X X X

Cytat: sesef w 20 Lipiec 2009, 14:54trochę mnie dziwią te dane, 280 lepszy niż 285
Ostatnio analizowałem ofertę NV i zwróciłem uwagę, że 280 ma pobór 236W a 285 "tylko" 204W i pewnie stąd jest ta różnica.

Niezależnie od tego, po analizie, "obraziłem" się na NV i pozostanę wierny ATI - ta firma bardziej dba o moją kieszeń i trzeba te starania odwzajemnić jej. W zakupie i eksploatacji 2xATI = 1xNV. W związku z tym wyrzucam wszystkie projekty wspomagające NV, a olewające ATI, czyli: GPUGrid, SETI i Lattice.
>:(

Troll81

:D

Jak już zakończycie pisanie poradnika to wrzućcie go w formie arta na WIKI :D

sesef

#27
Cytat: 7NBI_Zarecki Robert w 07 Sierpień 2009, 10:49
Cytat: sesef w 20 Lipiec 2009, 14:54trochę mnie dziwią te dane, 280 lepszy niż 285
Ostatnio analizowałem ofertę NV i zwróciłem uwagę, że 280 ma pobór 236W a 285 "tylko" 204W i pewnie stąd jest ta różnica.

280 65nm
285 55nm

Co do poradnika, do oficjalnych sterów zalecam dodanie wersji 9.7 liczy wyraźnie szybciej, tylko od razu na wstępie trzeba zmienić avg_cpu na jakieś wyższe przy standardowym 0.1 sterowniki się sypia. Stery 9.7 nadają się do pojedynczej karty oraz z tego co Raptor pisał działają na 2x4890. Do 2x4870x2 nie polecam bo jak na razie nie udało się wyciągnąć pełni mocy.

X X X

No i 9.7 z R4770 w Win7u/64 też się wysypują - póki co zostaje 9.5.

sesef

#29
Cytat: 7NBI_Zarecki Robert w 07 Sierpień 2009, 11:21
No i 9.7 z R4770 w Win7u/64 też się wysypują - póki co zostaje 9.5.

Sprawdzałeś z wyższym avg_cpu? na 0.7 0.8 1.0? Mi na win7 x64 sterownik sypie się w 1 miejscu jak próbuje wejść do CCC, dlatego wywaliłem to w ciortu i używam RivaTuner. I oczywiście przed instalacja 9.7 trzeba odinstalować 9.5 + reset kompa bo nakładanie sterów często kończy się nie ciekawie.

Przy instalacji 9.7 koniecznie wywalić wpierw stare stery zrobić reset kompa i dopiero instalować 9.7

Jak stery są zainstalowane poprawnie to mamy coś takiego: CAL Runtime: 1.4.344

AiDec

Cytat: Troll81 w 07 Sierpień 2009, 10:57
:D

Jak już zakończycie pisanie poradnika to wrzućcie go w formie arta na WIKI :D

Jak zakoncze, to moge dac Ci znac i mozesz wrzucac.

1. Ja tego nie zrobie bo sie na tym nie znam i nie zamierzam tracic czasu na nauke kolejnej technologii, skoro dotychczasowa sie sprawdza.
2. Poradnik nigdy sie nie skonczy - bedzie juz zawsze koniecznosc ciaglej aktualizacji danych i rozbudowy poradnika.


Cytat: sesef w 07 Sierpień 2009, 11:13
Co do poradnika, do oficjalnych sterów zalecam dodanie wersji 9.7 (...)

Dzieki za wartosciowe info :). Zrobie to tak szybko, jak tylko bede mial czas, obecnie goszcze u siebie rodzicow, brata i siostre z rodzina, a z niektorymi z Nich nie widzialem sie kilka lat. Prosze o cierpliwosc.



Bo jest paru kumpli :),
Bo jest parę w życiu dobrych chwil...


Moja wizytowka i sygnaturka

X X X

Cytat: sesef w 07 Sierpień 2009, 11:25
Sprawdzałeś z wyższym avg_cpu? na 0.7 0.8 1.0? Mi na win7 x64 sterownik sypie się w 1 miejscu jak próbuje wejść do CCC, dlatego wywaliłem to w ciortu i używam RivaTuner. I oczywiście przed instalacja 9.7 trzeba odinstalować 9.5 + reset kompa bo nakładanie sterów często kończy się nie ciekawie.
Przy instalacji 9.7 koniecznie wywalić wpierw stare stery zrobić reset kompa i dopiero instalować 9.7
Jak stery są zainstalowane poprawnie to mamy coś takiego: CAL Runtime: 1.4.344
1. Sterów starych nie wywalałem, bo żadnych wcześniejszych nie miałem.

2. Podnosząc avg_cpu najpierw dochodzę do n=1, a później muszę zająć kolejne CPU...

Chwilowo Win7 nie uwiódł mnie, a aplikacje 64b są rzadkością. Dodatkowo dochodzą kłopoty ze współpracą z routerami, więc pewnie dziś spróbuję zainstalować pierwszego w życiu Linuksa. Oba systemu są dla mnie równie "nieprzyjazne", więc co za różnica. Jak i Linuks mnie nie przekona, to powrócę do wspaniałego WinXP i będzie spokój. Wszystko będzie chodzić i już.

Troll81

polecam XP64bit :D mam i chwalę sobie :D

sesef

Cytat: Troll81 w 07 Sierpień 2009, 21:20
polecam XP64bit :D mam i chwalę sobie :D

Broń Boże od tego systemu to już wole Viste, albo Server 2003/2005/2008.

Troll81

ja mam i nie narzekam :D wsio mi hula :D gry filmy net. nawet specjalnego problemu ze sterownikami nie miałem... W przeciwieństwie do wiśty...

AiDec

Cytat: Troll81 w 08 Sierpień 2009, 00:51
ja mam i nie narzekam :D wsio mi hula :D gry filmy net. nawet specjalnego problemu ze sterownikami nie miałem... W przeciwieństwie do wiśty...

Ja tez potwierdzam ze wole XPx64 niz zViste czy Wzjeben. XPx64 byl po protu o wiele, wiele lepszy, stabilniejszy, mniej klopotliwy w obsludze. Szkoda ze nie jest wspierany jak nalezy. No ale skoro mamy producentow idiotow latwo poddajacych sie naciskom ze strony M$... Za duzo matolow na swiecie :(.



Bo jest paru kumpli :),
Bo jest parę w życiu dobrych chwil...


Moja wizytowka i sygnaturka

X X X

Mam pytanie "poradnikowe" w sprawie kart ATI. Tutaj http://techreport.com/articles.x/16820/4 jest ciekawe porównanie wydajności kart NV i ATI. Dla singli zestawienie jest kompletne, ale dla double dane dotyczą tylko NV. Niestety wcześniej w tym wątku przytaczane dane nie obejmują "mojej" 4770.

W sumie nie do końca jestem przekonany czy podawać w app tę wydajność czy też nie, ale z biegiem czasu pewnie będzie do czegoś potrzebna. Po podstawieniu danych do przytoczonego wzoru (640/ 320) * (1+((750 - 668)/668)) uzyskuję... 2.25. Dla 4850 otrzymuję 2,34. Czy to oznacza, że w double 4850 ma 200 GFlopsów a 4770 192,3 GFlopsa? Czy tak mam to interpretować?
W efekcie zalecenia dotyczące flopsów różnią się o parę rzędów wielkości - ma tam być wydajność w singlach czy doublach? A nawet w singlach to byłoby chyba 1.0e9?

Proszę biegłych obliczeniowców o rozjaśnienie tych kwestii.

AiDec

Poradnik zaktualizowano o uwagi `OOSsf - spolka z nieograniczona nieodpowiedzialnoscia` XP, oraz przygotowanie sterow do Milky dla XPx64.



Bo jest paru kumpli :),
Bo jest parę w życiu dobrych chwil...


Moja wizytowka i sygnaturka

OxyOne

#38
Podaje nowe wiesci.

OOSsf - zrobili wałka (przez przypadek o ok 2 w nocy- zmeczenie materiału) na sterownikach. Przyspieszenie ładowania do GPU oraz samo liczenie - zwrost o ok 10%.

System Vista64bit, HD4870x2

Instalujemy albo zostawiamy stery 9.5 tylko wrzucamy do System32 i SysWOW64 pliki ati(amd)cal*.dll z serii 9.7
Tak proste i tak głupie ze nikt nie wpadł na taki pomysł...
http://www.speedyshare.com/538283471.html  stery 9.7

co do ustawien app_info musicie poczekac albo sami dzialac, narazie testujemy...

Powyższy post wyraża jedynie opinię autora w dniu dzisiejszym. Nie może on służyć przeciwko niemu w dniu jutrzejszym, ani każdym innym następującym po tym terminie.

[/url]

TRZECIAK

Właśnie przed chwilą patrzyłem na Twoje czasy przeliczania próbek i się zastanawiałem skąd jest ok 7 sek różnicy do momentu aż zlukałem CAL Runtime: 1.4.344 (stery 9,7).
Jutro i ja potestuję  :), bo przy ostatniej podmianie coś mi nie chciało to działać na BOINC 6.5.0 Crunch3ra.