BOINC@Poland

https://www.google.pl/search?q=quantum&um=1&ie=UTF-8&hl=pl&tbm=isch&source=og&sa=N&tab=wi&ei=holXUJWLCYzLsgaN-oG4BQ&biw=941&bih=523&sei=iYlXUPvhGsTGswaXx4CIAw

Słowo kluczowe: quantum

Tak powinno być lepiej.


(ale ze wzorami też możesz się zapoznać to może coś innego Ci wpadnie do głowy)

Coś nie wszystkim wykrywa platformę.

http://oproject.goldbach.pl/forum_thread.php?id=27

Możesz tam napisac co jest nie tak?

A teraz jak?

Cytat: matszpk w 14 Wrzesień 2012, 15:53
cześć. dodałem projekt na moim telefonie (Android) i okazało się, że nie wspiera jego platformy :(. NativeBOINC ma dwie nazwy platformy:
arm-android i arm-android-linux-gnu. To tak dla informacji. Jeśli możesz popraw na serwerze konfigurację platform dla Android.
dzięki.

Mój błąd. Myślałem, że obejdzie się jako platforma LInux na ARM. Teraz poprawione. Działa?

Składam zamówienie na odznaki do Shora  :attack:

Kto zrealizuje je?

(odznaki o takich samych nazwach i takiej samej ilości jak do GSCE)

Tylko tego brakowało do szczęścia  :deadman:

Jeszcze ktoś pomyśli, że to wirusy wchodzą  XD

Dodano staty w profilu:

http://oproject.goldbach.pl/show_user.php?userid=1921

Jak będe wyglądały po przeskalowaniu?

Zmniejszyłem sobie je w przeglądarce ale efekt taki sobie.

Mozna wyciagac dane w następujący sposób:

oznaczenia:

mode=user // dane dla usera
mode=host // dane dla hosta

id=x // id usera lub hosta
app_id=y // id aplikacji dla ktorej chcemy dane zassac

Przykład dla hosta o id 690 i app id 3:

http://atom.goldbach.pl/oproject_stats.php?mode=host&id=690&app_id=3

Przykłądowe dane zwrócone:

Cytat4209.89907027856 482014.87000000005 529592.3190759998 26

Oznaczają odpowiednio:

Cytat[credits] [CPU Time] [Elapsed Time] [Returned sucess result]

Będą statystyki uwzględniające:

ilośc odesłanych wyników z sukcesem
elapsed time
cpu time

Podział z uwzględnieniem konkretnych aplikacji, hostów i userów.

Może nawet dzisiaj udostepnie instrukcje jak będzie można przez www pobierać dane (ze skryptu).

Może ktoś zaproponuje jakieś progi do odznak i zrobi przykładowe wersje dla GSCE-SV?

Cytat: ReallyGrid w 13 Wrzesień 2012, 11:06
Po pierwsze: próbki przeliczają się nie wykorzystując nawet 1% mocy obliczeniowej procka. Mogę mieć jednocześnie 4 przeliczane inne WU, które zajmują po 100% mocy/rdzeń i jeszcze 2 WU z tego projektu.

Powinny być do zadania non-CPU i dlatego tak jest.

Cytat: ReallyGrid w 13 Wrzesień 2012, 11:06
Po drugie: Mam wyłączoną możliwość pobierania nowych danych w BOINC Managerze a mimo to po odesłaniu przeliczonej WU pobiera się kolejna. Odesłałem WU pre-2-44719_0 i zaraz po tym zaczęła się przeliczać próbka pre-2-45005_0, której wcześniej nie miałem na liście zadań.

To bug serwera boinc.

Cytat: ReallyGrid w 13 Wrzesień 2012, 11:06
Po trzecie: Odsyłane WU mają po 1B (słownie: jeden bajt).

To normalne.

Nie wiem czy takie karty (7970) mają dużą opłacalność GFLOPS/W. Raczej najlepiej tutaj błyszczy z tego co pamiętam 7770, która w FP ma aż 1280 GFLOPS.

Nie mam pojęcia czemu tych 5 WU się zatrzymało. Wszystkie inne idą ok. Coś wymyślimy.

To globalny problem. Już powinno być ok, ale zobaczymy przez najbliższe 48 godzin czy nie wysypie się. Mam pewne problemy  %)

Sprawdziłem. Coś jednak jest nie tak mi się wydaje.

Nie wiem czy prawidłowo jest procesor CELL wykrywany. Mam co do tego wątpliwości.

Moje środowisko widzi go tak:


