> On 08/17/2011 11:56 PM, m...@t...pl wrote:

> To ja ci powiem, że został popełniony jeden generalny. Kiedyś faktycznie
> optymalizacja to assembler albo bardzo blisko. Dzisiaj, fakt, jakieś
Nie chcę powiedzieć że umiem się perfekcyjnie posługiwać kompilatorami.
Po prostu - przyszedł mi pomysł do głowy, napisałem, zmierzyłem czas,
gdy było szybciej to zostawiałem, gdy wolniej to cofałem.

> multimedia i podobne niektórzy jeszcze rzeźbią w assemblerze, czy
> też wstawki typu atomiki, których dotychczas nie było, i ok. Natomiast
> większość optymalizacji - o ile wiem - to umiejętne użycie kompilatora.
> Czasami wydaje mi się, że niektórzy nie uświadomili sobie, że
> zarówno procki i kompilatory "deczko" się zmieniły przez ostatnie
> dziesięć lat. Oczywiście, niektóre rzeczy były i są kosztowne,
> trzeba kod pisać inaczej, żeby kompilator mógł go optymalizować,
> bo robi tylko te przekształcenia, które może zrobić mając dostępne
> założenia - zazwyczaj wystarczy mu przeszkody usunąć z drogi. Nie jest
> to darmo, ale nie ma to większego wpływu na pisanie poprawnego
> kodu. Range check w przypadku większych pętli zazwyczaj sprowadza się
> do jednorazowego >=start <end - co i tak kompilator musi zrobić,
> żeby np. wygenerować prologi przekształconych pętli, więc taki check
> w kodzie źródłowym paradoksalnie ułatwia mu pracę (ok, jak to zwykle
> z optymalizacjami bywa: czasami, nie zawsze, zależy, itd.).
Nie wiem... dawno nie jestem na bieżąco z nowymi prockami i kompilatorami.
Jak pisałem wyżej, bazowałem na eksperymencie - zmiana kodu i pomiar czasu.


> Co do optymalizacji i Javy, to różnie mówią. Znam testy gdzie Java i C++
> były podobne. Znam takie, gdzie Java była wolniejsza. Znam też takie,
> że w HPC używają Javy, ale tylko ze słyszenia - kiedyś googlnę, nie
> spędza mi to snu z powiek łagodnie mówiąc.
Java używa wszędzie new, nie można położyć statycznego obiektu na stosie.
Mocno rozrzuca dane po przestrzeni adresowej. Słabo działa cache, a sama
alokacja trochę czasu też zajmuje. To są trzy wady wydajnościowe Javy:
częsta allokacja, słabo działa cache, na przechowanie danych trzeba więcej
pamięci niż rozmiar danych. Niektóre programy mogą unikać tych krytycznych
sytuacji i dlatego takie różnice w porównywaniu do C/C++. Program obliczeniowy
w Javie który przetwarza wielokrotnie te same dane w pętlach działa bardzo
szybko. Skąd wiem? Też z pomiarów.

> Są. Ale sam valgrind ma "suppresions" czy jakoś tak to się nazywa, co
> obchodzi znane problemy z libami, ma też opcję "wygeneruj suppresion",
> jak już nie ma innego wyjścia pod każdym upierdliwcem wypluje, jak go
> wyłączyć.
Nie znam tego narzędzia. Przed chwilą poszukałem przykładu w necie,
odpaliłem i nie wyświetlił żadnych problemów. Ale pewnie użyłem jakiś
mały procent jego możliwości.

> Testy tego możliwie małego kawałka kodu też. Nie pisałem algorytmów
> szachowych, nie wiem, czy dają się tak podzielić.
Raczej trzeba trochę większe bloki testować. Zależy jaki test...

> braku ifa nie wyniucha - szkoda ;) Przydałby się tool, który bierze dwa
> algorytmy, powiedzmy, że różniące się nie zasadą działania, tylko
> użytymi strukturami danych, i mówi, czy są równoważne.
Inna struktura danych to inny algorytm. A automatyczne porównywanie dwóch
algorytmów to kiepska sprawa ;) Jedynie na wyrywki, właśnie w takiej
walidacji krzyżowej.
Pozdrawiam



--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl