On 19 Maj, 10:32, Jędrzej Dudkiewicz <j...@g...com>
wrote:

> > Czyli mówimy *w ogólności* o wykorzystaniu *współbieżności* w celu
> > lepszego wykorzystania zasobów.
>
> No dobra, ale sprawdź jeszcze raz odpowiedź Wojtka Muły, podał
> informację o AIO w momencie, kiedy było wiadomo, że:
> a) same obliczenia długo trwają
> b) dużo czasu zajmuje czekanie na dane.
>
> Wniosek: jest szansa, że AIO pomoże.
>
> W tym momencie odpowiedź "możesz użyć współbieżności" jest mniej pomocne
> od konkretniejszego rozwiązania, czyli podania hasła o asynchronicznym I/O.

Wątki będą gorsze?

Nie znamy kontekstu, ale spróbujmy z takim utrudnieniem: I/O jest
opakowane w istniejący kod (nazwijmy go modnie "persistency layer").
Zauważamy, że można coś policzyć w trakcie czekania na dane. Co
robimy?
(hint: w realu ten problem wystąpi np. formie komunikacji z DB, albo
interakcji w systemie rozproszonym, nie tylko w kontekście operacji z
dyskiem)

Asynchroniczne I/O jest, owszem, konkretnym rozwiązaniem w temacie
współbieżności. Problem w tym, że rozwiązaniem bardzo intruzywnym[*] i
słabo komponowalnym. Tzn. da się to zrobić nawet bardzo elegancko,
jeśli całość jest pisana *od zera*, ale nie podjąłbym się tego w
ramach refaktoryzacji czy optymalizacji istniejącego kodu.

[*] Czasami ta intruzywność jest tak daleka, że kompletnie wyklucza
takie rozwiązanie. Zwłaszcza jeśli chodzi o interakcje client-server
przy użyciu istniejących bibliotek czy frameworków.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

do góry

Maciej Sobczak wrote:
> On 19 Maj, 10:32, Jędrzej Dudkiewicz <j...@g...com>
> wrote:
>
>>> Czyli mówimy *w ogólności* o wykorzystaniu *współbieżności* w celu
>>> lepszego wykorzystania zasobów.
>> No dobra, ale sprawdź jeszcze raz odpowiedź Wojtka Muły, podał
>> informację o AIO w momencie, kiedy było wiadomo, że:
>> a) same obliczenia długo trwają
>> b) dużo czasu zajmuje czekanie na dane.
>>
>> Wniosek: jest szansa, że AIO pomoże.
>>
>> W tym momencie odpowiedź "możesz użyć współbieżności" jest mniej pomocne
>> od konkretniejszego rozwiązania, czyli podania hasła o asynchronicznym I/O.
>
> Wątki będą gorsze?

Do AIO? Oczywiście, że będą gorsze. AIO jako usługa kernela jest szybsza
niż kolejny wątek w userlandzie. Nie, nie mam danych statystycznych.

> Nie znamy kontekstu,

Ależ oczywiście, że znamy, w pierwszym poście OP napisał co i jak, pisze
od początku, dużo danych, dużo obliczeń itd, itp. Odpowiedź, że może
pomóc AIO jest jak najbardziej na miejscu, mi tylko o to chodzi!

JD

do góry

Dnia Tue, 19 May 2009 09:37:11 +0200, Paweł Kierski napisał(a):

> To trochę jak zakład Newtona - też można twierdzić, że nie da się
> uzasadnić wyboru, bo kontekst (istnienie Boga) nie jest znany. Ale
> podobnie jak w zakładzie, tak i tu, przyjmujemy rozwiązanie
> maksymalizujące zysk.

Newtona na metr kwadratowy czyli Pascala ;)

--
GLaF

do góry

Jędrzej Dudkiewicz pisze:
> Maciej Sobczak wrote:
>> On 19 Maj, 10:32, Jędrzej Dudkiewicz <j...@g...com>
>> wrote:
>>
>>>> Czyli mówimy *w ogólności* o wykorzystaniu *współbieżności* w celu
>>>> lepszego wykorzystania zasobów.
>>> No dobra, ale sprawdź jeszcze raz odpowiedź Wojtka Muły, podał
>>> informację o AIO w momencie, kiedy było wiadomo, że:
>>> a) same obliczenia długo trwają
>>> b) dużo czasu zajmuje czekanie na dane.
>>>
>>> Wniosek: jest szansa, że AIO pomoże.
>>>
>>> W tym momencie odpowiedź "możesz użyć współbieżności" jest mniej pomocne
>>> od konkretniejszego rozwiązania, czyli podania hasła o
>>> asynchronicznym I/O.
>>
>> Wątki będą gorsze?
>
> Do AIO? Oczywiście, że będą gorsze. AIO jako usługa kernela jest szybsza
> niż kolejny wątek w userlandzie. Nie, nie mam danych statystycznych.
Mówimy chyba o wątkach (kernel) a nie "włóknach" z userlandu?

