On Tue, 8 Mar 2011 20:54:29 +0100, "slawek" <s...@h...pl> wrote:
> >
http://www.tomshardware.co.uk/charts/desktop-cpu-cha
rts-2010/Raw-Perfor

> > mance-SiSoftware-Sandra-2010-Pro-GFLOPS,2409.html


> Ciekawe, bo pod tym adresem mam:

> Tom's Hardware > Error 404
> Sorry!
> The page you requested couldn't be found
> Tom's Hardware

> Zupełnie nie wiem czemu. LOL

Wiesz, jeśli nie potrafisz rozgryźć tej zagadki, to może lepiej by
było, gdybyś zajął się czymś innym niż pisanie programów.

do góry

On 9 Mar, 11:53, "slawek" <h...@s...pl> wrote:
> Użytkownik "Michoo"  napisał w wiadomości grup
> dyskusyjnych:il7d7t$c...@n...onet.pl...
>
> >Jeżeli oszacowanie na poziomie 10X Cię interesuje to tak.
>
> Jeżeli nie możesz podać z dokładnością do 0.01%, to lepiej znać "na poziomie
> 10X" - niż nic nie umieć odpowiedzieć.

Doprowadz ponizszy kod do wersji kompilowalnejj, uruchom dla roznych
SIZE, zmierz czasy dla roznych SIZE ale tych samych TIME.
Zobaczymy co wyjdzie.

#define TIME 1000000000
#define SIZE od 1E3 do 1E9
double x[SIZE];
for( i=0 ; i<SIZE ; i++ )
x[i] = rand() % 16 - rand() % 16;
double sum=0;
unsigned int r1 = 1234;
unsigned int r2 = 2345;
unsigned int r3 = 3456;
for( i=0 ; i<TIME ; i++ ) {
sum += x[r1%SIZE];
r1 += r2 + r3;
r2 += r1 + r3;
r3 += r1 + r2;
}
printf( sum );

do góry

On 09.03.2011 11:53, slawek wrote:
> Użytkownik "Michoo" napisał w wiadomości grup
> dyskusyjnych:il7d7t$coe$...@n...onet.pl...
>
>> Jeżeli oszacowanie na poziomie 10X Cię interesuje to tak.
>
> Jeżeli nie możesz podać z dokładnością do 0.01%, to lepiej znać "na
> poziomie 10X" - niż nic nie umieć odpowiedzieć.
>
> Jak na razie - nie podałeś nawet "na poziomie 10X". Dlaczego? Trywialne
> wyjaśnienie - nie masz "wiedzy na ten temat".
>

Po pierwsze przemyśl sobie jak zbudowane są współczesne procesory, pod
co są optymalizowane. Problem z obliczeniem ich wydajności jest na tyle
duży, że stosuje się profilowane testy. I nagle okazuje się, że jeden
procesor w grach jest lepszy, a drugi w obliczeniach, a trzeci w
przetwarzaniu grafiki w photoshopie.
To trochę tak jakby obecnie przeliczać na owies zużywane paliwo przez
samochód, śmigłowiec i rakietę kosmiczną.

--
wer <",,)~~
http://szumofob.eu

do góry

W dniu 09.03.2011 11:53, slawek pisze:
> Użytkownik "Michoo" napisał w wiadomości grup

> Jak na razie - nie podałeś nawet "na poziomie 10X". Dlaczego? Trywialne
> wyjaśnienie - nie masz "wiedzy na ten temat".
Problemy ze wzrokiem?
Message-ID: <ikuaqr$1nr$1@news.onet.pl>

>
>> Jesteś ignorantem. Od pewnego czasu mamy właśnie wzrost GIPS (i trochę
>> mniejszy GFLOPS) przy równoczesnym zatrzymaniu, czy wręcz spadku
>> częstotliwości.
>
> Gdybym miał konkretne dane - nie pytałbym - a więc masz rację, w jakimś
> sensie jestem "ignorantem".
_Jakieś_ konkretne dane już dostałeś od Andrzeja, ale linka nie umiesz
otworzyć.

>
> Niemniej jednak - jak czytam to co napisałeś - to jawisz się jako picer
> od reklamy w marketingu, który nawija niczym towarzysz Gierek - "mamy
> wzrost przy jednoczesnym zatrzymaniu"! LOL
Nie nie LOL. Twój brak wiedzy nie jest już nawet śmieszny.

