On Mon, 18 May 2009 13:47:20 +0200, Jędrzej Dudkiewicz
<j...@g...com> wrote:

>Maciej Sobczak wrote:
>> On 18 Maj, 09:35, Wojciech Muła <w...@p...onet.pl> wrote:
>>
>>>>> Wówczas można spróbować asynchroniczne I/O.
>>>> I wtedy się szybciej dysk kręci?
>>> Bez sensu się czepiasz. W kontekście problemu Kolegi (duża ilość
>>> danych),
>>> asynchroniczne I/O może pomóc.
>>
>> Nadal chciałbym wiedzieć dlaczego.
>
>Ponieważ dane są pobierane równolegle z wykonaniem programu. Nie wierzę,
>żebyś nie wiedział o co chodzi, więc rozumiem, że przeczytałeś coś
>świetnego w mądrej książce i tylko czekasz, żeby zaprezentować :)
>Dajesz, dajesz :)
>
>JD

Tia... tylko jak sie puszcza dwa procesy na jednym procesorze to kazdy
z nich zabierze swoja czesc czasu procesora plus administracja, wiec
wszystko ma szanse dzialac wolniej... o ile procedor nie jest
multicore... co nei jest zreszta automatycznei gwarancja ze bedzie
dzialac szybciej...

A.L.

do góry

bartekLTG wrote:
> Maciej Pilichowski wrote:
>> aby zawsze pisac ++var zamiast
>> var++ (o ile merytorycznie nie zachodzi koniecznosc tego drugiego),
>
> Im dluzej o tym mysle, tym bardziej nie rozumiem, o co Ci mogło chodzic;-)

O ile pamiętam "rationale", to w C++ do iteracji winien być używany
iterator. Będący obiektem, potencjalnie dużym i skomplikowanym. Kiedy w
kodzie pojawia się "var++", w to miejsce należy zwrócić "starą" wartość
var, a następnie zaaplikować operator++ na var, kiedy pojawia się ++var,
nie trzeba zwracać kopii.

JD

do góry

On 17.05.2009, Maciej Pilichowski wrote:
> Jacek Czerwinski wrote:
>
>> W konkluzji:
>> I) nie optymalizować.
>
> Nie zgodze sie. Czesc optymalizacji mozna zrobic w zasadzie nie myslac, jak
> np. przyzwyczajenie sie, aby zawsze pisac ++var zamiast var++ (o ile
> merytorycznie nie zachodzi koniecznosc tego drugiego),

Z dokładnością do tego że kompilator doskonale poradzi sobie z takim
no-thinking.

> dwa ze czesc
> optymalizacji jest trywialnych, jak np.
>
> int x;
> vs
> static int x;
>
> (tu mocno przejaskrawiam oczywiscie)

To nie jest optymalizacja. Albo zmienna x jest lokalna, wtedy
static int x to zupełnie inny byt, albo to zmienna globalna, a wtedy
ustatycznienie jej ukryje ten symbol dla dostępu z zewnątrz. Tak czy
siak zmieniasz mocno zastosowanie zmiennej, co nijak mi się nie mieści
w definicji trywialnej optymalizacji.


> trzy, ze czesc programow bez optymalizacji po prostu nie skonczy dzialac,

#define nie skończy działać.

Ręcznie optymalizować kodu się nie opłaca dopóki nie zlokalizowałeś
wąskich gardeł i nie zoptymalizowałeś użytych tam algorytmów.

--
Stanislaw Klekot

do góry

A.L. wrote:
> On Mon, 18 May 2009 13:47:20 +0200, Jędrzej Dudkiewicz
> <j...@g...com> wrote:
>
>> Maciej Sobczak wrote:
>>> On 18 Maj, 09:35, Wojciech Muła <w...@p...onet.pl> wrote:
>>>
>>>>>> Wówczas można spróbować asynchroniczne I/O.
>>>>> I wtedy się szybciej dysk kręci?
>>>> Bez sensu się czepiasz. W kontekście problemu Kolegi (duża ilość
>>>> danych),
>>>> asynchroniczne I/O może pomóc.
>>> Nadal chciałbym wiedzieć dlaczego.
>> Ponieważ dane są pobierane równolegle z wykonaniem programu. Nie wierzę,
>> żebyś nie wiedział o co chodzi, więc rozumiem, że przeczytałeś coś
>> świetnego w mądrej książce i tylko czekasz, żeby zaprezentować :)
>> Dajesz, dajesz :)
>
> Tia... tylko jak sie puszcza dwa procesy na jednym procesorze to kazdy
> z nich zabierze swoja czesc czasu procesora plus administracja, wiec
> wszystko ma szanse dzialac wolniej... o ile procedor nie jest
> multicore... co nei jest zreszta automatycznei gwarancja ze bedzie
> dzialac szybciej...