[root@cell1 samples]# ./benchmark_ocl
====================================================================
OLib Benchmark.
Written by Lukasz Swierczewski <luk.swierczewski@gmail.com>.
Version: OpenCL
Compile date: Aug 17 2012
Compile time: 03:05:39
Architecture: Unknown
====================================================================

--- 1 OpenCL platform(s) found: -----------------------------------------
  -- 0 --
  PROFILE = FULL_PROFILE
  VERSION = OpenCL 1.1 BUILD 201103161830
  NAME = IBM
  VENDOR = IBM
  EXTENSIONS =
--- 1 OpenCL device(s) found on platform: -----------------------------------------

  ------------------- 0 -------------------
  DEVICE_NAME = CPU Cell Broadband Engine, altivec supported 32bit
  DEVICE_VENDOR = IBM
  DEVICE_VERSION = OpenCL 1.1 BUILD 201103161830
  DRIVER_VERSION = 0.3
  CL_DEVICE_EXTENSIONS = cl_khr_byte_addressable_store cl_ext_device_fission cl_ext_migrate_memobject cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics
  DEVICE_MAX_COMPUTE_UNITS = 4
  DEVICE_MAX_CLOCK_FREQUENCY = 3200
  DEVICE_GLOBAL_MEM_SIZE = 2594177024
  CL_DEVICE_GLOBAL_MEM_CACHE_SIZE = 32768
  CL_DEVICE_GLOBAL_MEM_CACHELINE_SIZE = 128
  CL_DEVICE_LOCAL_MEM_SIZE = 524288
  CL_DEVICE_MAX_MEM_ALLOC_SIZE = 1297088512
  CL_DEVICE_MAX_MEM_ALLOC_SIZE = 1297088512

Enter the device number:
>> 0


Kody zasadniczo się nie uruchamiają. Pomimo, że te same źródła z repozytorium odpalają się na kartach nVidii i AMD to na IBM CELL wywala niestety CL_INVALID_KERNEL_ARGS.

Nie mam pojęcia gdzie tam może być błąd skoro to na wszelkich kartach działa.

A jako IBM ID co podać? Bo mi coś mojego nie chce łykać.

Jest problem.

Potrzebuję pliku OpenCL Development Kit ISO image: OpenCL-0.3.linux.ppc.iso

Jest on według informacji IBM dotępny pod adresem: http://www.alphaworks.ibm.com/tech/opencl/download

Ja jednak tam niczego nie widzę. Jest opcja zalogowania się i zapewne czegoś pobrania. Nie mam jednak konta. Do rejestracji wymagany jakiś IBM ID. Ktoś może pomóc?

BOINC@Poland trzyma się na prowadzeniu ;)

Z informacji jakie posiadam wynika, że nie jest to demon  %)

Cytat: Tomasz R. Gwiazda w 12 Sierpień 2012, 18:32
slowo goldbach w nazwie projektu mowi wg. mnie wszystko

Goldbach to tylko domena xD

A ciężko dobrać kategorię:

oproject.info

Opis projektu OProject na wiki

Podejście z innej strony: Kto ma procesor AMD pod Linuxem w jakiejś maszynce działającej 24/365?

Cytat: RAD-Poland w 09 Sierpień 2012, 18:49
? - może lepiej nie uruchamiać bo coś ...

Może nie oddać sterowania do podsystemu graficznego  :attack: Nie ma po co ryzykować stabilności jak nie trzeba.

Rew. 37.

Można sprawdzić:

benchmark_ocl
burner_ocl (może nie uruchamiać)

A teraz komplacja przechodzi? (Rewizja 36)

Eh. Właśnie widzę, że make źle poprawiłem. Kaszanę niezłą zrobiłem. Potem to poprawię (za kilka godzin jak wrócę) - teraz już nie dam rady.

W repozytorium jest już plik do testów 'shor_algorithm_tester.sh' ale wkradł się tam drobny problem, którego w repo poprawionego nie ma.

Odpaliłem testy u siebie na Tesli C2050 aby wiedzieć ile mogą się one na oko wykonywać na innych kartach.

Pod wieczór napiszę dokładniej co z tego wychodzi.

Można także pobrać rewizję 34 w której problem kompilacji na AMD chyba jest poprawiony.

Może na początek skompiluj shor_algorithm_ocl_float

Do linijki numer 198 w pliku makefile dodaj po spacji -I/opt/AMDAPP/include

i potem normalnie

make shor_algorithm_ocl_float

Tak. Bedzie tworzył pliki tymczasowe. Nie powinien jednak zaliczyć zwiechy - ograniczymy się do typu float, a na nim wszystko ładnie działa  :attack:

Jutro stworzę skrypcik do testowania. Ile czasu GPU dasz radę wyłuskać?  :attack:

A benchmark?

