-
11. Data: 2009-07-04 17:02:53
Temat: Re: liczby dużej (nie dowolnej) precyzji
Od: "Mariusz Marszałkowski" <b...@W...gazeta.pl>
A.L. <a...@a...com> napisał(a):
> On Sat, 4 Jul 2009 16:34:04 +0000 (UTC), Roman Werpachowski <"r o m a
> nNOSPAM"@student.ifpan.edu.pl> wrote:
>
> >
> >Kod ktory moze zalozyc ze macierz jest 5x5 moze zostac bardziej
> >zoptymalizowany niz kod, ktory musi obslugiwac macierz dowolnych rozmiarow.
> >Na tym polega sila takich bibliotek jak http://tvmet.sourceforge.net/
>
> Ze mozna rozwinac petle? Mozna
>
Można też tak napisać kod, aby małą strukturę w całości załadować do
pamięci cache.
Pozdrawiam
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
-
12. Data: 2009-07-04 17:07:09
Temat: Re: liczby dużej (nie dowolnej) precyzji
Od: Roman Werpachowski <"r o m a nNOSPAM"@student.ifpan.edu.pl>
On the Sat, 4 Jul 2009 16:56:46 +0000 (UTC), Mariusz Marszałkowski wrote:
>> > Kompletnie nie wiem czy były próby takiego przyspieszenia i czy zysk jest
>> > rzędu 10% czy 1000%. Jeśli jest mniejszy niż 200% to nie ma sensu się
>> > tym interesować.
>>
>> Zalezy od sytuacji.
>>
>
> Np. taka sytuacja jak opisałem: Mnożymy duże macierze. Raz elementem jest
> liczba o dowolnej precyzji a drugi raz wyspecjalizowana o stałej precyzji.
> Oczywiście ta liczba o dowolnej precyzji jest tak ograniczona, że obie liczby
> mają podobną dokładność, np. 40-60 cyfr w systemie dziesiątkowym.
Nie mam pojecia, jaki zysk osiagniesz, najlepsze co mozesz zrobic to
porownac dwie implementacje w praktyce. Spodziewalbym sie, z wielu przyczyn,
ze ta druga implementacja bedzei szybsza. "Zalezy od sytuacji" odnosilo sie
do pytania, czy warto sie interesowac zyskiem mniejszym niz 200%. Jezeli moj
program wykonuje sie 8h, a po przyspieszeniu "tylko" 6h, to ja sie
zainteresuje.
RW
-
13. Data: 2009-07-04 17:25:50
Temat: Re: liczby dużej (nie dowolnej) precyzji
Od: A.L. <a...@a...com>
On Sat, 4 Jul 2009 17:02:53 +0000 (UTC), "Mariusz Marszałkowski"
<b...@W...gazeta.pl> wrote:
>A.L. <a...@a...com> napisał(a):
>
>> On Sat, 4 Jul 2009 16:34:04 +0000 (UTC), Roman Werpachowski <"r o m a
>> nNOSPAM"@student.ifpan.edu.pl> wrote:
>>
>> >
>> >Kod ktory moze zalozyc ze macierz jest 5x5 moze zostac bardziej
>> >zoptymalizowany niz kod, ktory musi obslugiwac macierz dowolnych rozmiarow.
>> >Na tym polega sila takich bibliotek jak http://tvmet.sourceforge.net/
>>
>> Ze mozna rozwinac petle? Mozna
>>
>
>Można też tak napisać kod, aby małą strukturę w całości załadować do
>pamięci cache.
Ze co?
A.L.
-
14. Data: 2009-07-04 17:38:14
Temat: Re: liczby dużej (nie dowolnej) precyzji
Od: Roman Werpachowski <"r o m a nNOSPAM"@student.ifpan.edu.pl>
On the Sat, 04 Jul 2009 12:25:50 -0500, A.L wrote:
> On Sat, 4 Jul 2009 17:02:53 +0000 (UTC), "Mariusz Marszałkowski"
><b...@W...gazeta.pl> wrote:
>>
>>Można też tak napisać kod, aby małą strukturę w całości załadować do
>>pamięci cache.
>
> Ze co?
http://en.wikipedia.org/wiki/Locality_of_reference
RW
-
15. Data: 2009-07-04 17:45:18
Temat: Re: liczby dużej (nie dowolnej) precyzji
Od: "Mariusz Marszałkowski" <b...@W...gazeta.pl>
A.L. <a...@a...com> napisał(a):
> On Sat, 4 Jul 2009 17:02:53 +0000 (UTC), "Mariusz Marszałkowski"
> <b...@W...gazeta.pl> wrote:
>
> >A.L. <a...@a...com> napisał(a):
> >
> >> On Sat, 4 Jul 2009 16:34:04 +0000 (UTC), Roman Werpachowski <"r o m a
> >> nNOSPAM"@student.ifpan.edu.pl> wrote:
> >>
> >> >
> >> >Kod ktory moze zalozyc ze macierz jest 5x5 moze zostac bardziej
> >> >zoptymalizowany niz kod, ktory musi obslugiwac macierz dowolnych rozmiarow.
> >> >Na tym polega sila takich bibliotek jak http://tvmet.sourceforge.net/
> >>
> >> Ze mozna rozwinac petle? Mozna
> >>
> >
> >Można też tak napisać kod, aby małą strukturę w całości załadować do
> >pamięci cache.
>
> Ze co?
W książce pod poniższym linkiem:
http://www.lideria.pl/Programowanie-optymalizacja-ko
du-Efektywne-wykorzystanie-pamieci-Kris-Kaspersky/sk
lep/opis?nr=65324
jest rozdział: "Optymalizacja pamięci podręcznej i dostępu do pamięci".
Zaczyna się on tak: "Bez wątpienia, im mniejsze są tablice danych, tym
szybciej są one przetwarzane (można domniemać że autorowi chodzi o
szybsze w stosunku do rozmiaru). Aby osiągnąć maksymalną wydajność, należy
tak zaprojektować algorytm programu, aby wszystkie najintensywniej
przetwarzane dane mieściły się w pamięci podręcznej L1 lub przynammniej
w pamięci podręcznej L2. W przeciwnym przypadku intensywan wymiana danych
z pamięcią główną pochłonie cały czas procesora."
Pozdrawiam
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
-
16. Data: 2009-07-04 18:29:13
Temat: Re: liczby dużej (nie dowolnej) precyzji
Od: Michoo <m...@v...pl>
Mariusz Marszałkowski pisze:
> Witam
>
> Pierwsze pytanie: Jak sądzicie, jaka jest różnica w wydajności pomiędzy
> biblioteką liczb dowolnej precyzji, a biblioteką liczb dużej precyzji. Np.
> w bibliotece dowolnej precyzji ustalamy dokładność na 40 liczb znaczących
> (w systemie dziesiątkowym), a bibliotekę liczb dużej precyzji implementujemy
> tylko i wyłącznie do obsługi liczb 40 cyfrowych. Jeśli biblioteka ma obsługiwać
> tylko i wyłącznie jedną precyzję, to wydaje się że może być znacznie
> wydajniejsza. No i właśnie jak sądzicie, czy taka implementacja może być
> dużo wydajniejsza?
>
> Drugie pytanie: czy są dostępne biblioteki do obsługi typu zmiennoprzecinkowego
> o rozmiarze np. 30-60 cyfr znaczących?
To jest już "dowolnej" długości. Tzn. właściwie wszystko co nie mieści
się w typie obsługiwanym natywnie przez procesor będzie wymagało jakiejś
rekurencji/iteracji.
Co więcej może się okazać, że (poza jakimiś chorymi rzeźbami w asm na
konkretną architekturę) biblioteka obsługująca 24-240 bitów będzie
wolniejsza dla tych 240 bitów niż biblioteka o dowolnej precyzji.
--
Pozdrawiam
Michoo
-
17. Data: 2009-07-04 18:38:52
Temat: Re: liczby dużej (nie dowolnej) precyzji
Od: A.L. <a...@a...com>
On Sat, 4 Jul 2009 17:45:18 +0000 (UTC), "Mariusz Marszałkowski"
<b...@W...gazeta.pl> wrote:
>W przeciwnym przypadku intensywan wymiana danych
>z pamięcią główną pochłonie cały czas procesora."
Naprawde tak napisal?... A jak mam wektory ktore zamuja wiecej niz
cache, to zanczy nei da sie policzyc?...
A.L.
-
18. Data: 2009-07-04 18:39:50
Temat: Re: liczby dużej (nie dowolnej) precyzji
Od: Roman Werpachowski <"r o m a nNOSPAM"@student.ifpan.edu.pl>
On the Sat, 04 Jul 2009 13:38:52 -0500, A.L wrote:
> On Sat, 4 Jul 2009 17:45:18 +0000 (UTC), "Mariusz Marszałkowski"
><b...@W...gazeta.pl> wrote:
>
>>W przeciwnym przypadku intensywan wymiana danych
>>z pamięcią główną pochłonie cały czas procesora."
>
> Naprawde tak napisal?... A jak mam wektory ktore zamuja wiecej niz
> cache, to zanczy nei da sie policzyc?...
To nie sa wtedy krotkie.
RW
-
19. Data: 2009-07-04 18:41:54
Temat: Re: liczby dużej (nie dowolnej) precyzji
Od: A.L. <a...@a...com>
On Sat, 4 Jul 2009 17:38:14 +0000 (UTC), Roman Werpachowski <"r o m a
nNOSPAM"@student.ifpan.edu.pl> wrote:
>On the Sat, 04 Jul 2009 12:25:50 -0500, A.L wrote:
>> On Sat, 4 Jul 2009 17:02:53 +0000 (UTC), "Mariusz Marszałkowski"
>><b...@W...gazeta.pl> wrote:
>>>
>>>Można też tak napisać kod, aby małą strukturę w całości załadować do
>>>pamięci cache.
>>
>> Ze co?
>
>http://en.wikipedia.org/wiki/Locality_of_reference
>
>RW
"Wsycko piknie" jak mawial Baca. Ale ja mam dynamiczny graf ktory
zajmuje pol gigabajta. I robie wyszykwianie na tym grafie. I jak wtedy
zapewnic "locality"?... Wedle Kasperskiego nei da sie takiego problemu
rozwiazac, bo procesor caly czas spedzi na kopiowaniu danych
A.L.
-
20. Data: 2009-07-04 18:56:03
Temat: Re: liczby dużej (nie dowolnej) precyzji
Od: Roman Werpachowski <"r o m a nNOSPAM"@student.ifpan.edu.pl>
On the Sat, 04 Jul 2009 13:41:54 -0500, A.L wrote:
> On Sat, 4 Jul 2009 17:38:14 +0000 (UTC), Roman Werpachowski <"r o m a
> nNOSPAM"@student.ifpan.edu.pl> wrote:
>
>>On the Sat, 04 Jul 2009 12:25:50 -0500, A.L wrote:
>>> On Sat, 4 Jul 2009 17:02:53 +0000 (UTC), "Mariusz Marszałkowski"
>>><b...@W...gazeta.pl> wrote:
>>>>
>>>>Można też tak napisać kod, aby małą strukturę w całości załadować do
>>>>pamięci cache.
>>>
>>> Ze co?
>>
>>http://en.wikipedia.org/wiki/Locality_of_reference
>>
>>RW
>
> "Wsycko piknie" jak mawial Baca. Ale ja mam dynamiczny graf ktory
> zajmuje pol gigabajta.
No to nie jest *mala*.
> I robie wyszykwianie na tym grafie. I jak wtedy
> zapewnic "locality"?...
Nie znam sie na algorytmach przeszukiwania grafów, ale nie da sie tego
zapisac tak, zeby algortym potrzebowal w danej chwili tylko kawalka grafu,
ktory sie miesci w cache?
>Wedle Kasperskiego nei da sie takiego problemu
> rozwiazac, bo procesor caly czas spedzi na kopiowaniu danych
Skoro ludzie takich grafów uzywaja, to widac daja sobie rade z tym
problemem.
RW