Znaczy, nie rozumiem. Przy AIO nie musimy mieć dwóch procesów ani
wątków, dane są, jak rozumiem, pobierane w tle bez udziału procesora i
przy małym udziale kontrolera pamięci, przy pomocy takich wynalazków jak
DMA.

Głównie to nie rozumiem, skąd ta uwaga o dwóch procesach w tym kontekście.

JD

do góry

On Mon, 18 May 2009 14:58:31 +0200, Jędrzej Dudkiewicz
<j...@g...com> wrote:

>A.L. wrote:
>> On Mon, 18 May 2009 13:47:20 +0200, Jędrzej Dudkiewicz
>> <j...@g...com> wrote:
>>
>>> Maciej Sobczak wrote:
>>>> On 18 Maj, 09:35, Wojciech Muła <w...@p...onet.pl> wrote:
>>>>
>>>>>>> Wówczas można spróbować asynchroniczne I/O.
>>>>>> I wtedy się szybciej dysk kręci?
>>>>> Bez sensu się czepiasz. W kontekście problemu Kolegi (duża ilość
>>>>> danych),
>>>>> asynchroniczne I/O może pomóc.
>>>> Nadal chciałbym wiedzieć dlaczego.
>>> Ponieważ dane są pobierane równolegle z wykonaniem programu. Nie wierzę,
>>> żebyś nie wiedział o co chodzi, więc rozumiem, że przeczytałeś coś
>>> świetnego w mądrej książce i tylko czekasz, żeby zaprezentować :)
>>> Dajesz, dajesz :)
>>
>> Tia... tylko jak sie puszcza dwa procesy na jednym procesorze to kazdy
>> z nich zabierze swoja czesc czasu procesora plus administracja, wiec
>> wszystko ma szanse dzialac wolniej... o ile procedor nie jest
>> multicore... co nei jest zreszta automatycznei gwarancja ze bedzie
>> dzialac szybciej...
>
>Znaczy, nie rozumiem. Przy AIO nie musimy mieć dwóch procesów ani
>wątków, dane są, jak rozumiem, pobierane w tle bez udziału procesora i
>przy małym udziale kontrolera pamięci, przy pomocy takich wynalazków jak
>DMA.

BEz udzialu procesora?...

Proponuje sobie zobaczyc zrodla do asynchroncznego IO w Javie na
przyklad, i zastanowic sie jak te zrodla mozna zapuscic na DMA.

A.L.

do góry

"bartekLTG" <b...@o...ciach.pl> wrote in message
news:gurkis$5d7$1@news.onet.pl...
> Maciej Pilichowski wrote:
>> aby zawsze pisac ++var zamiast
>> var++ (o ile merytorycznie nie zachodzi koniecznosc tego drugiego),
>
> Im dluzej o tym mysle, tym bardziej nie rozumiem, o co Ci mogło chodzic;-)

O uniknięcie tworzenia tymczasowego obiektu, jest to szczególnie istotne
przy
optymalziacji użycia iteratorów.

Pozdrawiam
--
Mateusz Loskot, http://mateusz.loskot.net
pl.comp.lang.c FAQ: http://pl.cpp.wikia.com/wiki/FAQ
C++ FAQ: http://parashift.com/c++-faq-lite

do góry

On Mon, 18 May 2009 14:24:50 +0100, "Mateusz Loskot"
<m...@l...net> wrote:

>"bartekLTG" <b...@o...ciach.pl> wrote in message
>news:gurkis$5d7$1@news.onet.pl...
>> Maciej Pilichowski wrote:
>>> aby zawsze pisac ++var zamiast
>>> var++ (o ile merytorycznie nie zachodzi koniecznosc tego drugiego),
>>
>> Im dluzej o tym mysle, tym bardziej nie rozumiem, o co Ci mogło chodzic;-)
>
>O uniknięcie tworzenia tymczasowego obiektu, jest to szczególnie istotne
>przy
>optymalziacji użycia iteratorów.
>

Jakiego obiektu?...

A.L.

do góry

"A.L." <a...@a...com> wrote in message
news:7fp215hi0ri3dg0joavei9c38r9si7kn6b@4ax.com...
> On Mon, 18 May 2009 14:24:50 +0100, "Mateusz Loskot"
> <m...@l...net> wrote:
>
>>"bartekLTG" <b...@o...ciach.pl> wrote in message
>>news:gurkis$5d7$1@news.onet.pl...
>>> Maciej Pilichowski wrote:
>>>> aby zawsze pisac ++var zamiast
>>>> var++ (o ile merytorycznie nie zachodzi koniecznosc tego drugiego),
>>>
>>> Im dluzej o tym mysle, tym bardziej nie rozumiem, o co Ci mogło
>>> chodzic;-)
>>
>>O uniknięcie tworzenia tymczasowego obiektu, jest to szczególnie istotne
>>przy
>>optymalziacji użycia iteratorów.
>>
>
> Jakiego obiektu?...


Tymczasowego, o takim samym typie jak 'var', utworzonego i zwróconego
przez operator post-inkrementacji.

Pozdrawiam
--
Mateusz Loskot, http://mateusz.loskot.net
pl.comp.lang.c FAQ: http://pl.cpp.wikia.com/wiki/FAQ
C++ FAQ: http://parashift.com/c++-faq-lite

do góry

On Mon, 18 May 2009 14:59:48 +0100, "Mateusz Loskot"
<m...@l...net> wrote:

>"A.L." <a...@a...com> wrote in message
>news:7fp215hi0ri3dg0joavei9c38r9si7kn6b@4ax.com...
>> On Mon, 18 May 2009 14:24:50 +0100, "Mateusz Loskot"
>> <m...@l...net> wrote:
>>
>>>"bartekLTG" <b...@o...ciach.pl> wrote in message
>>>news:gurkis$5d7$1@news.onet.pl...
>>>> Maciej Pilichowski wrote:
>>>>> aby zawsze pisac ++var zamiast
>>>>> var++ (o ile merytorycznie nie zachodzi koniecznosc tego drugiego),
>>>>
>>>> Im dluzej o tym mysle, tym bardziej nie rozumiem, o co Ci mogło
>>>> chodzic;-)
>>>
>>>O uniknięcie tworzenia tymczasowego obiektu, jest to szczególnie istotne
>>>przy
>>>optymalziacji użycia iteratorów.
>>>
>>
>> Jakiego obiektu?...
>
>
>Tymczasowego, o takim samym typie jak 'var', utworzonego i zwróconego
>przez operator post-inkrementacji.
>

Wszystko co Kolega pisze jest gleboko sluszne, jezeli zostanie
uzupelnione nastepujacym tekstem: "w przypadku gdy operator ++ jest
overlaoded, na ogol operacja prefiksowa jest bardziej efektywna od
postfiksowej. Nie ma to jednak znaczenai dla operacji ++ na typach
elementarnych"

A.L.

do góry

A.L. wrote:
> On Sun, 17 May 2009 12:19:56 +0200, Jacek Czerwinski <...@...z.pl> wrote:
>
>> I) nie optymalizować.
>
> Nieprawda. Optymalizowac:
>
> a. Gdy program dziala za wolno
>
> b. Posluzyc sie regula "20% kodu konsumuje 80% czasu wykonania".
> Znalezc te 20% i zoptymalizowac.
>
> c. Go to a.

Domyślam się, że to, co przedpiśca chciał powiedzieć, zawiera się
w "a", tylko przy odwróceniu warunku: "Jeśli program nie działa za wolno
- nie optymalizować".

--
Paweł Kierski
n...@p...net

do góry