Tak se patrze na to cudo, cudo dosłownie i w przenośni :)
http://www.alternate.pl/html/product/PNY/Tesla_K20/1
047488/?

Jeśli się nie mylę, ma to 2496 procesorów i ponad 1tflop
mocy obliczeniowej - teoretyczne wartości robią wrażenie.
Zastanawiam się jednak jak z takim sprzętem jest w praktyce. Na
pewno nie da się tego oprogramować w asemblerze, więc
pierwsze straty będą spowodowane językiem wysokiego poziomu.
Potem może być problem z całkowitym wykorzystaniem zasobów.
Słyszałem gdzieś, że dopiero od niedawna CUDA ma wsparcie
dla języków z rekurencją - zdaje się że te procesory nie
mają stosu, więc jedynie wchodzi w grę jakaś symulacja
softwerowa na tablicach. Pewnie wad i problemów jest więcej...
Stąd moje pytanie jak taki (lub podobny) sprzęt sprawdza
się w praktyce? Właściwie to nie pytam o aplikacje które
wymagają dużego transferu pomiędzy ram a kartą. Załóżmy że
dane zmieściły się w karcie, a algorytm cały czas na nich
operuje. Jakie przyspieszenie na jakich algorytmach w praktyce
uzyskuje się na takim sprzędzie względem np. najnowszego
procesora i7?

Pozdrawiam

PS. kiedyś sprawdzałem parametry jakiejś innej karty tego
typu i miała pobór mocy 900W. W sumie to był główny czynnik
który zniechęcał do zakupu. Teraz widzę że sprzęt jest mocniejszy, a
pobór mocy zaledwie 225W - robi się ciekawie :)

do góry

On 28.02.2013 17:57, M.M. wrote:
> Tak se patrze na to cudo, cudo dosłownie i w przenośni :)
> http://www.alternate.pl/html/product/PNY/Tesla_K20/1
047488/?
>
> Jeśli się nie mylę, ma to 2496 procesorów i ponad 1tflop
> mocy obliczeniowej - teoretyczne wartości robią wrażenie.
> Zastanawiam się jednak jak z takim sprzętem jest w praktyce. Na
> pewno nie da się tego oprogramować w asemblerze, więc
> pierwsze straty będą spowodowane językiem wysokiego poziomu.
> Potem może być problem z całkowitym wykorzystaniem zasobów.
> Słyszałem gdzieś, że dopiero od niedawna CUDA ma wsparcie
> dla języków z rekurencją - zdaje się że te procesory nie
> mają stosu, więc jedynie wchodzi w grę jakaś symulacja
> softwerowa na tablicach. Pewnie wad i problemów jest więcej...
> Stąd moje pytanie jak taki (lub podobny) sprzęt sprawdza
> się w praktyce? Właściwie to nie pytam o aplikacje które
> wymagają dużego transferu pomiędzy ram a kartą. Załóżmy że
> dane zmieściły się w karcie, a algorytm cały czas na nich
> operuje. Jakie przyspieszenie na jakich algorytmach w praktyce
> uzyskuje się na takim sprzędzie względem np. najnowszego
> procesora i7?
>
> Pozdrawiam
>
> PS. kiedyś sprawdzałem parametry jakiejś innej karty tego
> typu i miała pobór mocy 900W. W sumie to był główny czynnik
> który zniechęcał do zakupu. Teraz widzę że sprzęt jest mocniejszy, a
> pobór mocy zaledwie 225W - robi się ciekawie :)
>
>
>
>
>
>
Dzięki za ciekawe pytanie

GPUGPU czyli cuda lub OpenCl.

alternatywą jest Xeon Phi korzystający ze standardowego kodu ( np. c
+OpnMP )

http://goparallel.sourceforge.net/independent-test-x
eon-phi-shocks-tesla-gpu/

goparallel.sourceforge.net/wp-content/uploads/2013/0
1/Colfax_Nbody_Xeon_Phi.pdf



Adam

do góry