Cytat: RAD-Poland w 08 Sierpień 2012, 21:42
EDIT benchmarka nie puszczałem -> jesteś pewien ?

Nie  :deadman:

Ale tylko w jeden sposób można się przekonać. Jednak zapodaj go jak nie będziesz niczego na PC robić  :attack:

Cytat: RAD-Poland w 08 Sierpień 2012, 21:24

Kod [Zaznacz] Rozwiń

bash-4.2$ ulimit -s unlimited
bash-4.2$ ./shor_algorithm_ocl_float
0 1 6 1.98 1.19 0
:)

I gites. Tak powinno być. Jeden wynik jednak niczego mi nie mówi. Jutro podeślę skrypcik w bashu co będzie w pętli to liczył i zbierał wyniki.

Cytat: RAD-Poland w 08 Sierpień 2012, 21:24

Kod [Zaznacz] Rozwiń

bash-4.2$ ulimit -s unlimited
bash-4.2$ ./shor_algorithm_ocl_double
"/tmp/OCLLqoikk.cl", line 28: warning: ignore unrecognized OpenCL extension
  #pragma OPENCL EXTENSION cl_khr_fp64 : enable
                                               ^

"/tmp/OCLLqoikk.cl", line 29: error: can't enable all OpenCL extensions or
          unrecognized OpenCL extension
  #pragma OPENCL EXTENSION cl_khr_int64_base_atomics : enable
                                                       ^

"/tmp/OCLLqoikk.cl", line 46: error: function "atom_cmpxchg" declared
          implicitly
        while ((readback = atom_cmpxchg((__global long*)address, oldval, newval)) != oldval)
                           ^

2 errors detected in the compilation of "/tmp/OCLLqoikk.cl".

Internal error: clc compiler invocation failed.

ERROR: CL_BUILD_PROGRAM_FAILUREERROR: CL_INVALID_KERNEL0 1 1 1.57 0.86 0