>
> A już "czy wręcz spadku" - to mega-LOL - przypomnienie "starych dobrych
> czasów betonu" bezcenne. (Czekam jeszcze na "na tym odcinku";
> "pomożecie?"; "ciągłe doskonalenie".)
>
> Konkrety może jakieś? Ile mamy dziś megaflopsów - a ile mieliśmy w
> analogicznym kwartale roku ubiegłego?
Nie dotrze do ciebie, że takie liczby można porównywać w obrębie
KONKRETNEGO testu? Co robiłeś w szkole jak uczyli czytać ze zrozumieniem.

> Sam napisałeś, patrz wyżej, że
> oszacowanie obarczone jest błędem rzędu tysiąca procent... więc skąd u
> ciebie optymizm?!
Z *moich* testów. Polegających na kompilacji kodu - mnie taka strona
"wydajności" interesuje.

> Nota bene, spadek częstotliwości to raczej nigdy nie
> jest postępem - można, choćby chłodząc azotem, zawsze podkręcić i mieć
> trochę więcej i trochę do przodu.
Widzę, że jesteś też specjalistą w dziedzinie krzemu i projektowania
układów.


> Obniżanie częstotliwości służy
> bateriom, ale my nie dyskutujemy o czasie pracy netbooków - jakbyś nie
> zauważył.
Służy też zapewnieniu wystarczającego odprowadzania ciepła. Nawet ciekły
azot nie pomoże jak się zagotuje interconnect albo sam krzem przegrzeje.
Poza tym przy pewnej dozie równoległości nie ma sensu zwiększanie
częstotliwości bo pamięć nie wyrobi. Dzisiejsze komputery zazwyczaj nie
_prowadzą obliczeń_ a _przetwarzają dane_. I pod to się je optymalizuje.

>
>> Zamiana _kolejności_ instrukcji (a więc brak zmiany ilości tych FLO)
>> może dać wielokrotnie różne wyniki.
>
> Acha, właśnie usiłujesz mi przekazać, że czas obliczania 1+2+3 jest
> różny od 3+2+1 .
Nie. Czas obliczania:
for(int i=0;i<SIZE;i++)
{
tabA[i]=tabB[i]*tabC[i]+tabD[i];
}
Może być różny (i wcale nie w tę stronę co myślisz) od:
for(int i=0;i<SIZE;i++)
{
tabA[i]=tabB[i]*tabC[i];
}
for(int i=0;i<SIZE;i++)
{
tabA[i]+=tabD[i];
}

> Acha. A w domu to wszyscy zdrowi?
U mnie na szczęście tak, bardzo mi przykro z twojego powodu.

>> Nie zwykłe, bo tych dodawań [dla obliczenia funkcji
>> trygonometrycznych, hiperbolicznych] jest po drodze kilka.
>
> To poczytaj sobie, jak był zrobiony Intel 80287.
Taa... Oidp 80287 potrzebowało ~50 cykli na jedno dodawanie. Nie ma jak
turbo wydajność.

> Od tamtych czasów
> trochę minęło, oczekiwałbym jakiegoś postępu.
Tak, jest SSE i spółka - one są właśnie potokowe. A nie
turboszbkie/instrukcja.

> Nota bene, masz jakieś
> blade pojęcie o tym, jak naprawdę zaimplementowane są rozkazy FPU?!
Pewnie. A ty?

> LOL
Już pisałem, że twoja wiedza nie jest śmieszna tylko przygnębiająca.

>
>> Od czasów wymyślenia przewidywania skoków i wywoływania operacji FP w
>> pipeline nie ma czegoś takiego jak RAW IPS/RAW FLOPS. Wszystko jest w
>> kontekście określonego testu na określonej wersji kompilatora.
>
> Wykręcasz się. Oczywiście, można nieco zaoszczędzić. Są dwie możliwości:
> albo wyrocznia odgadnie wszystko i wszystko ułoży się optymalnie dla
> prędkości - albo wyjdzie jak zwykle, tj. wszystko się spieprzy, nic się
> nie da przyspieszyć. W jednym i drugim przypadku MOŻNA określić ile
> FLOPS wyciągnął procesor. Każda inna możliwość będzie zawierała się w
> tak ustalonym przedziale.
No to robimy test z NOP'ami (2 NOP/cykl to już od dawna standard). O
czym mówi tak zmierzona wydajność? Czy daje się porównać z platformą,
która robi tylko 1 NOP/cykl? (I która "w teście" wychodzi 2 razy
wolniejsza?)

>
>> Może i fajnie, ale [moc silnika samochodu] niewiele daje informacji o
>> takich 'szczegółach' jak np prędkość maksymalna, czy "ile +- czasu
>> będę jechał na 100km pustej autostradzie".
>
> Zdziwisz się - daje. Prędkość maksymalną wyliczysz sobie, porównując ze
> znana prędkością maksymalną tego samego auta, ale z innymi silnikami.
Jeden model będzie miał karoserię z włókna a drugi wzmocnioną, z
dodatkową klatką wewnątrz i twoje wyliczenia staja się bardzo trafne...