W dniu 2013-02-28 17:57, M.M. pisze:
> Tak se patrze na to cudo, cudo dosłownie i w przenośni :)
> http://www.alternate.pl/html/product/PNY/Tesla_K20/1
047488/?
>
> Jeśli się nie mylę, ma to 2496 procesorów i ponad 1tflop
> mocy obliczeniowej - teoretyczne wartości robią wrażenie.
> Zastanawiam się jednak jak z takim sprzętem jest w praktyce. Na
> pewno nie da się tego oprogramować w asemblerze, więc
> pierwsze straty będą spowodowane językiem wysokiego poziomu.

I Ty za magią assemblera?
c (i to niepełny, przynajmniej jeszcze niedawno) jest
dostatecznie blisko. A jeszcze lepiej FORTRAN;)

> Potem może być problem z całkowitym wykorzystaniem zasobów.
> Słyszałem gdzieś, że dopiero od niedawna CUDA ma wsparcie
> dla języków z rekurencją - zdaje się że te procesory nie
> mają stosu, więc jedynie wchodzi w grę jakaś symulacja
> softwerowa na tablicach. Pewnie wad i problemów jest więcej...

A po co Ci stos w koprocesorze;) To się zupełnie nie nadaje
do przechodzenia grafu czy liczenia silni rekurencyjnie.
To cierpi nawet, jeśli są rozgałęzienia programu.

> Stąd moje pytanie jak taki (lub podobny) sprzęt sprawdza
> się w praktyce? Właściwie to nie pytam o aplikacje które
> wymagają dużego transferu pomiędzy ram a kartą. Załóżmy że
> dane zmieściły się w karcie, a algorytm cały czas na nich
> operuje. Jakie przyspieszenie na jakich algorytmach w praktyce
> uzyskuje się na takim sprzędzie względem np. najnowszego
> procesora i7?

Bardzo dobrze. Ale w swoich zadaniach, to nie jest uniwersalny
procesor do wszystkiego.

Z lekkim przymrożeniem oka możesz patrzeć na to jak na
koprocesor, tylko on nie dostaje do przemnożenia
dwa double, tylko dwie macierze zespolone po 200MB,
albo jakąś funkcję do policzenia w tysiącach punktów naraz.

Jak się sprawdza. AMD Phenon II X4 955 (3.2GHz)
kontra
GTX 460v2 (też nie kręcone)

Przy tym, co karty lubią najbardziej, czyli mnożeniu
gęstych macierzy karta była jakieś 12 razy szybsza
na dużych danych. Wliczając w to czas transferu danych!

Oczywiście, obliczenia za pomocą bibliotek, nie własnych wynalazków.

> Pozdrawiam
>
> PS. kiedyś sprawdzałem parametry jakiejś innej karty tego
> typu i miała pobór mocy 900W. W sumie to był główny czynnik
> który zniechęcał do zakupu. Teraz widzę że sprzęt jest mocniejszy, a
> pobór mocy zaledwie 225W - robi się ciekawie :)

Za 15kzł chciałbym więcej RAMu:)
"Panie, a co ja mam zrobi na tych marnych 4GB na węźle" :)

pzdr
bartekltg

do góry

M.M. <m...@g...com> wrote:
> Tak se patrze na to cudo, cudo dosłownie i w przenośni :)
> http://www.alternate.pl/html/product/PNY/Tesla_K20/1
047488/?
>
> Jeśli się nie mylę, ma to 2496 procesorów i ponad 1tflop
> mocy obliczeniowej - teoretyczne wartości robią wrażenie.
> Zastanawiam się jednak jak z takim sprzętem jest w praktyce. Na
> pewno nie da się tego oprogramować w asemblerze, więc
> pierwsze straty będą spowodowane językiem wysokiego poziomu.
... wiesz, to nie tak. Wlasciwie mozna traktowc C jako
taki makroasembler;-) Straty przy dzisiejszej optymalizacji
sa np dla takiego C minimalne. Z powazaniem
Adam Przybyla

do góry

Użytkownik Adam Majewski napisał:
>Adam Majewski
> alternatywą jest Xeon Phi korzystający ze standardowego
> kodu ( np. c+OpnMP )
Niezłe!


W dniu czwartek, 28 lutego 2013 19:30:54 UTC+1 użytkownik bartekltg napisał:
> A po co Ci stos w koprocesorze;)
Zwykła-zachłanna natura człowieka :)