:(

No tak... Można było się domyślić...

W repozytorium jest rewizja 33.

Na poczatek przetestuj Shora na double. Potem zapodaj benchmarka. Zobaczymy czy teraz łyknie.

Cytat: RAD-Poland w 08 Sierpień 2012, 21:11
- jak system wytrzyma to zaraz wkleję double....................

:deadman:

bash-4.2$ ./shor_algorithm_ocl_float
Naruszenie ochrony pamięci

Odpowiedz na to:

ulimit -s unlimited

O kurcze faktycznie tak jest problem z przeciążoną funkcją. Zaraz to poprawię.

A próbowałeś coś z tym Shor'em na float?

Cytat: RAD-Poland w 08 Sierpień 2012, 20:51
przy teście nVidia Tesla C2050 masz

CytatERROR: CL_INVALID_BINARY   Execution time: 438 seconds

Szukałem rozwiązania dlaczego tak u mnie jest. Okazało się, że najprawdopodobniej jest to spowodowane starą wersją OpenCL.

Ja mam jedynie:

--- 1 OpenCL platform(s) found: -----------------------------------------
  -- 0 --
  PROFILE = FULL_PROFILE
  VERSION = OpenCL 1.0 CUDA 3.2.1
  NAME = NVIDIA CUDA
  VENDOR = NVIDIA Corporation
  EXTENSIONS = cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll


W ciągu 30 minut dodam do repozytorium nową rewizję z dodatkową pragmą dla AMD to zobaczymy czy to coś zmieni.

Problemem może być interfejs graficzny.

Dasz radę wyłączyć interfejs graficzny i odpalić program mając w systemie tylko tryb tekstowy?

Ja do wieczora postaram się poprawić benchamark i napiszę na forum jak będzie nowa rewizja.

PS. Faktycznie przetestowałem u siebie na nVidia Tesla C2050 i dostałem:

[1: FPU-32] Initial test
Calculations... Please wait...
Execution time: 19 seconds
Rate: 5.263158

[1: FPU-32] Final test
Calculations... Please wait...
FP Units Testing...
Execution time: 84 seconds
Special Units Testing...
Execution time: 127 seconds
Performance: [32-bit float types]
573.638161 GFLOPS
1018482283 special operations (e.g. sin, cos) per second

[1: FPU-64] Final test
Calculations... Please wait...
FP Units Testing...
ERROR: CL_INVALID_BINARY Execution time: 438 seconds
Special Units Testing...
ERROR: CL_INVALID_BINARY Execution time: 25 seconds
Performance: [64-bit float types]
11.001088 GFLOPS
517380000 special operations (e.g. sin, cos) per second

[2: ALU-64] Final test
Calculations... Please wait...
Execution time: 96 seconds
Performance: [64-bit integer types]
260850.292889 MIPS

Na GeForce GTS250 gdzie nie ma double precision działa dobrze:

[1: FPU-32] Initial test
Calculations... Please wait...
Execution time: 105 seconds
Rate: 0.952381

[1: FPU-32] Final test
Calculations... Please wait...
FP Units Testing...
Execution time: 106 seconds
Special Units Testing...
Execution time: 51 seconds
Performance: [32-bit float types]
82.255991 GFLOPS
458926470 special operations (e.g. sin, cos) per second

[1: FPU-64] Final test
FP-64 NOT SUPPORTED

[2: ALU-64] Final test
Calculations... Please wait...
Execution time: 30 seconds
Performance: [64-bit integer types]
151041.883120 MIPS

Jest jakiś ostry wałek w double. Zaraz będę szukał. Może pamiętasz jaką wydajność w FPU-32 pokazał Ci test?

Możesz też spróbowac do tego czasu skompilować i odpalić shor_algorithm_ocl_float (działa na 32-bit float więc jest szansa, że będzie ok)

On powinien wykonywać się szybko. Zwraca na ekran kilka liczb. Jeżeli się uruchomi i zadziała to wykonaj jego kilka razy (ma różne czasy wykonywania i zwraca różne wyniki).

Wersja 32 niczego nie wnosi do problemów, o których wspomniałeś.

Ciekawi mnie jak benchmark wykrył urządzenie OpenCL? Przed uruchomieniem testu miałeś tam wyświetlone informacje o device. Możesz je podesłać bez uruchamiania samego testu (tylko uruchom benchmark, skopiuj informacje i nie zatwierdzaj aby liczył dalej).

Konfiguracja bardzo dobra. Wystarczająca w zupełności.

Testy wykonuje do swojej pracy dyplomowej. Program symuluje algorytmy kwantowe. Potrzebuje pomocy przy testowaniu szybkości wykonywania algorytmu Shora.

Jest napisany także prosty benchmark. Testuje on zarówno CPU jak i inne sprzęty (np. GPU).

Link do repozytorium jest tutaj:

http://code.google.com/p/olib/

Możemy wpisać do konsoli:

svn checkout https://olib.googlecode.com/svn/trunk/

W katalogu gdzie będziemy zostanie utworzony folder 'trunk' i zostanie do niego zassane repozyturium.

Programy znajdują się w katalogu 'samples'. TAm też jest plik makefile. W pliku makefile jest dość dużo wersji programów dlatego nie polecam wpisywać 'make' lub 'make all' ponieważ zapewne czegoś w naszym systemie zabraknie. Lista dostępnych progrosów jest w samples/programs.list


Benchmark w wersji na jeden rdzeń można skompilować następująco:

make benchmark_sp

Benchmark w wersji dla OpenCL (karty AMD itp.) można skompilować za pomocą:

make benchmark_ocl

Po uruchomieniu wersji OpenCL powinna pokazać się lista dostępnych urządzeń, które można przetestować.


Sam algorytm Shora na OpenCL (wersja na float) kompilujemy za pomocą:

shor_algorithm_ocl_float

Możemy też skompilować wersję na double:

shor_algorithm_ocl_double

Czasy wykonywania algorytmu Shora sa różne. Na GPU mogą być bardzo niskie.

Najlepiej całość pobrać z repozytorium (przez polecenie) ponieważ tam znajduje się najnowsza rewizja (aktualnie 31). Wieczorem wyślę spakowane archiwum.

Na poczatek prosze o sprawdzenie czy uda się skompilować (wersję na OpenCL i ewentualnie sp).

Mogą pojawić się problemy z przekroczeniem rozmiaru stosu. Dla pewności proponuję wpisać przed uruchomieniem:

ulimit -s unlimited

Zmienia to rozmiar stosu na unlimited. Nie wpływa negatywnie na system. Zmiana zachodzi tylko dla jednej sesji i gdy odpalimy kolejny terminal to znowu trzeba podać ulimit -s unlimited. Nie wiem czy będzie to niezbędne ale pisze dla pewności.


Praca testera powinna ograniczyć się do sprawdzenia czy progros się skompiluje. Uruchomienia skryptu i odesłania wyników. Niczego dodatkowego nie będzie tester musiał robić więc nakład pracy raczej postaram się zredukować.

Może być APU. Z tego co widzę normalnie to wspiera OpenCL.

Nikt nie ma AMD z Linuxem...

A kto ma nVidię z Linuxem?

CytatUwaga: W tym wątku nie pisano od 200 dni.

Ciekawe  :attack:

Zapraszam all: http://lswierczewski.wordpress.com/  XD