Re: priorytet procesu

Autor: Radosław Sokół <Radoslaw.Sokol_at_polsl.pl>
Data: Thu 01 Feb 2007 - 15:10:32 MET
Message-ID: <epssco$l6m$1@polsl.pl>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed

Tomasz Bątor napisał(a):
> Bo Java stała się bardzo popularna, więc i ludzi ją wychwalających jest
> więcej.

No ale na tej zasadzie wychwalanie będzie na podstawie "bo jest
na tyle prosta, że udało mi się nauczyć", a nie na bazie jakichś
merytorycznych uwag. A tego należy unikać. Jak Stroustrup powie-
dział, niedobrze jest, gdy języki stają się proste tak, że
dużo ludzi jest w stanie się ich nauczyć.

> Cały czas używasz argumentu o straszliwej powolności Javy, który nijak
> ma się do rzeczywistości. To jest *mit*. Wolno działający program można

Nie mit.

Pamiętaj, że od kilku dobrych lat szybkość programu to nie
jest realizacja kodu, tylko rozmiar kodu. Na poziomie makro
rozmiar kodu wpływa na wymagania wobec sprzętu oraz na
częstotliwość swapowania. Na poziomie mikro wpływa na
wymagania wobec rozmiaru cache oraz częstotliwość występo-
wania nietrafień w cache. Dlatego zaleca się optymalizowanie
pod kątem rozmiaru, a nie szybkości.

Tutaj języki JIT/VM mają problem, gdyż realizacja programu
wymaga równoczesnego dostępu do czterech obszarów: maszyny
wirtualnej, p-kodu, kodu skompilowanego JIT i obszaru danych
(w uproszczeniu). Kod maszynowy wymaga tylko dwóch ostatnich
elementów (od biedy funkcji bibliotecznych jeszcze, ale tam
sterowanie przekazywane jest w sposób periodyczny). Dopiero
w momencie, gdy praktycznie cały p-kod jest przekompilowany,
całość działa z prawie pełną wydajnością (aczkolwiek nie wiem,
czy JITy kiedykolwiek kompilują faktycznie wszystko), choć
sama VM musi dalej działać, bo obsługuje choćby GC.

Ponadto, w przypadku Javy (i częściowo C#) wchodzi problem GUI.
Zamiast wywoływać funkcje systemowe, obecne w DLLach zawsze
w samym systemie i *BARDZO* silnie zoptymalizowane przez
producenta systemu (przynajmniej takie powinny być, w Windows
na ich szybkość nie można raczej narzekać, w GTK jest różnie),
oba środowiska rysują okienka w zasadzie na własną rękę,
czasem wręcz za pomocą własnych funkcji (nie wiem czy Java
ma Swinga zakodowanego w C, czy w Javie). W efekcie narzuty
wydajnościowe przenoszą się na GUI, a tu to widać wyraźniej
(no i kod maszyny wirtualnej znów puchnie o biblioteki
graficzne dublujące coś, co jest w samym systemie przecież).

O ile zatem zgodzę się z Tobą, że wydajność *obliczeniowa*
aplikacji napisanej np. w Javie prawie dorównuje C++, to
wydajność *postrzegana*, wywodząca się z czasu rysowania
zawartości okien oraz z zajętości pamięci wirtualnej i
fizycznej jest *znacząco* gorsza.

-- 
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  http://www.grush.one.pl/              |
|                 |  Administrator, Politechnika Śląska    |
\................... Microsoft MVP ......................../
Received on Thu Feb 1 15:15:08 2007

To archiwum zostało wygenerowane przez hypermail 2.1.8 : Thu 01 Feb 2007 - 15:42:01 MET