> To się zupełnie nie nadaje
> do przechodzenia grafu czy liczenia silni rekurencyjnie.
Nie mam pewnych informacji, ale gdzieś o uszy mi się obiła
plotka, że ktoś na to szachy napisał. Mnie też się to
wydaje dziwne, ale któż to wie...


> To cierpi nawet, jeśli są rozgałęzienia programu.
To niedobrze :(


> Bardzo dobrze. Ale w swoich zadaniach, to nie jest uniwersalny
> procesor do wszystkiego.


> Z lekkim przymrożeniem oka możesz patrzeć na to jak na
> koprocesor, tylko on nie dostaje do przemnożenia
> dwa double, tylko dwie macierze zespolone po 200MB,
> albo jakąś funkcję do policzenia w tysiącach punktów naraz.
Myślę o tym głównie pod kątem czegoś podobnego do symulowanego
wyżarzania, czyli w kółko liczenie wartości funkcji. Niestety
ta funkcja, choć nie jest funkcją rekurencyjną, ma
dużo ifów.


> Jak się sprawdza. AMD Phenon II X4 955 (3.2GHz)
> kontra
> GTX 460v2 (też nie kręcone)
> Przy tym, co karty lubią najbardziej, czyli mnożeniu
> gęstych macierzy karta była jakieś 12 razy szybsza
> na dużych danych. Wliczając w to czas transferu danych!
Jeśli wierzyć temu co piszą na wiki, to GTX 460v2 też ma
ponad 1TFLOP... 12 razy na czymś co karta lubi najbardziej...
to nie aż tak dużo. Powiedzmy że bez transferu byłoby to
ze 20 razy, a na gąszczu if-ów 10 razy... hmmm. Myślałem
że to będzie przyspieszenie rzędu 100-200 razy.

Gdzieś czytałem benchmark w którym cztery tesle działały
270 razy szybciej niż dwa zwykłe procesory. Aplikacja to
jakaś sieć neuronowa. Kurcze... jeśli karta ma prawie 3tys
rdzeni i nawet gdy rdzeń jest 10 razy wolniejszy od rdzenia
w głównym procesorze, to nadal karta powinna dawać przyspieszenie
rzędu 50-100 razy.

Może to jednak kwestia asemblera? Nie wiem jak jest dzisiaj.
Ale jakieś kilkanaście lat temu, jak przepisałem niechlujnie
procedurę w asemblerze, to działała 3 razy szybciej niż
skompilowana kompilatorem C/C++. Gdy przepisałem ją porządnie,
to działała 3-4 razy szybciej. Gdy dostosowałem jeszcze
strukturę danych, czyli tak jakby zmiana algorytmu, to dało się
wyciągnąć nawet 5 razy. Potem pojawiły się lepsze kompilatory,
które od swoich starszych poprzedników generowały kod 3 razy
szybszy. Można było je pokonać pisząc ręcznie w asm, ale to
wymagało dużo pracy. Potem już w asemblerze nie pisałem i teraz
generalnie nie znam się, ale faktem jest, że często pojawiają się nowe
procesory. Czy kompilatory nadążają za nowymi procesorami?
Jak jest teraz, to nie wiem, ale kiedyś pojawiały się z
dużym opóźnieniem. Karta graficzna, czy tam taki koprocesor,
to tak jakby większa nowość niż nowy procesor... może
języki wysokiego poziomu na te karty kuleją i pisząc w
asemblerze da się uzyskać przyspieszenie nawet 10 krotne
względem języka wysokopoziomowego?


> Oczywiście, obliczenia za pomocą bibliotek, nie własnych wynalazków.
Więc te 12 razy to może jednak dobre oszacowanie, nie wiem
już co myśleć.

> Za 15kzł chciałbym więcej RAMu:)
> "Panie, a co ja mam zrobi na tych marnych 4GB na węźle" :)
Podejrzewam że mnie by wystarczyło nawet 0.5GB na kartę. Ale
myślałem że to będą przyspieszenia rzędu 100 razy względem i7.

Pozdrawiam i dzięki wszystkim za odpowiedzi!

do góry

