> 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

do góry

Dnia 18-08-2011 o 02:42:05 <m...@t...pl> napisał(a):

[...]
> 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.

chodzi chyba o to, żebyś jeszcze poeksperymentował ze zmianą opcji
kompilatora i pomiarem czasu.

[...]
--
Jordan Szubert

do góry

On Aug 17, 2:30 pm, Michal Kleczek <k...@p...onet.pl> wrote:
>
> Przy takim podejsciu to zaden jezyk nie ma, bo chyba (tutaj - fakt -
> potrzebuje wsparcia mocniejszych teoretykow) nie da sie zrobic jezyka
> "turing complete" bez operacji "unsafe" czyli nieweryfikowalnych
> statycznie (takich jak rzutowanie).

Musiałbyś bardziej dodefioniować, co uważasz, za operację unsafe. Na
pewno da się zrobic język Turing complete bez rzutowania. Banalny
przykład: Uniwaersalna Maszyna Turinga ma tylko jeden typ danych, więc
żadnego rzutowania nie ma, a z definicji jest Turing complete.

do góry

On 2011-08-19 11:28, Andrzej Jarzabek wrote:
> On Aug 17, 2:30 pm, Michal Kleczek<k...@p...onet.pl> wrote:
>>
>> Przy takim podejsciu to zaden jezyk nie ma, bo chyba (tutaj - fakt -
>> potrzebuje wsparcia mocniejszych teoretykow) nie da sie zrobic jezyka
>> "turing complete" bez operacji "unsafe" czyli nieweryfikowalnych
>> statycznie (takich jak rzutowanie).
>
> Musiałbyś bardziej dodefioniować, co uważasz, za operację unsafe. Na
> pewno da się zrobic język Turing complete bez rzutowania. Banalny
> przykład: Uniwaersalna Maszyna Turinga ma tylko jeden typ danych, więc
> żadnego rzutowania nie ma, a z definicji jest Turing complete.

Jak pisalem wczesniej - ktos przydalby sie madrzejszy ode mnie w tej
dysusji. Ale w mojej ciemnocie wydaje mi sie ze na podstawie tw Rice'a -
nic nietrywialnego (a wiec sensownego z punktu widzenia statycznej
weryfikacji programu) o takiej maszynie nie daje sie powiedziec. W koncu
o kazdej maszynie turinga mozna powiedziec, ze "czyta symbole alfabetu".

--
Michal

do góry

On 19.08.2011 11:28, Andrzej Jarzabek wrote:
> On Aug 17, 2:30 pm, Michal Kleczek <k...@p...onet.pl> wrote:
>>
>> Przy takim podejsciu to zaden jezyk nie ma, bo chyba (tutaj - fakt -
>> potrzebuje wsparcia mocniejszych teoretykow) nie da sie zrobic jezyka
>> "turing complete" bez operacji "unsafe" czyli nieweryfikowalnych
>> statycznie (takich jak rzutowanie).
>
> Musiałbyś bardziej dodefioniować, co uważasz, za operację unsafe. Na
> pewno da się zrobic język Turing complete bez rzutowania. Banalny
> przykład: Uniwaersalna Maszyna Turinga ma tylko jeden typ danych, więc
> żadnego rzutowania nie ma, a z definicji jest Turing complete.

Swoją droga podstawowy język nie ma rzutowania, a przynajmniej nie
słyszałem o rzutowaniu w asemblerze.

--
wer <",,)~~
http://szumofob.eu

do góry

On Mon, 15 Aug 2011 12:46:29 -0700 (PDT), Maciej Sobczak wrote:

>> *W tym  
>> kontekście* absolutnie zgadzam się ze stwierdzeniem, że w Javie robi się  
>> mniej błędów.

> Otóż nie, to nie przeszkadza w robieniu błędów. Ten mechanizm je co
> najwyżej wykrywa. W run-time. Nic nie stoi na przeszkodzie, żeby
> wysłać klientowi program z błędem i w tym kontekście uważam, że Java
> nie wnosi istotnego postępu w dziedzinie poprawności.

Otóż właśnie przeszkadza w popełnianiu pewnej klasy błędów. Najbardziej
oczywistą klasą błędów są błędy wynikające z użycia błędnego wskaźnika - w
Javie się to po prostu nie zdarza. O wycieki pamięci też jest dużo
trudniej. A to jest tylko najbardziej oczywisty przykład.

> Jawne deklarowanie wyjątków się nie sprawdziło w praktyce i Javowcy
> masowo to pomijają. Nie, nie chodzi o początkujących adeptów, robią
> tak również projektanci poważnych frameworków. Po prostu się nie
> sprawdziło.

