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.