On 01.03.2013 11:14, M.M. wrote:
>> To cierpi nawet, jeśli są rozgałęzienia programu.
> To niedobrze :(

To jest po prostu inny sprzęt i go się inaczej programuje. Na klasycznym
procesorze sporo przypadków opiera się o różne formy pętli, na GPU na
podział danych na jednorodne bloki i wykonywanie na nich takich samych
operacji.


>
>
>> Bardzo dobrze. Ale w swoich zadaniach, to nie jest uniwersalny
>> procesor do wszystkiego.
>
>
>> Z lekkim przymrożeniem oka możesz patrzeć na to jak na
>> koprocesor, tylko on nie dostaje do przemnożenia
>> dwa double, tylko dwie macierze zespolone po 200MB,
>> albo jakąś funkcję do policzenia w tysiącach punktów naraz.
> Myślę o tym głównie pod kątem czegoś podobnego do symulowanego
> wyżarzania, czyli w kółko liczenie wartości funkcji. Niestety
> ta funkcja, choć nie jest funkcją rekurencyjną, ma
> dużo ifów.

Wszystko zależy od przypadku - czasami lepiej napisać if, czasami lepiej
zamienić coś pokroju (to tylko przykład)

if(b>10)
a = 123*b*y;
else if(b<-10)
a = 321*b*x;
else
a = b*x*y;

na

a = (b>10)*123*b*y + (b<-10)*321*b*x + (!(b>10))*(!(b<-10))*b*x*y

>
> Może to jednak kwestia asemblera? Nie wiem jak jest dzisiaj.
> Ale jakieś kilkanaście lat temu, jak przepisałem niechlujnie
> procedurę w asemblerze, to działała 3 razy szybciej niż
> skompilowana kompilatorem C/C++.

Przez kilkanaście lat naprawdę sporo się zmieniło to raz. Po drugie na
dzisiejsze procesory czasami lepiej jest wygenerować "ciaśniejszy" kod,
niż "szybszy" bo zaoszczędzenie na dostępach do cache potrafi dawać
kilkukrotny boost. W języku pokroju C++ wystarczy zmienić atrybuty
dotyczące optymalizacji, w asm musisz przepisywać ;) W ogóle asm poza
bardzo rzadkimi przypadkami to strata czasu - liczy się doby algorytm a
go im wyżej poziomowy język tym szybciej zapisać, przetestować,
tuningować. Mikrooptymalizacje to robota na sam, sam koniec.

--
Pozdrawiam
Michoo

do góry

Dnia Fri, 01 Mar 2013 02:14:05 -0800, M.M. wyszeptal:

>> To się zupełnie nie nadaje
>> do przechodzenia grafu czy liczenia silni rekurencyjnie.
> Nie mam pewnych informacji, ale gdzieś o uszy mi się obiła
> plotka, że ktoś na to szachy napisał. Mnie też się to
> wydaje dziwne, ale któż to wie...

Całkiem możliwe.

>> To cierpi nawet, jeśli są rozgałęzienia programu.
> To niedobrze :(

Niekoniecznie. Krótkie if-y są zastępowane predykatami.
Jedne instrukcje wykonywane są gdy true, inne gdy false.
To byłoby dwa razy wolniej. Większe if-y wymagają interwencji
schedulera, wykonywane są najpierw jedne potem drugie. Tak
czy inaczej moc obliczeniowa jest 30-70x większa niż
przepustowość RAM, często if-y nic nie zmienią.

>> Bardzo dobrze. Ale w swoich zadaniach, to nie jest uniwersalny
>> procesor do wszystkiego.
>
>
>> Z lekkim przymrożeniem oka możesz patrzeć na to jak na
>> koprocesor, tylko on nie dostaje do przemnożenia
>> dwa double, tylko dwie macierze zespolone po 200MB,
>> albo jakąś funkcję do policzenia w tysiącach punktów naraz.
> Myślę o tym głównie pod kątem czegoś podobnego do symulowanego
> wyżarzania, czyli w kółko liczenie wartości funkcji. Niestety
> ta funkcja, choć nie jest funkcją rekurencyjną, ma
> dużo ifów.

Wiele algorytmów piszę inaczej na cpu niż na gpu. Główną zaletą
Phi jest pewnie czas pisania kodu.

>> Jak się sprawdza. AMD Phenon II X4 955 (3.2GHz)
>> kontra
>> GTX 460v2 (też nie kręcone)
>> Przy tym, co karty lubią najbardziej, czyli mnożeniu
>> gęstych macierzy karta była jakieś 12 razy szybsza
>> na dużych danych. Wliczając w to czas transferu danych!
> Jeśli wierzyć temu co piszą na wiki, to GTX 460v2 też ma
> ponad 1TFLOP... 12 razy na czymś co karta lubi najbardziej...
> to nie aż tak dużo. Powiedzmy że bez transferu byłoby to
> ze 20 razy, a na gąszczu if-ów 10 razy... hmmm. Myślałem
> że to będzie przyspieszenie rzędu 100-200 razy.

Niektórych nie ma sensu przepisaywać na kartę, niektóre mają
10x, niektóre algorytmy dają 200x. Liczy się przepustowość,
zupełnie inaczej niż na cpu.

> Gdzieś czytałem benchmark w którym cztery tesle działały
> 270 razy szybciej niż dwa zwykłe procesory. Aplikacja to
> jakaś sieć neuronowa. Kurcze... jeśli karta ma prawie 3tys
> rdzeni i nawet gdy rdzeń jest 10 razy wolniejszy od rdzenia
> w głównym procesorze, to nadal karta powinna dawać przyspieszenie
> rzędu 50-100 razy.

Marnować Teslę na sieci neuronowe? To już jest przesada IMO :)

