🚀 go-pugleaf

On 21 Paź, 21:09, Leonard Milcin <leon...@milcin.dont-spam.pl> wrote:
> jarekr wrote:
> > On 21 Paź, 00:39, Abece <abece.inac...@abece.pl> wrote:
> >> Poprawione. java znów dostaje w dupę. 171ms vs 31ms.
>
> > [Ciach ]
>
> > W końcu odrobiłeś zadanie domowe.
> > Nie podajesz co prawda parametrów kompilatora javy - ale wyznik pasuje
> > do defaultowych.
> > 171ms jest cokolwiek różne od 22 Sekunc :-)
> > No a teraz zadanie numer 2 - zwiększamy n 100 razy:
> > czyli
> > int n=200000000;
> > I prosze o wyniki.!!!
>
> > Pocieszę Cię od razu - nie martw się gcc od wersji (przynajmniej)
> > 3.4. w górę wychodzi na szybsze od
> > sun jvm server - aczkolwiek to nie jest 171 do 31 - spradwdż sobie.
> > Acha. żeby nie było.  jeśli Ci nie działa w C++ n=200000000 to  łatwo
> > to naprawisz.
>
> > Uznaję za porażkę, że sunowski jvm daje się bić jakiemuś gcc. ( u
> > mnie, w warunkach "normalnych"  około 36%).
>
> Wasze ,,benchmarki'' i różne takie dociekiwania są g**** warte i mają
> nic wspólnego z metodą naukową.

Zapewniam Cię, że się bez sesnu przypieprzasz. Zajmuję się zawodowo
optymalizowaniem programów
- zasadniczo w javie i dość dobrze znam różnego rodzaju pułapki i
problemy.
Fakt, mój czas nie pozwala mi na przeprowadzenie dla tego zagadnienia
poważnych pomiarów (nikt mi nie zapłaci).
Tym niemniej podane  tutaj zagadnienie  jest dość proste i zasadniczo
sprowadza do postaci kodu maszynowego jaki powstaje w obu
kompilatorach.
(mierzę czas już na skompilowanym kodzie w JVM  ).
Jak mi starczy troche czasu to przyjrze się różnicom (-XX:
+PrintAssembly). (Tu zagadnienie jest o tyle proste, że w podanym
kodzie nie musi działać GC ).

> Przygotowywanie tego rodzaju testów jest bardzo delikatną sprawą bo
> trzeba wziąć pod uwagę znacznie więcej współczynników niż zdajecie sobie
> sprawy a nawet wtedy interpretacja wyników nie jest tak prosta jak
> wskazanie kierunku relacji większości.
NIkt tu nie  o jakiejś poważnej interpretacji wyników - oprócz trollka
- nie mówi.
Osobiście ciekawi mnie gdzie co gcc robi lepiej od C2 na  podanym
kawałku kodu. (bo może trzeba mu coś poprawić :-) ).

Tak przy okazji.
W sumie parę ciekawych wyników mam przy okazji tego zagadnienia.
Np. bardzo zawiodłem się na implementacji System arraycopy.
Z dobrych rzeczy natomiast  - w Dolphin (java 7.0) sensownie
przeorganizowali ( w źródłach JVM) - kompilację
native wrapperów.(library_call.cpp). Teraz dodanie (na poziomie kodu
JVM) nowych jest dość proste i można się spodziewać
że w niedalekiej przyszłości dużo nowych funkcji z jdk będzie miało
native wrappery bez JNI zrobione (czyli tak jak Math.sin i inne).



--
jarekr