Hey

Mam plik z danymi. Plik jest duzy i nie miesci sie w pamieci ram.
Na danych wykonuje wielokrotnie podobne obliczenia i plik w
niezmienionej postaci jest wiele razy odczytywany. Za kazdym razem
odczytywany jest caly, sekwencyjnie, od poczatku do konca. Dane
w pliku to rekrody o stalym rozmairze.

Moje pytanie: co mozna zrobic, zeby proces przyspieszyc? Wykonywanie
obliczenia na rekordach sa bardzo proste i absolutnie nie sa waskim
gardlem.

Mysle nad kilkoma usprawnieniami.
1) Mozna wczytac do ram tyle ile sie zmiesci, a reszte czytac bezposrednio z
pliku. Ale od razu mam obawe, czy system operacyjny nie robi tego lepiej?
Lepiej wylaczyc cache systemu i zrobic wlasny czy lepiej polegac na
systemie?
2) Kompresja danych, ale jaka? Dane bardzo dobrze sie kompresuja, nawet
30krotnie. Ale czy to sie oplaci? Odczytow bedzie mniej, ale trzeba
stracic czas na dekompresje.
3) Czy warto kupic szybki dysk np. taki oparty o pamiec flash?
4) A moze warto kupic np. 10 zwyklych dyskow i aplikacje uruchomic w
10-ciu watkach?

Z gory dziekuje za wszelkie zainteresowanie.
Pozdrawiam
P.S.
Jakby kogos interesowalo czym sa dane w tym pliku, to sa logi z rozgrywek
szachowych.






--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 2011-12-05, M.M. <m...@g...pl> wrote:
> Mam plik z danymi. Plik jest duzy i nie miesci sie w pamieci ram.
> Na danych wykonuje wielokrotnie podobne obliczenia i plik w
> niezmienionej postaci jest wiele razy odczytywany. Za kazdym razem
> odczytywany jest caly, sekwencyjnie, od poczatku do konca. Dane
> w pliku to rekrody o stalym rozmairze.
>
> Moje pytanie: co mozna zrobic, zeby proces przyspieszyc? Wykonywanie
> obliczenia na rekordach sa bardzo proste i absolutnie nie sa waskim
> gardlem.

Wykonywać po kilka obliczeń na rekordzie naraz.

> Mysle nad kilkoma usprawnieniami.
> 1) Mozna wczytac do ram tyle ile sie zmiesci, a reszte czytac bezposrednio z
> pliku. Ale od razu mam obawe, czy system operacyjny nie robi tego lepiej?
> Lepiej wylaczyc cache systemu i zrobic wlasny czy lepiej polegac na
> systemie?
> 2) Kompresja danych, ale jaka? Dane bardzo dobrze sie kompresuja, nawet
> 30krotnie. Ale czy to sie oplaci? Odczytow bedzie mniej, ale trzeba
> stracic czas na dekompresje.
> 3) Czy warto kupic szybki dysk np. taki oparty o pamiec flash?
> 4) A moze warto kupic np. 10 zwyklych dyskow i aplikacje uruchomic w
> 10-ciu watkach?

--
Secunia non olet.
Stanislaw Klekot

do góry

Stachu 'Dozzie' K. <d...@g...eat.some.screws.spammer.invalid> napisał(a):

> > Moje pytanie: co mozna zrobic, zeby proces przyspieszyc? Wykonywanie
> > obliczenia na rekordach sa bardzo proste i absolutnie nie sa waskim
> > gardlem.
>
> Wykonywać po kilka obliczeń na rekordzie naraz.
Racja. Dopoki wyniki czesciowe mieszcza sie w ram, to mozna
je zapamietywac. Moich wynikow czesciowych zmiesci sie duzo...
rzedu 10tys. Czyzby to oznaczalo przyspieszenie rzedu 10tys razy? :)
Dzieki


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 12/05/2011 05:38 PM, M.M. wrote:
> Hey
>
> Mam plik z danymi. Plik jest duzy i nie miesci sie w pamieci ram.
> Na danych wykonuje wielokrotnie podobne obliczenia i plik w
> niezmienionej postaci jest wiele razy odczytywany. Za kazdym razem
> odczytywany jest caly, sekwencyjnie, od poczatku do konca. Dane
> w pliku to rekrody o stalym rozmairze.
>
> Moje pytanie: co mozna zrobic, zeby proces przyspieszyc? Wykonywanie
> obliczenia na rekordach sa bardzo proste i absolutnie nie sa waskim
> gardlem.
>
> Mysle nad kilkoma usprawnieniami.
> 1) Mozna wczytac do ram tyle ile sie zmiesci, a reszte czytac bezposrednio z
> pliku. Ale od razu mam obawe, czy system operacyjny nie robi tego lepiej?
> Lepiej wylaczyc cache systemu i zrobic wlasny czy lepiej polegac na
> systemie?
> 2) Kompresja danych, ale jaka? Dane bardzo dobrze sie kompresuja, nawet
> 30krotnie. Ale czy to sie oplaci? Odczytow bedzie mniej, ale trzeba
> stracic czas na dekompresje.
> 3) Czy warto kupic szybki dysk np. taki oparty o pamiec flash?
> 4) A moze warto kupic np. 10 zwyklych dyskow i aplikacje uruchomic w
> 10-ciu watkach?
>
> Z gory dziekuje za wszelkie zainteresowanie.
> Pozdrawiam
> P.S.
> Jakby kogos interesowalo czym sa dane w tym pliku, to sa logi z rozgrywek
> szachowych.