A mi właśnie brakuje takiego jawnego deklarowania wyjątków w językach,
które go nie używają. Są sytuacje, w których jest to denerwujące, ale dla
mnie w większości przypadków jest to po prostu wygoda.

> import java.util.TreeSet;
>
> class NonComparable {}
>
> public class Test {
> public static void main(String[] args) {
> TreeSet<NonComparable> mySet = new TreeSet<NonComparable>();
> mySet.add(new NonComparable());
> mySet.add(new NonComparable());
> }
> }
>
> W funkcji main są trzy linijki.
> W języku z poważną statyczną kontrolą typów powinien być błąd
> kompilacji w pierwszej linii, gdzie tworzony jest bezsensowny typ
> zbioru. Tak się stanie np. w Adzie (w równoważnym przykładzie).

To *w ogóle* nie jest kwestia siły typowania języka, tylko rozwiązania z
biblioteki. To jest tylko i _wyłącznie_ kwestia api udostępnianego przez
klasę TreeSet. Po prostu TreeSet nie narzuca na klasy konieczności
implementowania interfejsu Comparable. Co więcej, umożliwia korzystanie z
klas, które tego interfejsu nie implementują. Można bez problemu napisać w
Javie odpowiednik TreeSet, którego użycie spowodowałoby błąd kompilacji już
w pierwszej linijce. Więc tak, jest tutaj silniejsza kontrola typów.

--
Pozdrawiam
Zbyszek Malec

do góry

On Fri, 19 Aug 2011 22:05:25 +0200, Zbigniew Malec wrote:

>>> *W tym  
>>> kontekście* absolutnie zgadzam się ze stwierdzeniem, że w Javie robi się  
>>> mniej błędów.

Eh, widzę, że ktoś mnie ubiegł.

--
Pozdrawiam
Zbyszek Malec

do góry

> On 19.08.2011 11:28, Andrzej Jarzabek wrote:

> > On Aug 17, 2:30 pm, Michal Kleczek <k...@p...onet.pl> wrote:

> >>

> >> Przy takim podejsciu to zaden jezyk nie ma, bo chyba (tutaj - fakt -

> >> potrzebuje wsparcia mocniejszych teoretykow) nie da sie zrobic jezyka

> >> "turing complete" bez operacji "unsafe" czyli nieweryfikowalnych

> >> statycznie (takich jak rzutowanie).

> >

> > Musiałbyś bardziej dodefioniować, co uważasz, za operację unsafe. Na

> > pewno da się zrobic język Turing complete bez rzutowania. Banalny

> > przykład: Uniwaersalna Maszyna Turinga ma tylko jeden typ danych, więc

> > żadnego rzutowania nie ma, a z definicji jest Turing complete.

>

> Swoją droga podstawowy język nie ma rzutowania, a przynajmniej nie
> słyszałem o rzutowaniu w asemblerze.
Tak samo, inta do chara przez obciecie najbardziej znaczacych bitow.
Bez wzgledu na to czy robi to procesor, czy programista, czy moze
makroasembler cos wstawia.
Pozdrawiam


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

do góry

> Od jakiegoś czasu tez sprawdzałem ile piszę kodu, ale na dobę. Rozrzut
> mam ogromy nawet w ramach tego samego języka. Ba... często pod koniec
> dnia kod jest dużo mniejszy niż na początku :) W szachach w C++ pewnie
> by mi wyszła jedna linijka na dobę :) W PHP (ale z małą ilością htmla) to
> rekordowo mam 30kb na dobę.
> Pozdrawiam.

jak juz kiedys mowilem MZ normalnym i BARDZO dobrym rezultatem jest kilkaset
linijek dziennie - z pewnym akcentem ze jak to jest kilkaset linijek to
byl to dzien duzej ilosci porzadnego kodowania poswiecony w calosci na
kodowanie - sa tez dni (i mz normalnie powinno ich byc sporo) w ktorych
ilosc linijek wynosi 0 bo trzeba jednak tez poczytac, poszukac, pomyslec
itp i wogole tez czasem 'zregenerowac leb'

(zmeczony iphonista)


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

do góry

W dniu 18.08.2011 02:42, m...@t...pl pisze:
> 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.
Java wymaga słowa kluczowego new. Afaik kompilator w sytuacji gdy widzi,
że zmienna nie wychodzi z zakresu umieszcza ją na stosie.

--
Pozdrawiam
Michoo

do góry