> Znając masę - nietrudno obliczyć, z mocy silnika, ile zajmie rozpędzenie
> do 100 km/h.
Ile może zająć teoretycznie. 1000 konny spychacz może mieć problem z
rozpędzeniem się do 80. Bo mu ta moc jest w innym celu potrzebna.

>> przełożenia zamiast podawania prędkości maksymalnej zmierzonej w
>
> O ile pamiętam, to dla R&R nie podawano prędkości maksymalnej. Dla
> pozostałych modeli aut - jak najbardziej się podaje. Poszukaj, sprawdź.
Przeczytałeś o warunkach testowych? Co u diabła da Ci w realnej sytuacji
informacja o tym jak szybko samochód kręci kołami przy braku obciążenia?

>
>> Jeżeli Cię interesuje taki rząd wielkości to o czym jest ta dyskusja?
>
> O tym, że nie jestem najmądrzejszy na świecie, więc pytam się, czy ktoś
> wie coś, co pozwoliłoby moje - jakże zgrubne - oszacowania uściślić.
>
Dostałeś, nie umiesz skorzystać - to już Twój problem.

--
Pozdrawiam
Michoo

do góry

On 03/08/2011 08:54 PM, slawek wrote:
>
> Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał w
> wiadomości grup
> dyskusyjnych:a...@n...gaze
ta.pl...
>> On Mon, 7 Mar 2011 13:14:03 -0800 (PST), Mariusz
>> Marszałkowski<m...@g...com> wrote:
>>> Dla kart graficznych mozna latwo znalezc:
>>
>> Ale co wam właściwie wyskakuje jak guglacie "CPU GFLOPS chart"? Bo mi
>> np to:
>>
>> http://www.tomshardware.co.uk/charts/desktop-cpu-cha
rts-2010/Raw-Perfor
>> mance-SiSoftware-Sandra-2010-Pro-GFLOPS,2409.html
>
> Ciekawe, bo pod tym adresem mam:
>
> Tom's Hardware > Error 404
> Sorry!
> The page you requested couldn't be found
> Tom's Hardware
>
> Zupełnie nie wiem czemu. LOL

Tak? Mi pokazuje wyniki.

JD

do góry

On 08/03/2011 19:51, slawek wrote:
>
> Użytkownik "Bronek Kozicki" <b...@s...net> napisał w wiadomości grup
> dyskusyjnych:4d762ea3$0$12227$c3e8da3$6d1d8cbd@news.
astraweb.com...
>> dla uświadomienia Sławka - czas dostępu do pamięci może być ponad 100x
>> większy od czasu pojedynczej operacji.
>
> Jeżeli to swap na HDD to może być nawet 10000 razy wolniej.
>
> Ale - program+dane z luzem mieszczą się w cache procesora - więc czas
> dostępu do pamięci nie ma znaczenia.

nie zauważyłem tego zastrzeżenia wcześniej w tym wątku,


B.

do góry

Użytkownik "Marek Borowski" <m...@b...com> napisał w
wiadomości grup dyskusyjnych:il7ngk$kg5$...@n...onet.pl...
> W przypadku nowoczesnych procesorow nie jest to takie proste do
> policzenia, no chyba ze chcesz liczyc ilosc opercji nop / s.

Jeżeli nie jest takie łatwe do policzenia - to znaczy że pytanie o to, jakie
to jest - nie jest pytaniem trywialnym. q.e.d.

slawek

do góry

Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał w
wiadomości grup dyskusyjnych:a...@n...gaze
ta.pl...
> Wiesz, jeśli nie potrafisz rozgryźć tej zagadki, to może lepiej by było,
> gdybyś zajął się czymś innym niż pisanie programów.

Jeżeli nie potrafisz porządnie zapodać linku - to może lepiej tego nie rób,
dobrze?

do góry

Użytkownik "Bronek Kozicki" <b...@s...net> napisał w wiadomości grup
dyskusyjnych:4d77a2df$0$25231$c3e8da3$efbdef2c@news.
astraweb.com...
> nie zauważyłem tego zastrzeżenia wcześniej w tym wątku,

Teraz już widzisz.

slawek

do góry

Użytkownik "Mariusz Marszałkowski" <m...@g...com> napisał w wiadomości
grup
dyskusyjnych:68341070-543c-4d20-88e2-595a54731611@o1
0g2000vbg.googlegroups.com...
> Zobaczymy co wyjdzie.

Jak puszczę na dużej maszynce - to różnice będą niewielkie ;)

do góry