🚀 go-pugleaf

Jaroslaw Zabiello wrote:
>>> Weź odpal sobie taką Vistę od zera i to dodaj do czasu wykonania 
>>> programu. Wyjdzie na to samo albo nawet i gorzej. Bo narzut startu 
>>> JVM można zlikwidować Nailgunem. A narzutu startu Windowsów, czy 
>>> Linuksa nie zlikwidujesz w żaden sposób.
>>
>> O czy ty tu?!?
> 
> Owszem. Zapoznaj się z terminem: Nailgun.

No i? Co ma JVM do Windowsów czy Linuksa?

Czemu sam go nie użyłeś prezentując swój microbenchmark?

Poza tym, widzę że nadal ignorujesz fakt że w przypadku Pythona też masz 
koszt załadowania i uruchomienia "całego środowiska Pythona").

To nie moja wina, że Sun zrobił (spieprzył) Javę w ten sposób, że jej 
środowisko waży tony.

BTW. zdążyłem już zauważyć, że podniecasz się "terminami" bez zgłębienia 
sprawy. Ot, taka obserwacja na boku.



>> Nie odpalami Windowsów ani Linuksa tylko zwykły rantajm języka wraz z 
>> jego maszyną wirtualną. I to w obu wypadkach (i Javy i Pythona).
>>
>>
>>>>> Poza tym, rozgrzanie HotSpota jest kluczowe bo pełną wydajność 
>>>>> osiąga gdzieś po przekroczeniu 5 iteracji.
>>>>
>>>> To już sobie z palca ssiesz
>>>  A ty to ślepy jesteś? Weź odpal ten sam kod z -J-server i bez. Widać 
>>> gołym okiem różnice jak wykonanie kolejnych pętl jest coraz szybsze.
>>
>> Ssiesz z palca, że akurat 5 iteracji. To zależy od kodu.
> 
> To czepiasz się tylko liczby 5? LOL. Dobra, nie będę się przy niej 
> upierał, jeśli ci tylko o to chodzi. Natomiast będę się upierał, że  
> odpalanie nie rozgrzanego HotSpota jak i odpalanie za każdym razem JVM 
> bez Nailguna (skoro się upierasz żeby za każdym razem ładować całe 
> środowisko Javy) i używanie takiej metody do pokazywania "jaka ta java 
> jest wolna" jest po prostu głupie.

Co mi po rozgrzanym hotspocie, jeśli w real life nie będzie rozgrzany?
I owszem w real-life często nie jest rozhgrzany. W sofcie serwerowym też.

Po co mi piąty raz liczenie od zero pierwszych 35000 liczb fibonnaciego?

> 
>>>> BTW w wielu przypadkach program coś liczący wykonywany jest raz.
>>>  Wtedy nie będzie tego efektu, zgoda. Dlatego JVM rządzi na serwerach.
>>
>> Zwłaszcza jak na serwerze (a raczej wielu równolegle pracujących 
>> serwerach) chodzi np. interfejs webowy banku -- ot 1000 formatek, z 
>> czego wiele używanych z rzadka. Potem zdziwienie, że kod w jakimś tam 
>> Perlu działa zdecydowanie szybciej (mniej pamięci żre, klientom się 
>> szybciej wyświetla).

Widzę że nie dotarło.

Podkręcam jasność:

Jak masz 1000 różnych formatek z czego wiele rzadko używanych to efekt 
jest taki, że HotSpot ich nie będzie kompilował tylko zostawi 
interpretowane. W efekcie czego użytkownik będzie odczuwał paskudną 
ślamazarność serwisu w mniej używanych jego fragmentach.

> 
> Jak aplikacja jest źle napisana, to nic jej nie pomoże.

Przyjmij, że jest dobrze napisana.

> Java pracując 
> serwletowo jest dużo szybsza od serwerków pracujących w trybie cgi. 

Co ma do tego wszystkiego CGI?

> Oczywiście serwletowo pracujący Python też będzie szybszy niż 
> analogiczny PHP który niszczy i tworzy wszystkie obiekty za każdym 
> requestem. Różnica będzie tym większa im większy kod.
> 

Co to ma do tego o czym napisałem?

pzdr
\SK

-- 
"Never underestimate the power of human stupidity" -- L. Lang
-- 
http://www.tajga.org -- (some photos from my travels)