On 14 Cze, 06:38, Andrzej Jarzabek <a...@g...com> wrote:

> Z Adą nie jest przypadkiem tak, że wymusza dodatkowe runtime checks w
> celu uniknięcia undefined behaviour?

Z Adą jest tak, że *jeśli* masz sytuację wyjątkową, to ma być wyjątek.
Nie znaczy to wcale, że w kodzie zawsze musi być check. To, co Adę
odróżnia od Javy to znacznie bogatszy system typów i znacznie bardziej
rozbudowane reguły języka, które pozwalają kompilatorowi na statyczne
stwierdzenie, że skoro sytuacja wyjątkowa nie wystąpi, to nie trzeba
wstawiać run-time checków.

Koncepcyjnie nie jest to wielka filozofia. Przykład w Javie:

for (int i = 0; i < myArray.length; ++i) {
System.out.println(myArray[i]);
}

To jest pattern, który kompilator może rozpoznać jako bezpieczny i
wtedy nie ma potrzeby wstawiać checków w miejscu indeksowania. Podobno
kompilator Javy z tego korzysta. Problem z Javą polega na tym, że w
zasadzie to jest również granica tego typu działań, bo system typów
jest tak żałosny (właściwie można go określić mianem "skryptowy"), że
nic więcej nie wiadomo. Czy w tablicy są nulle? Czy te obiekty są
niezależne, czy może są wzajemnie poaliasowane? Itd.

Ada pozwala zapisać w typach i w kodzie znacznie więcej informacji,
więc kompilator ma też znacznie większe możliwości redukcji checków. W
praktyce i przy właściwym wykorzystaniu języka checki są wstawiane
tylko tam, gdzie naprawdę muszą, czyli np. przy rzutowaniu typów, przy
odczycie z I/O, itp.
Checki w Adzie można też lokalnie bądź globalnie wyłączyć, z
oczywistymi konsekwencjami.

Istnieje też powiązany z Adą język SPARK, w którym w ogóle nie ma
wyjątków, bo język gwarantuje, że nie ma sytuacji wyjątkowych, które
normalnie wymagalyby run-time checka.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

On Wednesday, June 13, 2012 9:25:11 PM UTC+1, Artur Muszyński wrote:
> W dniu 2012-06-13 12:03, Roman W pisze:
> > Rozmawialem niedawno z ludzmi ktorzy przeniesli zaawansowany model do wyceny
opcji na GPU, uzyskujac przyspieszenie rzedu 300x. Stwierdzili ze najtrudniejsza
czescia projektu bylo
> >
> > a) przekonanie dzialu IT do zainstalowania GPU
> > b) zarzadzanie przeplywem danych do pamieci GPU.
> >
> > Uzyskanie znaczacego przyrostuy wydajnosci wymaga starannego tuningowania kodu.
Dlatego jestem sceptyczny, czy kiedykolwiek ludzie ktorym zalezy na wydajnosci na
tyle, zeby bawic sie w deployment GPU, ograniczyli sie do bibliotek typu Brahma, i
nie brali spraw "we wlasne rece". Ale moze sie myle.
>
> Bardziej jestem sceptyczny do "starannego tuningowania".

Bo? Zarabiaja na tym tyle pieniedzy, ze maja odpowiednia motywacje. I to nie sa glupi
ludzie.

RW

do góry

On Thursday, June 14, 2012 8:28:39 AM UTC+1, Maciej Sobczak wrote:

> Istnieje też powiązany z Adą język SPARK, w którym w ogóle nie ma
> wyjątków, bo język gwarantuje, że nie ma sytuacji wyjątkowych, które
> normalnie wymagalyby run-time checka.

Jezyk gwarantuje, ze kazde polaczenie z baza danych bedzie udane, a kazdy plik na
dysku gotowy do zapisu?

RW

do góry

Dnia Thu, 14 Jun 2012 01:16:42 -0700, Roman W napisal:

> On Wednesday, June 13, 2012 9:25:11 PM UTC+1, Artur Muszyński wrote:
>> W dniu 2012-06-13 12:03, Roman W pisze:
>> > Rozmawialem niedawno z ludzmi ktorzy przeniesli zaawansowany model do
>> > wyceny opcji na GPU, uzyskujac przyspieszenie rzedu 300x. Stwierdzili
>> > ze najtrudniejsza czescia projektu bylo
>> >
>> > a) przekonanie dzialu IT do zainstalowania GPU b) zarzadzanie
>> > przeplywem danych do pamieci GPU.
>> >
>> > Uzyskanie znaczacego przyrostuy wydajnosci wymaga starannego
>> > tuningowania kodu. Dlatego jestem sceptyczny, czy kiedykolwiek ludzie
>> > ktorym zalezy na wydajnosci na tyle, zeby bawic sie w deployment GPU,
>> > ograniczyli sie do bibliotek typu Brahma, i nie brali spraw "we
>> > wlasne rece". Ale moze sie myle.
>>
>> Bardziej jestem sceptyczny do "starannego tuningowania".
>
> Bo? Zarabiaja na tym tyle pieniedzy, ze maja odpowiednia motywacje. I to
> nie sa glupi ludzie.

To jest prawda. Wydajność GPGPU zależy głównie od pamięci
i to nie +- 10% ale czasami ileś razy. Zarówno pamięci na karcie jak i
kopiowania przez PCIEx. Nawet jeżeli tuningowanie nie było aż tak
staranne, bez tego nie ma prawa działać szybko na GPU nic poza "demo".

Edek

do góry

W dniu czwartek, 14 czerwca 2012 01:39:27 UTC+2 użytkownik Michoo napisał:
> > Ale nie żartujmy o C++ lambdach, bo dojdziemy do ściany
> > a.k.a. closure. Lambdy bez podanych wprost argumentów nie
> > mają dostępu do niczego z zewnętrznego zakresu, tak samo
> > jest w phpie, tylko w phpie ciut ładniejsza składnia.
> >
> Przecież mają:
> int b=64;
> int a=32;
> auto l = [&]()->int { return b+a; };
^^^^^

A to co, jak nie podanie explicite zakresu dostępu.
O tym pisałem, że programista *musi* przy definicji
ustalić, do czego funkcja ma dostęp.

BTW funkcje anonimowe są ogólnie przereklamowane.

w.

do góry

On 14 Cze, 10:18, Roman W <b...@g...pl> wrote:

> > Istnieje też powiązany z Adą język SPARK, w którym w ogóle nie ma
> > wyjątków, bo język gwarantuje, że nie ma sytuacji wyjątkowych, które
> > normalnie wymagalyby run-time checka.
>
> Jezyk gwarantuje, ze kazde polaczenie z baza danych bedzie udane, a kazdy plik na
dysku gotowy do zapisu?

Język gwarantuje, że nie ma operacji, które prowadziłyby do zachowań
niezdefiniowanych. Próba zapisu do pliku, którego nie da się zapisać,
to jest bardzo dobrze zdefiniowana operacja i żadnego wyjątku tam nie
potrzeba. To, że większość współczesnych języków używa w takich
okolicznościach wyątków nie znaczy, że bez wyjątków nie można tego
obsłużyć. To raczej objaw wrzucania wszystkiego do jednego worka.

Pomyśl natomiast o dzieleniu przez zero, wyjechaniu za tablicę,
przekroczeniu zakresu dla jakiegoś typu, itp. - to są przypadki, które
normalnie prowadziłyby do zachowania niezdefiniowanego i przy których
tzw. "bezpieczne" języki strzelają wyjątkami a tzw. "niebezpieczne"
udają, że nic nie widzą. Właśnie takich przypadków w SPARKu nie ma.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

On Thursday, June 14, 2012 2:28:40 PM UTC+1, Maciej Sobczak wrote:
> On 14 Cze, 10:18, Roman W <b...@g...pl> wrote:
>
> > > Istnieje też powiązany z Adą język SPARK, w którym w ogóle nie ma
> > > wyjątków, bo język gwarantuje, że nie ma sytuacji wyjątkowych, które
> > > normalnie wymagalyby run-time checka.
> >
> > Jezyk gwarantuje, ze kazde polaczenie z baza danych bedzie udane, a kazdy plik na
dysku gotowy do zapisu?
>
> Język gwarantuje, że nie ma operacji, które prowadziłyby do zachowań
> niezdefiniowanych. Próba zapisu do pliku, którego nie da się zapisać,
> to jest bardzo dobrze zdefiniowana operacja i żadnego wyjątku tam nie
> potrzeba. To, że większość współczesnych języków używa w takich
> okolicznościach wyątków nie znaczy, że bez wyjątków nie można tego
> obsłużyć.

Oczywiscie ze mozna bez wyjatkow, C przeciez sobie radzilo z takimi sytuacjami bez
wyjatkow ;-) A co robi wtedy SPARK?

RW

do góry

W dniu czwartek, 14 czerwca 2012 16:35:43 UTC+2 użytkownik Roman W napisał:
> Oczywiscie ze mozna bez wyjatkow, C przeciez sobie radzilo z takimi sytuacjami bez
wyjatkow ;-)

C sobie radzi? Polecam wszystkim spróbować sił
w "A Quiz About Integers in C" http://blog.regehr.org/archives/721
Na kilku przykładach widać w jak głębokiej dupie
jest koder C/C++ tylko dzięki specyfikacji języka.

W ogóle jestem ciekaw ile kosztowały w sumie te
wszystkie trywialne błędy w rodzaju "null pointer
dereference". Znacie jakieś opracowania?

w.

do góry

Użytkownik "Wojciech Muła" <w...@g...com> napisał:

> BTW funkcje anonimowe są ogólnie przereklamowane.

Wreszcie ktos to napisal odwaznie jawnym tekstem ! :)

PS: To tylko takie zwykle wykastwowane zwykle funkcje/metody

AK

do góry

On Thursday, June 14, 2012 3:51:44 PM UTC+1, Wojciech Muła wrote:
> W dniu czwartek, 14 czerwca 2012 16:35:43 UTC+2 użytkownik Roman W napisał:
> > Oczywiscie ze mozna bez wyjatkow, C przeciez sobie radzilo z takimi sytuacjami
bez wyjatkow ;-)
>
> C sobie radzi? Polecam wszystkim spróbować sił
> w "A Quiz About Integers in C" http://blog.regehr.org/archives/721
> Na kilku przykładach widać w jak głębokiej dupie
> jest koder C/C++ tylko dzięki specyfikacji języka.

No jakos sobie radzi, skoro tyle dobrego oprogramowania napisano w C.

RW

do góry