hejka,

Twoim wąskim gardłem jest więc sekwencyjny odczyt z dysku. z sensowych
operacji programowych proponuję:
1) kompresję danych. CPU jest zdecydowanie szybsze niż dysk, więc się to
opłaca, szczególnie że w Twoim przypadku obliczenia są proste, więc
procesor się nudzi przez sporą część czasu.
2) osobny wątek czytający dane do bufora i osobny wątek liczący. nawet
jeśli liczenie jest szybkie, czemu w tym samym czasie nie czytać?
3) zgrupować obliczenia. jeśli się da, czytając plik wykonywać więcej
obliczeń jednocześnie, na tych samych blokach. oczywiście, czy tak się
da, zależy od użycia.
4) w nowszych jajkach jest wywołanie, mówiące jak duży będzie plik,
podczas tworzenia - niestety nie pamiętam teraz jak się tego używa. :/
5) upewnij się, że format pliku jest odpowiednio kompaktowy. w którejś
książce Suttera, o C++, był zaproponowany format, gdzie pojedynczy ruch
oznaczał tylko kilka bitów (zmian względem poprzedniego stanu szachownicy).

ponieważ odczyt jest sekewncyjny (na poziomie fs - fizycznie bywa
różnie) dysk SSD może nie dać dużych przyśpieszeń (kwestia do
zmierzenia), za to jest dużo droższy. być może sensowniej będzie kupić w
tej samej cenie kilka SATA i połączyć je w RAID1 (mirror)? zależnie od
możliwości konkretnej implementacji RAIDa może to przyspieszyć czytanie
z jednego wątku, lub wymagać użycia wielu, by w pełni wykorzystać
sprzęt (a przyspieszenie idzie tu praktycznie liniowo z liczbą dysków).

pilnuj też, by dyski nie były przepełnione - kiedy kończy się miejsce na
dysku, zawodzą pewne heurystyki rozmieszania danych fs-ów i dane są
mocniej rozproszone do nośniku, co dramatycznie pogarsza odczyt (częste
ruchy głowicy).

oczywiście jeśli to bardzo krytyczne, możesz zrezygnować z systemu
plików i zapisać plik bezpośrednio na urządzeniu blokowym - fs też ma
swoje narzuty.

tyle na szybko. potestuj, pomierz i zrób wykresy z porównaniem różnych
podejść. taka analiza graficzna przeważnie uwypukla najlepsze
rozwiązania. :)

--
pozdrawiam serdecznie / best regards,
Bartek 'BaSz' Szurgot

http://www.baszerr.org

do góry

> 2) osobny wątek czytający dane do bufora i osobny wątek liczący. nawet
> jeśli liczenie jest szybkie, czemu w tym samym czasie nie czytać?

Zakładając, że problemem jest wydajność dysku czyli CPU Load < 100%,
stworzenie drugiego wątku coś da? Nie obrażam, tylko czy w tej sytuacji,
coś to pomoże? Algorytm podejścia stanie się bardziej poprawny,
uniwersalny ale w tym przypadku, to raczej to niczego nie zmieni.

--
Mateusz Bogusz

do góry

Dnia 05-12-2011 o 17:38:11 M.M. <m...@g...pl> napisał(a):

> Hey
>
> Mam plik z danymi. Plik jest duzy i nie miesci sie w pamieci ram.
> Na danych wykonuje wielokrotnie podobne obliczenia i plik w
> niezmienionej postaci jest wiele razy odczytywany. Za kazdym razem
> odczytywany jest caly, sekwencyjnie, od poczatku do konca. Dane
> w pliku to rekrody o stalym rozmairze.
>
> Moje pytanie: co mozna zrobic, zeby proces przyspieszyc? Wykonywanie
> obliczenia na rekordach sa bardzo proste i absolutnie nie sa waskim
> gardlem.
>
> Mysle nad kilkoma usprawnieniami.
> 1) Mozna wczytac do ram tyle ile sie zmiesci, a reszte czytac
> bezposrednio z
> pliku. Ale od razu mam obawe, czy system operacyjny nie robi tego
> lepiej?
> Lepiej wylaczyc cache systemu i zrobic wlasny czy lepiej polegac na
> systemie?
> 2) Kompresja danych, ale jaka? Dane bardzo dobrze sie kompresuja, nawet
> 30krotnie. Ale czy to sie oplaci? Odczytow bedzie mniej, ale trzeba
> stracic czas na dekompresje.
> 3) Czy warto kupic szybki dysk np. taki oparty o pamiec flash?
> 4) A moze warto kupic np. 10 zwyklych dyskow i aplikacje uruchomic w
> 10-ciu watkach?
>
> Z gory dziekuje za wszelkie zainteresowanie.
> Pozdrawiam
> P.S.
> Jakby kogos interesowalo czym sa dane w tym pliku, to sa logi z rozgrywek
> szachowych.