"Zwykłe" io też jest usługą kernela (np. wywołanie DMA)

Ja widzę te 2 przedstawione możliwości tak:
1. Mamy wątek, który asynchronicznie odbiera dane i po "uzbieraniu"
odpowiedniej porcji je przetwarza. Na jednym procesorze mamy
wykorzystanie go na ~100%, przy 2 procesorach (b, częste dzisiaj) nadal
mamy wykorzystanie jednego procesora .
2. Mamy 2 wątki w jeden "wisi" na i/o (a wiec nie jest nawet brany pod
uwagę przez sheduler). Drugi przetwarza dane. Na jednoprocesorowej
maszynie wykorzystają max ~99% (1% na zmiany kontekstu przy
synchronicznym i/o to i tak za dużo). Na 2 wykorzystają max 2*100%.

>
>> Nie znamy kontekstu,
>
> Ależ oczywiście, że znamy, w pierwszym poście OP napisał co i jak, pisze
> od początku, dużo danych, dużo obliczeń itd, itp. Odpowiedź, że może
> pomóc AIO jest jak najbardziej na miejscu, mi tylko o to chodzi!
Imo wielowątkowość może pomóc. Samo AIO nie da prawie nic - zaoszczędzi
jedynie czas transferu z bufora do pamięci w porównaniu do 1 wątku z
synchronicznym io+poll, w przypadku więcej wątków czas zmiany kontekstu.
Na dzisiejszym sprzęcie - 2+ rdzenie - aio bez wątków będzie wolniejsze
niż operacje synchroniczne+wątki.

--
Pozdrawiam
Michoo

do góry

On 19 Maj, 13:45, Jędrzej Dudkiewicz <j...@g...com>
wrote:

> > Wątki będą gorsze?
>
> Do AIO? Oczywiście, że będą gorsze. AIO jako usługa kernela jest szybsza
> niż kolejny wątek w userlandzie.

Dlaczego jest szybsza? Dysk się wtedy szybciej kręci?
Mówimy o transferze danych, reszta jest kompletnie nieistotna albo
dokładnie równoważna.
W obu przypadkach kiedyś tam jakiś wątek musi być powiadomiony
(czytaj: zmienia się stan jakiegoś obiektu synchronizacyjnego), że
transfer się zakończył. Wtedy kod userlandu wie, że może te dane
wykorzystać.
Co mi daje AIO?

> > Nie znamy kontekstu,
>
> Ależ oczywiście, że znamy, w pierwszym poście OP napisał co i jak, pisze
> od początku,

Nie, pisze "część do większego programu". :-)

Utrudnienie jak poprzednio: w tym "większym programie" I/O już jest
zrobione. Powiedzmy data persistency framework.
Przerabiamy na AIO?

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

do góry

On 19 Maj, 20:20, Michoo <m...@v...pl> wrote:

> Samo AIO nie da prawie nic - zaoszczędzi
> jedynie czas transferu z bufora do pamięci

Dlaczego? Myślisz, że przy AIO nie trzeba tego transferu robić?
Trzeba, inaczej użytkownik z tych danych nie skorzysta.

char my_buffer[my_size];

Niezależnie od metody dane muszą być przetransferowane z/do my_buffer.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

do góry

A.L. wrote:
> umozliwiajace "rozwineicie" petli na szeregowu kod zawierajacj kolejne
> "wnetrza" petli. Likwiduje sie w ten sposob narzut zwiazany z
> wykonywaniem petli.
>
> Podsumowujac: mniej koku i wielokrotne uzycie kodu spowalnei program a
> nei przyspiesza"

Rozwinięcie pętli to nie to samo co powtarzanie kodu, a reszta to jest
oczywiście bzdura.

Kolega A.L. jest znany z tego że "nigdy się nie myli", a mnie szkoda
czasu, więc rezygnuję z ostatniego słowa.


B.



PS. no code is faster than no code.