> Może to jednak kwestia asemblera? Nie wiem jak jest dzisiaj.
> Ale jakieś kilkanaście lat temu, jak przepisałem niechlujnie
> procedurę w asemblerze, to działała 3 razy szybciej niż
> skompilowana kompilatorem C/C++. Gdy przepisałem ją porządnie,
> to działała 3-4 razy szybciej. Gdy dostosowałem jeszcze
> strukturę danych, czyli tak jakby zmiana algorytmu, to dało się
> wyciągnąć nawet 5 razy. Potem pojawiły się lepsze kompilatory,
> które od swoich starszych poprzedników generowały kod 3 razy
> szybszy. Można było je pokonać pisząc ręcznie w asm, ale to
> wymagało dużo pracy. Potem już w asemblerze nie pisałem i teraz
> generalnie nie znam się, ale faktem jest, że często pojawiają się nowe
> procesory. Czy kompilatory nadążają za nowymi procesorami?
> Jak jest teraz, to nie wiem, ale kiedyś pojawiały się z
> dużym opóźnieniem. Karta graficzna, czy tam taki koprocesor,
> to tak jakby większa nowość niż nowy procesor... może
> języki wysokiego poziomu na te karty kuleją i pisząc w
> asemblerze da się uzyskać przyspieszenie nawet 10 krotne
> względem języka wysokopoziomowego?

Możesz pisać w PTX. Nie jest bezpośrednio assemblerem, jest
częściowo tłumaczony przez sterownik, ale daje pełną kontrolę.

Przyśpieszenie uzyskuje się generalnie na dwa sposoby: próbuje
się zająć wszystkie rdzenie, jest nawet prosty kalkulator do tego
celu w Excelu, oraz optymalizuje dostęp do pamięci, w tym
pamięci na gpu - zależnie od tego co ma niższą przepustowość.

>> Oczywiście, obliczenia za pomocą bibliotek, nie własnych wynalazków.
> Więc te 12 razy to może jednak dobre oszacowanie, nie wiem
> już co myśleć.
>
>> Za 15kzł chciałbym więcej RAMu:)
>> "Panie, a co ja mam zrobi na tych marnych 4GB na węźle" :)
> Podejrzewam że mnie by wystarczyło nawet 0.5GB na kartę. Ale
> myślałem że to będą przyspieszenia rzędu 100 razy względem i7.

To bardzo dobrze, że nie potrzebuje więcej Ram. Zostaje tylko
dopasować algorytm i kupić grzałkę ;) Same dane przy 192GB/s
teoretycznie wczytasz 300 razy na sekundę.

--
Edek

do góry

On Thu, 28 Feb 2013 08:57:35 -0800 (PST), "M.M." <m...@g...com>
wrote:
> Stąd moje pytanie jak taki (lub podobny) sprzęt sprawdza
> się w praktyce? Właściwie to nie pytam o aplikacje które
> wymagają dużego transferu pomiędzy ram a kartą. Załóżmy że
> dane zmieściły się w karcie, a algorytm cały czas na nich
> operuje. Jakie przyspieszenie na jakich algorytmach w praktyce
> uzyskuje się na takim sprzędzie względem np. najnowszego
> procesora i7?