może warto by rozważyć zamiast:

for item in file:
f1(item)
for item in file:
f2(item)
for item in file:
f3(item)

takie coś:

for item in file:
f1(item)
f2(item)
f3(item)

?
--
Jordan Szubert

do góry

Jordan Szubert <u...@j...us.to> napisał(a):
> zamiast:
>
> for item in file:
> f1(item)
> for item in file:
> f2(item)
> for item in file:
> f3(item)
>
> takie co=B6:
>
> for item in file:
> f1(item)
> f2(item)
> f3(item)

Tak, prawdopodobnie to rozwiazanie z powrotem przerzuci waskie gardlo z
dysku na obliczenia w ram. Nie wiem czemu mi to do glowy nie przyszlo :)
Dzieki wszystkim.


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 12/05/2011 06:11 PM, Karol Y wrote:
>> 2) osobny wątek czytający dane do bufora i osobny wątek liczący. nawet
>> jeśli liczenie jest szybkie, czemu w tym samym czasie nie czytać?
>
> Zakładając, że problemem jest wydajność dysku czyli CPU Load < 100%,
> stworzenie drugiego wątku coś da? Nie obrażam, tylko czy w tej sytuacji,
> coś to pomoże? Algorytm podejścia stanie się bardziej poprawny,
> uniwersalny ale w tym przypadku, to raczej to niczego nie zmieni.

może pomóc. ile? zależy od proporcji io/cpu. generalna zasada mówi, by
(powolne) I/O realizować w osobnym wątku. chodzi o to, by możliwie
najefektywniej wykorzystać zasoby.

załóżmy, że 80% czasu wykonania to I/O a 20% CPU. oznacza to, iż program
czytający i przetwarzający sekwencyjnie, przez 80% używa (niemal)
wyłącznie dysku a przez 20% (niemal) wyłącznie CPU. efektywnie - przez
20% czasu nie używasz dysku, na który będziesz zaraz czekał. jeśli
podzielisz to na 2 wątki, robisz (wolne) I/O cały czas (wątek czytający
będzie większość czasu oczekiwał) - również wtedy, kiedy liczysz, czyli
"odczuwalnie" będziesz krócej czekał na I/O.

oczywiście w praktyce nie jest tak źle - systemy mają swoje bufory,
czytają więcej, niż jest w danej chwili potrzebne, etc... nie mniej
robienie tego w osobnym wątku jest zawsze jakimś przyspieszeniem.
zależnie od aplikacji i konkretnych proporcji może to być kilka procent,
albo i kilkaset. ale to już trzeba zmierzyć w konkretnym przypadku. :)

--
pozdrawiam serdecznie / best regards,
bartek szurgot
/* http://www.baszerr.org */

do góry

On 12/05/2011 06:03 PM, bartek szurgot wrote:
> zmierzenia), za to jest dużo droższy. być może sensowniej będzie kupić w
> tej samej cenie kilka SATA i połączyć je w RAID1 (mirror)? zależnie

Raczej RAID0, RAID1 niewiele pomaga w szybkości odczytu, przynajmniej
soft-raid. RAID0 i RAID5 na kilku dyskach - u mnie przynajmniej -
daje "niezłego kopa" w sekwencyjnym.

Edek

do góry

On 12/05/2011 08:15 PM, Edek wrote:
> On 12/05/2011 06:03 PM, bartek szurgot wrote:
>> zmierzenia), za to jest dużo droższy. być może sensowniej będzie kupić w
>> tej samej cenie kilka SATA i połączyć je w RAID1 (mirror)? zależnie
>
> Raczej RAID0, RAID1 niewiele pomaga w szybkości odczytu, przynajmniej
> soft-raid. RAID0 i RAID5 na kilku dyskach - u mnie przynajmniej -
> daje "niezłego kopa" w sekwencyjnym.

to zależy od użycia i implementacji RAIDa. mam soft-RAID1 (2 dyski) na
jednej ze stacji i przy odczytach z jednego procesu idzie przepustowość
pojedynczego dysku, jednak 2 równoległe odczyty idą (łącznie) 2x
przepustowością pojedynczego dysku. zapis oczywiście pozostaje bez zmian.

--
pozdrawiam serdecznie / best regards,
bartek szurgot
/* http://www.baszerr.org */

do góry