--
Remove -trap- when replying. Usun -trap- gdy odpisujesz.

do góry

Maciej Sobczak pisze:
> On 19 Maj, 20:20, Michoo <m...@v...pl> wrote:
>
>> Samo AIO nie da prawie nic - zaoszczędzi
>> jedynie czas transferu z bufora do pamięci
>
> Dlaczego? Myślisz, że przy AIO nie trzeba tego transferu robić?
> Trzeba, inaczej użytkownik z tych danych nie skorzysta.
DMA
>
> char my_buffer[my_size];
>
> Niezależnie od metody dane muszą być przetransferowane z/do my_buffer.
W przypadku dobrej implementacji (na gruncie czystej teorii - nie chce
mi się teraz zastanawiać gdzie to jak jest zaimplementowane - chodzi mi
o sam fakt, że jest to jedyny zysk jaki można osiągnąć) i/o kopiowanie
danych na drodze dysk->ram, bufor karty sieciowej-> ram, etc powinno być
robione "na zewnątrz" procesora (i to w trybie nie odcinającym go od szyny).

synchroniczne i/o: program robi wywołanie systemowe "czytaj" system
wywala wątek z kolejki procesów gotowych i zleca kontrolerowi transfer,
po otrzymaniu przerwania od kontrolera proces wraca do kolejki i w
najbliższym czasie wraca z wywołania

asynchroniczne i/o: program robi wywołanie systemowe "czytaj" system
zleca kontrolerowi transfer, wątek powraca z wywołania i może pracować.
po otrzymaniu przerwania od kontrolera system powiadamia wątek o
zakończeniu operacji.

W drugim przypadku wątek może pracować w trakcie kopiowania danych.


--
Pozdrawiam
Michoo

do góry

On Tue, 19 May 2009 21:41:39 +0100, Bronek Kozicki <b...@s...net>
wrote:

>A.L. wrote:
>> umozliwiajace "rozwineicie" petli na szeregowu kod zawierajacj kolejne
>> "wnetrza" petli. Likwiduje sie w ten sposob narzut zwiazany z
>> wykonywaniem petli.
>>
>> Podsumowujac: mniej koku i wielokrotne uzycie kodu spowalnei program a
>> nei przyspiesza"
>
>Rozwinięcie pętli to nie to samo co powtarzanie kodu, a reszta to jest
>oczywiście bzdura.

Nie slyszales o procedurach "inline"? Odswiez sobie pamiec

Inline expansion is used to eliminate the time overhead when a
function is called. It is typically used for functions that execute
frequently. It also has a space benefit for very small functions, and
is an enabling transformation for other optimizations

http://en.wikipedia.org/wiki/Inline_function

Czy slyszales o partial evaluation" Jak nie

In computing, partial evaluation is a technique for several different
types of program optimization by specialization. The most
straightforward application is to produce new programs which run
faster than the originals but are guaranteed to behave in the same
way. More advanced uses include compiling by partially evaluating an
interpreter with the program to be compiled as its input; generating
compilers by partially evaluating a partial evaluator with an
interpreter for the source language concerned as its input; and
finally generating a compiler-generator by partially evaluating a
partial evaluator with itself as its input.

http://en.wikipedia.org/wiki/Partial_evaluation

Poczytaj sobie ksaizke "Generative Programming, Methods, Tools and
Applications", Krzysztof Czarnecki i Ulrich W. Eisenecker, Addison
Wesley 2000. Jak nei bedziesz wiedzial ktore rozdzialy, to ci wsaze

>
>Kolega A.L. jest znany z tego że "nigdy się nie myli", a mnie szkoda
>czasu, więc rezygnuję z ostatniego słowa.

ja nei napisalem ze "jestes glupi" a tylko ze "nei masz racji". Ty
zas, nie mogac wykazac ze nie mam racji, napisales ze A.L. jest glupi"
Za to idziesz do KF

A.L.

do góry

On May 19, 11:48 am, "Mateusz Loskot" <m...@l...net> wrote:
> > albo co jest szybsze: int array[10] czy int *array = new int[10].
>
> Pierwsze to alokacja na stosie, drugie na tzw. stercie (dynamic storage)
> Ogólna zasada przy optymalizacji, to im mniej alokacji pamięci
> tym lepiej. Alokacja to wolna operacja.

To co zrobić, żeby unikać konstrukcji spowalniających program? Pamięci
muszę używać, a żeby używać - muszę chyba jakoś ją zaalokować.

MR

do góry