🚀 go-pugleaf

On 22 Paź, 20:52, Marcin Mielżyński <l...@gazeta.pl> wrote:

>
> Tu nie ma żadnego jni i wcale niewiele się zmieni w 7ce. Metody typu
> "arraycopy", "indexOf", "hashCode" etc, to są tzw intrinsics
> (vmSymbols.hpp) (Nawet InvokeDynamic bazuje na intrinsics a nie na
> dodatkowym rozkazie, np MethodHandle, AnonymousClassLoader, czy pool
> patchery). One są bezpośrednio stubowane w natywny kod, ale przedtem ich
> argumenty podlegają takim samym optymalizacjom jak np. GVN na grafie
> SSA/MachNode jak normalny kod (przy "arraycopy" następuje nawet
> eliminacja sprawdzeń zasięgu dla tablic, czy src > 0 itp).

Dokładnie o tym napisałem. Jeszcze w kodzie mustanga
(library_calls.cpp) - to był niezły syf  i dopisanie własnego
intrinsica było co najmniej toporne -  a w 7ce zostało całkiem ładnie
uporządkowane - więc już się zmieniło,
bo mogę sobie choćby na potrzeby testów o wiele łatwiej coś dopisać.
(trochę requestów jest o dopisanie "native wrapperów" przy kilku
funkcjach (z Arrays choćby) widziałem) .


> W przypadku tego benchmarku pechowy jest OSR, czyli rekompilacja w locie
> (w czasie działania pętli) i resynchronizacja ramki interpretera i stosu
> natywnego.

U siebie ten czynnik wyeliminowałem od razu - dokładnie poprzez
wprowadzenie małych metod (wywaliłem też bitset). I  doszedłem do kodu
prawie tak szybkiego jak w C++ (na 100 razy większym n - żeby miało
sens mierzenie). (gdzieś na początku tej dyskusji chyba listing tak
przerobiony z dodaniem warmupu podałem)

Generalnie udało mi się uzyskać wersję w javie działającą na 7.5
sekundy (tablica boolean zamiast bitset, wydzielone metody. warmup) -
przy czym na tym samym sprzęcie  wersja GCC dawało mi 5.5sekundy
(około).

I na koniec dziś porównywałem listingi  +PrintOptoAssembly z wersją z
gcc.
Niestety nie starczyło mi czasu na analizę juz - ale chyba problem
jest w zupełnie śmiesznym miejscu.
Skubaniec (C2) nie wyłączył range_check na tablicach. i wrzuca w
każdym przebiegu pętli sprawdzenie górnego zakresu. .

                         while(k<=n)
                        {
                                b.clear(k); (u mnie tu przerzuciłem
na b[k] = false; (żeby wywalić bitset)
                                k = k + i;
                        }

Zachodzi podejrzenie - (cokolwiek wydaje mi się dziwne) - że to może
być ten narzut( ale to jest bardzo jeszcze niesprawdzone).  Niestety
nie wiem czy będę miał czas żeby to dokładnie sprawdzić.
Przede wszystkim  nie bardzo rozumiem dlaczego nie wywalił range
checka - chcę to zdebugować (nie wiem jakie są zasady dokładne
eliminacji range_check ale kod (JVM) w tym miejscu jest dość
przejrzysty  -więc się dowiem) .
--
jarekr