Nie wiem na ile moja odpowiedź Ci pomoże, ale w firmie w której
pracowałem grupa quantow przeniosła model stochastycznej wolatywnosci
Hestona na GPU I uzyskała przyspieszenie rzędu 100-400x, tak ze mogli
kalibrowac model symulacja Monte-Carlo, bez przyblizen analitycznych.

RW

do góry

użytkownik Roman W napisał:
> Nie wiem na ile moja odpowiedź Ci pomoże, ale w firmie w której
> pracowałem grupa quantow przeniosła model stochastycznej wolatywnosci
> Hestona na GPU I uzyskała przyspieszenie rzędu 100-400x, tak ze mogli
> kalibrowac model symulacja Monte-Carlo, bez przyblizen analitycznych.
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 informacja
dla mnie.

Natomiast nie znam szczegółów, nie wiem np. jakie obliczenia
dominują w tej symulacji MC. Nie wiem też co było z czym porównywane,
czy chodzi o przyspieszenie jedna karta vs jeden procesor, czy może
klaster 50 komputerów vs 50 kart, czy może komputer 4-procesorowy vs 4 karty.
Nie wiem też jakie wersje procesorów i kart były porównywane. Niemniej
jeśli innym się udało uzyskać przyspieszenia 100 razy, to mocno
przemawia do mnie aby zakupić karty i spróbować - a nóż się uda.

Z drugiej strony zastanawiam sie dlaczego w teście jaki przedstawił
Bartek wyszło przyspieszenie tylko 12 razy. Z informacji znalezionych
na wiki wynika, że sprzęt na którym testował Bartek, także jest mocny:
http://en.wikipedia.org/wiki/GeForce_400_Series
Ale skoro jest taki mocny, to dlaczego kosztuje tylko 200 dolców.

użytkownik Edek Pienkowski napisał:
> Wiele algorytmów piszę inaczej na cpu niż na gpu. Główną zaletą
> Phi jest pewnie czas pisania kodu.
Tak, a to bardzo ważna zaleta.


> Niektórych nie ma sensu przepisaywać na kartę, niektóre mają
> 10x, niektóre algorytmy dają 200x. Liczy się przepustowość,
> zupełnie inaczej niż na cpu.
Czyli w ogóle takie przyspieszenia są możliwe, w sumie chciałem
się dowiedzieć czy to nie jest marketingowa bujda :)

> Marnować Teslę na sieci neuronowe? To już jest przesada IMO :)
Dlaczego? Mnie się to wydaje idealne na Teslę, liczy się funkcję
dla wielu punktów jednocześnie.


> To bardzo dobrze, że nie potrzebuje więcej Ram. Zostaje tylko
> dopasować algorytm i kupić grzałkę ;) Same dane przy 192GB/s
> teoretycznie wczytasz 300 razy na sekundę.
Jeszcze nie jestem pewny, ale możliwe że będę mógł robić
jeden transfer na dobę pomiędzy ram a kartą :)


Pozdrawiam i dzięki wszystkim za odpowiedzi!

do góry

Dnia Sat, 02 Mar 2013 07:59:15 -0800, M.M. wyszeptal:
> użytkownik Edek Pienkowski napisał:
>> Marnować Teslę na sieci neuronowe? To już jest przesada IMO :)
> Dlaczego? Mnie się to wydaje idealne na Teslę, liczy się funkcję
> dla wielu punktów jednocześnie.

Ja też dla sportu i dla nauki cuda pisałem sieci neuronowe. Ale
nie po to się kupuje Teslę.

>> To bardzo dobrze, że nie potrzebuje więcej Ram. Zostaje tylko
>> dopasować algorytm i kupić grzałkę ;) Same dane przy 192GB/s
>> teoretycznie wczytasz 300 razy na sekundę.
> Jeszcze nie jestem pewny, ale możliwe że będę mógł robić
> jeden transfer na dobę pomiędzy ram a kartą :)

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. 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ę.

--
Edek

do góry