epsilon$ while read LINE; do echo \>"$LINE"; done < "Andrzej Jarzabek"
>> >W skali czego? Całego oprogramowania, które się tworzy? Nie mam
>> >widzialności w takiej skali, ale mam mocne podejrzenie, że całkiem spora
>> >część oprogramowania powstającego na świecie to oprogramowanie telefonów
>> >komórkowych, set-top boxów czy innych trafostacji, gdzie w ogóle nie ma
>> >opcji "dołożyć kolejny serwer".
>> I sądzisz, że na współczesne komórki tak się kombinuje w asemblerze, jak
>> trzydzieści lat temu na 8051?
>A napisałem coś, co by to sugerowało?

Owszem. Sugerujesz prostą dychotomię "optymalizacja uber
alles"<->pure evil.

--
d'`'`'`'`'`'`'`'`'`'`'`'`'Yb
`b K...@e...eu.org d'
d' http://epsilon.eu.org/ Yb
`b,-,.,-,.,-,.,-,.,-,.,-,.d'

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "A.L"
>>>>>>> Drugą sprawą jest to, że przy dokładaniu kolejnego serwera ograniczeiem
>>>>>>> nie jest cena samego serwera, tylko zasoby serwerowni.
>>>>>> Oczywiście. Takie problemy też _bywają_.
>>>>>> Owszem, istnieje klasa problemów, których optymalizacja (poza "zdrowy
>>>>>> rozsądek") ma sens. Ale w praktycznych zastosowaniach to nie jest aż tak
>>>>>> wielki margines.
>>>>>W skali czego? Całego oprogramowania, które się tworzy? Nie mam
>>>>>widzialności w takiej skali, ale mam mocne podejrzenie, że całkiem spora
>>>>>część oprogramowania powstającego na świecie to oprogramowanie telefonów
>>>>>komórkowych, set-top boxów czy innych trafostacji, gdzie w ogóle nie ma
>>>>>opcji "dołożyć kolejny serwer".
>>>>I sądzisz, że na współczesne komórki tak się kombinuje w asemblerze, jak
>>>>trzydzieści lat temu na 8051?
>>>Dodatkowy serwer tez mozna dolozyc?
>>Do komórki? Wątpię. Co nie zmienia faktu, że przeciętny twórca programu
>>na komórkę nie będzie się zastanawiał czy zajmie 15, czy 18% czasu
>>procesora.
>Dlatego komorki tak dziaja jak dzialaja.
>
>Tak na marginesie,zdarzylo mi sie pare razy liczyc nanosekundy w
>srodku petli. W zwyklej aplikacji a nie w komorce

I co ma wynikać z tego anecdotal evidence?
Sądzisz, że przeciętny klient będzie przeszczęśliwy jak po wydaniu
ciężkich k$ i straceniu miesięcy dowie się, że program działa o 1%
szybciej?

--
Kruk@ -\ |
}-> epsilon.eu.org |
http:// -/ |
|

do góry

Mariusz Kruk wrote:

> Do komórki? Wątpię. Co nie zmienia faktu, że przeciętny twórca programu
> na komórkę nie będzie się zastanawiał czy zajmie 15, czy 18% czasu
> procesora.

Mi nie chodzi nawet o optymalizacje dające 20, czy 30%. Chodzi o to, że
wielu programistów kierując się zasadą "sprzęt jest tani" ignoruje nawet
najbardziej oczywiste objawy, pokazujące że tworzony przez nich w taki a nie
inny sposób program będzie beznadziejnie wolny.
To że często nie opłaca się walczyć o 20% wydajności to się zgadzam. Ale już
o przyspieszenie dziesięciokrotne - warto. Niby da się przeżyć, że
użytkownik musi czekać kilka sekund na operację, która bez jakiejś
nadzwyczajnej optymalizacji mogła by się wykonać w czasie poniżej 100ms.
Tylko dlaczego robić taki chłam, skoro przy podobnym wysiłku da się to
zrobić wydajniej.

do góry

On Mon, 20 Dec 2010 19:07:06 +0100, Mariusz Kruk
<M...@e...eu.org> wrote:

>epsilon$ while read LINE; do echo \>"$LINE"; done < "A.L"
>>>>>>>> Drugą sprawą jest to, że przy dokładaniu kolejnego serwera ograniczeiem
>>>>>>>> nie jest cena samego serwera, tylko zasoby serwerowni.
>>>>>>> Oczywiście. Takie problemy też _bywają_.
>>>>>>> Owszem, istnieje klasa problemów, których optymalizacja (poza "zdrowy
>>>>>>> rozsądek") ma sens. Ale w praktycznych zastosowaniach to nie jest aż tak
>>>>>>> wielki margines.
>>>>>>W skali czego? Całego oprogramowania, które się tworzy? Nie mam
>>>>>>widzialności w takiej skali, ale mam mocne podejrzenie, że całkiem spora
>>>>>>część oprogramowania powstającego na świecie to oprogramowanie telefonów
>>>>>>komórkowych, set-top boxów czy innych trafostacji, gdzie w ogóle nie ma
>>>>>>opcji "dołożyć kolejny serwer".
>>>>>I sądzisz, że na współczesne komórki tak się kombinuje w asemblerze, jak
>>>>>trzydzieści lat temu na 8051?
>>>>Dodatkowy serwer tez mozna dolozyc?
>>>Do komórki? Wątpię. Co nie zmienia faktu, że przeciętny twórca programu
>>>na komórkę nie będzie się zastanawiał czy zajmie 15, czy 18% czasu
>>>procesora.
>>Dlatego komorki tak dziaja jak dzialaja.
>>
>>Tak na marginesie,zdarzylo mi sie pare razy liczyc nanosekundy w
>>srodku petli. W zwyklej aplikacji a nie w komorce
>
>I co ma wynikać z tego anecdotal evidence?
>Sądzisz, że przeciętny klient będzie przeszczęśliwy jak po wydaniu
>ciężkich k$ i straceniu miesięcy dowie się, że program działa o 1%
>szybciej?

Niestety, to nie byla kwesta 1 procenta, a kwestia tego czy bedzie
chodzil 10 godzin czy 2 godziny. Wystarczy te niepotzrebne nanosekundy
powtarzac dostatecznie duza ilosc razy

Gdyby chodzil 10 godzin, mozna by ow program o kant d... roztluc bo
wyniki potzrebne byly w ciagu 4 godzin. To sie nazywqa "real time
computing"

A.L.

do góry

On 20/12/2010 18:05, Mariusz Kruk wrote:
> epsilon$ while read LINE; do echo \>"$LINE"; done< "Andrzej Jarzabek"
>>>> W skali czego? Całego oprogramowania, które się tworzy? Nie mam
>>>> widzialności w takiej skali, ale mam mocne podejrzenie, że całkiem spora
>>>> część oprogramowania powstającego na świecie to oprogramowanie telefonów
>>>> komórkowych, set-top boxów czy innych trafostacji, gdzie w ogóle nie ma
>>>> opcji "dołożyć kolejny serwer".
>>> I sądzisz, że na współczesne komórki tak się kombinuje w asemblerze, jak
>>> trzydzieści lat temu na 8051?
>> A napisałem coś, co by to sugerowało?
>
> Owszem. Sugerujesz prostą dychotomię "optymalizacja uber
> alles"<->pure evil.

Nie chcę rozkręcać flejma, więc napiszę łagodnie: kompetnie nie zrozumiałeś.

do góry

W dniu 2010-12-20 21:13, Wojciech Jaczewski pisze:
> Mariusz Kruk wrote:
>
>> Do komórki? Wątpię. Co nie zmienia faktu, że przeciętny twórca programu
>> na komórkę nie będzie się zastanawiał czy zajmie 15, czy 18% czasu
>> procesora.
>
> Mi nie chodzi nawet o optymalizacje dające 20, czy 30%. Chodzi o to, że
> wielu programistów kierując się zasadą "sprzęt jest tani" ignoruje nawet
> najbardziej oczywiste objawy, pokazujące że tworzony przez nich w taki a nie
> inny sposób program będzie beznadziejnie wolny.
> To że często nie opłaca się walczyć o 20% wydajności to się zgadzam. Ale już
> o przyspieszenie dziesięciokrotne - warto.

Nie jestem zwykle 'niskopoziomowcem' tzn zwykle nie szukam mikrosekund,
ale pamietam pierwszy pomierzony wynik na gruncie Javy String+String
kontra StringBuilder. Niby wiedzialem, ze tak TRZEBA i ma byc szybciej,
ale liczby rzucily mnie na kolana. Petla, normalna apliakacyjna petla w
czynnosciami, wykonala sie z 5 razy szybciej.

Wiec mysle w "masowym" kodzie wystarczylyby na poczatek dobre wzorce
(best practices), czyli ten fajny przekaz miedzy programistami TAK
TRZEBA. (Tylko jeden problem: jak odsiac zle wzorce pokutujace w
srodowiskach :( )

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "A.L"
>>>Tak na marginesie,zdarzylo mi sie pare razy liczyc nanosekundy w
>>>srodku petli. W zwyklej aplikacji a nie w komorce
>>I co ma wynikać z tego anecdotal evidence?
>>Sądzisz, że przeciętny klient będzie przeszczęśliwy jak po wydaniu
>>ciężkich k$ i straceniu miesięcy dowie się, że program działa o 1%
>>szybciej?
>Niestety, to nie byla kwesta 1 procenta, a kwestia tego czy bedzie
>chodzil 10 godzin czy 2 godziny. Wystarczy te niepotzrebne nanosekundy
>powtarzac dostatecznie duza ilosc razy
>
>Gdyby chodzil 10 godzin, mozna by ow program o kant d... roztluc bo
>wyniki potzrebne byly w ciagu 4 godzin. To sie nazywqa "real time
>computing"

Po raz kolejny - i co ma wynikać z tego anecdotal evidence?
Czy ja gdzieś pisałem, że nigdy nie zdarzy się sytuacja, w której nawet
ten jeden procent byłby istotny?
Kluczowe w moim zdaniu było "przeciętny".

--
d'`'`'`'`'`'`'`'`'`'`'`'`'Yb
`b K...@e...eu.org d'
d' http://epsilon.eu.org/ Yb
`b,-,.,-,.,-,.,-,.,-,.,-,.d'

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Wojciech Jaczewski"
>> Do komórki? Wątpię. Co nie zmienia faktu, że przeciętny twórca programu
>> na komórkę nie będzie się zastanawiał czy zajmie 15, czy 18% czasu
>> procesora.
>Mi nie chodzi nawet o optymalizacje dające 20, czy 30%. Chodzi o to, że
>wielu programistów kierując się zasadą "sprzęt jest tani" ignoruje nawet
>najbardziej oczywiste objawy, pokazujące że tworzony przez nich w taki a nie
>inny sposób program będzie beznadziejnie wolny.

Czy ja gdzieś pisałem, że nigdy nie należy optymalizować? Owszem, jeśli
ktoś wszystko sortuje bąbelkowo, bo inaczej nie umie i nie jest w stanie
zrozumieć, że można inaczej, zapewnie w życiu nie napisze kawałka
dobrego kodu. Tego oczywiście nie neguję. Ale już zastanawianie się nad
kolejnością porównań żeby zyskać kilka procent szybkości przy sortowaniu
kosztem zaciemnienia kodu będzie miało sens tylko w pewnych konkretnych
przypadkach.

>To że często nie opłaca się walczyć o 20% wydajności to się zgadzam.

Ano właśnie.

>Ale już
>o przyspieszenie dziesięciokrotne - warto.

Czasami. Czasami nie. Czasem prościej jest napisać skrypt w bashu, niż
pier.*ić się z C. On i tak będzie uruchamiany raz na rzadko i to, czy
się będzie wykonywać minutę, czy dziesięć nie ma takiego znaczenia, jak
to czy widać co się w nim dzieje.
Co - z drugiej strony - nie zwalnia piszącego taki skrypt od uważania na
to, co robi. (find . -type f -exec cat {} \; anyone?)

>Niby da się przeżyć, że
>użytkownik musi czekać kilka sekund na operację, która bez jakiejś
>nadzwyczajnej optymalizacji mogła by się wykonać w czasie poniżej 100ms.
>Tylko dlaczego robić taki chłam, skoro przy podobnym wysiłku da się to
>zrobić wydajniej.

Owszem. Czasami tak jest. Czasami inny koszt jest po prostu
istotniejszy.

--
[------------------------]
[ K...@e...eu.org ]
[ http://epsilon.eu.org/ ]
[------------------------]

do góry

On 2010-12-21, Andrzej Jarzabek <a...@g...com> wrote:
> On 20/12/2010 18:05, Mariusz Kruk wrote:
>> epsilon$ while read LINE; do echo \>"$LINE"; done< "Andrzej Jarzabek"
>>>>> W skali czego? Całego oprogramowania, które się tworzy? Nie mam
>>>>> widzialności w takiej skali, ale mam mocne podejrzenie, że całkiem spora
>>>>> część oprogramowania powstającego na świecie to oprogramowanie telefonów
>>>>> komórkowych, set-top boxów czy innych trafostacji, gdzie w ogóle nie ma
>>>>> opcji "dołożyć kolejny serwer".
>>>> I sądzisz, że na współczesne komórki tak się kombinuje w asemblerze, jak
>>>> trzydzieści lat temu na 8051?
>>> A napisałem coś, co by to sugerowało?
>>
>> Owszem. Sugerujesz prostą dychotomię "optymalizacja uber
>> alles"<->pure evil.
>
> Nie chcę rozkręcać flejma, więc napiszę łagodnie: kompetnie nie zrozumiałeś.

To ja też kompletnie nie zrozumiałem. Może to jednak ty coś źle
przedstawiłeś?

--
Secunia non olet.
Stanislaw Klekot

do góry

Mariusz Kruk wrote:

> Czy ja gdzieś pisałem, że nigdy nie należy optymalizować? Owszem, jeśli
> ktoś wszystko sortuje bąbelkowo, bo inaczej nie umie i nie jest w stanie
> zrozumieć, że można inaczej, zapewnie w życiu nie napisze kawałka
> dobrego kodu. Tego oczywiście nie neguję. Ale już zastanawianie się nad
> kolejnością porównań żeby zyskać kilka procent szybkości przy sortowaniu
> kosztem zaciemnienia kodu będzie miało sens tylko w pewnych konkretnych
> przypadkach.

Akurat sortowanie nie jest chyba dobrym przykładem, bo mało kto rezygnuje ze
skorzystania z funkcji bibliotecznej. Zwykle te niewydajne rozwiązania
powstają dla mniej książkowych problemów.

>>To że często nie opłaca się walczyć o 20% wydajności to się zgadzam.
>
> Ano właśnie.

I tu jest właśnie ciekawostka... Rzeczywistość pokazuje nam oprócz programów
szybkich, oraz niezłych ale nie optymalizowanych intensywnie (czyli
wolniejszych o np. kilkadziesiąt procent), także wiele programów
beznadziejnie powolnych. Natomiast przy okazji prawie każdej dyskusji na
temat praktyki robienia powolnych programów ich obrońcy mówią o 1-5-10-15% o
które nie warto walczyć.
Jakby podyskutować na temat wydajności takiej np. Javy z jakimś jej
miłośnikiem, też zazwyczaj zacznie wywody o tanim sprzęcie i o tym że nie
opłaca się walczyć o każdy procent wydajności - gdy tymczasem każdy nie-
zaślepiony miłością do tego języka widzi, że w rzeczywistych programach
różnice wydajności są kilkukrotne, a nie rzędu pojedynczych procentów.

Ja staram się po prostu uzupełnić dyskusję na temat wydajności o przypadki o
których zazwyczaj się przy takiej okazji nie wspomina.

do góry