On Thu, 16 Dec 2010 04:37:10 -0800 (PST), Andrzej Jarzabek
<a...@g...com> wrote:

>On Dec 16, 1:07 am, A.L. <l...@a...com> wrote:
>> On Thu, 16 Dec 2010 01:02:07 +0000, Andrzej Jarzabek
>>
>> <a...@g...com> wrote:
>> >On 15/12/2010 23:03, A.L. wrote:
>> >> No dobrze. Jak to takie proste, to proponuje zadanko:
>>
>> >> Dane sa sekcje krytyczne A, B, C, D, E, F
>>
>> >> Maja one nastepujace wlasiciwosci
>>
>> >> A ~ B (gdzie ~ nalezy czytac "wzajemnie sie wyklucza"
>>
>> >Ja bym w og le postawi spraw inaczej. To, co jest opisane to jest
>> >starsznie niskopoziomowe i jednocze nie do abstrakcyjne.
>>
>> To nie jest ani niskopoziomowe ani abstarkcyjne. To jest
>> wyabstrachowany model problemu rzeczywisctego do rozwizania ktorego
>> "programista bez doktoratu" uzyl jednego semafora, za kazdym razem
>> blokuajc wszystko jak leci.
>
>Inna z kolei możliwość jest taka, że programista bez doktoratu użyje
>wielu semaforów (czy czego tam) i program zrobi deadlocka.

Owszem. Dlatego tzreba wiedziec jak takie problemy rozwiazywac. A
akurat rozwiazanei tego zadanka ktore zadalem nie jest takie proste

A.L.

do góry

On Dec 16, 1:33 pm, A.L. <l...@a...com> wrote:

> OK. Moze za stanowczo powieziane. Moze sie okazac ze facio znajacy
> jezyki funkcyjne bedzie bral 3 razy wiecej pieneidzy niz Joe Shmoe
> programujacy w Javie.

A teraz się jak najbardziej zgadzam. Co nawet byłoby sprawiedliwe i
pożądane, zwłaszcza że w naszej branży niezbyt często wynagrodzenie
idzie w parze z wiedzą.

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

do góry

On Dec 16, 11:17 am, Mariusz Kruk <M...@e...eu.org> wrote:

> >Zgadza się. Ale wtedy dobrze by było, żeby był chociaż przyjazdy dla
> >maszyny.
>
> Assembler? To już chyba było.

Nie popadajmy w skrajność. Można być przyjaznym dla maszyny nie będąc
jednocześnie aż tak niskopoziomowym.

To jest dobre na lekcje historii:

http://en.wikipedia.org/wiki/Steelman_language_requi
rements

> > ani żaden funkcjonalny,
>
> "Funkcyjny"!

Funkcjonalny.

> Funkcjonalne języki, w przeciwieństwie do języków niefunkcjonalnych
> (Brainf*ck anyone?) dają jednak jakieś możliwości.

Jakie?

Ponownie to samo pytanie: dlaczego nie wygrały tych zawodów o T1000?
Może jednak nie dają tych możliwości, co wszyscy myślą, że dają?

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

do góry

On Thu, 16 Dec 2010 06:15:14 -0800 (PST), Maciej Sobczak
<s...@g...com> wrote:

>On Dec 16, 11:17 am, Mariusz Kruk <M...@e...eu.org> wrote:
>
>> >Zgadza się. Ale wtedy dobrze by było, żeby był chociaż przyjazdy dla
>> >maszyny.
>>
>> Assembler? To już chyba było.
>
>Nie popadajmy w skrajność. Można być przyjaznym dla maszyny nie będąc
>jednocześnie aż tak niskopoziomowym.
>
>To jest dobre na lekcje historii:
>
>http://en.wikipedia.org/wiki/Steelman_language_requ
irements
>
>> > ani żaden funkcjonalny,
>>
>> "Funkcyjny"!
>
>Funkcjonalny.
>
>> Funkcjonalne języki, w przeciwieństwie do języków niefunkcjonalnych
>> (Brainf*ck anyone?) dają jednak jakieś możliwości.
>
>Jakie?
>
>Ponownie to samo pytanie: dlaczego nie wygrały tych zawodów o T1000?

A startowaly?...

A.L.

do góry

A.L. wrote:
> On Thu, 16 Dec 2010 04:37:10 -0800 (PST), Andrzej Jarzabek
> <a...@g...com> wrote:
>
>> On Dec 16, 1:07 am, A.L. <l...@a...com> wrote:
>>> On Thu, 16 Dec 2010 01:02:07 +0000, Andrzej Jarzabek
>>>
>>> <a...@g...com> wrote:
>>>> On 15/12/2010 23:03, A.L. wrote:
>>>>> No dobrze. Jak to takie proste, to proponuje zadanko:
>>>>> Dane sa sekcje krytyczne A, B, C, D, E, F
>>>>> Maja one nastepujace wlasiciwosci
>>>>> A ~ B (gdzie ~ nalezy czytac "wzajemnie sie wyklucza"
>>>> Ja bym w og le postawi spraw inaczej. To, co jest opisane to jest
>>>> starsznie niskopoziomowe i jednocze nie do abstrakcyjne.
>>> To nie jest ani niskopoziomowe ani abstarkcyjne. To jest
>>> wyabstrachowany model problemu rzeczywisctego do rozwizania ktorego
>>> "programista bez doktoratu" uzyl jednego semafora, za kazdym razem
>>> blokuajc wszystko jak leci.
>> Inna z kolei możliwość jest taka, że programista bez doktoratu użyje
>> wielu semaforów (czy czego tam) i program zrobi deadlocka.
>
> Owszem. Dlatego tzreba wiedziec jak takie problemy rozwiazywac. A
> akurat rozwiazanei tego zadanka ktore zadalem nie jest takie proste
>
> A.L.

Widze, ze nie jest trywialne... Pomysle wieczorem.

Ale w F# / Scali to niby kilka linijek bedzie?

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Maciej Sobczak"
>> >Zgadza się. Ale wtedy dobrze by było, żeby był chociaż przyjazdy dla
>> >maszyny.
>> Assembler? To już chyba było.
>Nie popadajmy w skrajność. Można być przyjaznym dla maszyny nie będąc
>jednocześnie aż tak niskopoziomowym.

Nie można. Każda forma niebędąca kodem maszynowym jest nieprzyjazna
i musi być tłumaczona na postać wynikową.

>> > ani żaden funkcjonalny,
>> "Funkcyjny"!
>Funkcjonalny.

Funkcjonalna może być kurtka z pierdyliardem kieszeni.
Nie róbmy na siłę kalki z angielskiego. (patrz cholerna "technologia").

>> Funkcjonalne języki, w przeciwieństwie do języków niefunkcjonalnych
>> (Brainf*ck anyone?) dają jednak jakieś możliwości.
>Jakie?

Skoro niektóre są funkcjonalne, to inne muszą być niefunkcjonalne.

>Ponownie to samo pytanie: dlaczego nie wygrały tych zawodów o T1000?
>Może jednak nie dają tych możliwości, co wszyscy myślą, że dają?

Odpowiem pytaniem na pytanie - dlaczego w tym roku w F1 wygrał człowiek
z nazwiskiem zaczynającym się na "V"? Może jednak inne litery nie dają
takich możliwości?

--
\.\.\.\.\.\.\.\.\.\.\.\.\.\
.\....@e...eu.org.\.\.
\.http://epsilon.eu.org/\.\
.\.\.\.\.\.\.\.\.\.\.\.\.\.

do góry

On Thu, 16 Dec 2010 15:33:12 +0100, "R. P."
<r...@w...to.wp.pl> wrote:

>A.L. wrote:
>> On Thu, 16 Dec 2010 04:37:10 -0800 (PST), Andrzej Jarzabek
>> <a...@g...com> wrote:
>>
>>> On Dec 16, 1:07 am, A.L. <l...@a...com> wrote:
>>>> On Thu, 16 Dec 2010 01:02:07 +0000, Andrzej Jarzabek
>>>>
>>>> <a...@g...com> wrote:
>>>>> On 15/12/2010 23:03, A.L. wrote:
>>>>>> No dobrze. Jak to takie proste, to proponuje zadanko:
>>>>>> Dane sa sekcje krytyczne A, B, C, D, E, F
>>>>>> Maja one nastepujace wlasiciwosci
>>>>>> A ~ B (gdzie ~ nalezy czytac "wzajemnie sie wyklucza"
>>>>> Ja bym w og le postawi spraw inaczej. To, co jest opisane to jest
>>>>> starsznie niskopoziomowe i jednocze nie do abstrakcyjne.
>>>> To nie jest ani niskopoziomowe ani abstarkcyjne. To jest
>>>> wyabstrachowany model problemu rzeczywisctego do rozwizania ktorego
>>>> "programista bez doktoratu" uzyl jednego semafora, za kazdym razem
>>>> blokuajc wszystko jak leci.
>>> Inna z kolei możliwość jest taka, że programista bez doktoratu użyje
>>> wielu semaforów (czy czego tam) i program zrobi deadlocka.
>>
>> Owszem. Dlatego tzreba wiedziec jak takie problemy rozwiazywac. A
>> akurat rozwiazanei tego zadanka ktore zadalem nie jest takie proste
>>
>> A.L.
>
>Widze, ze nie jest trywialne... Pomysle wieczorem.
>
>Ale w F# / Scali to niby kilka linijek bedzie?

Nie

A.L.

do góry

W dniu 16.12.2010 13:17, A.L. pisze:
> Gdy procesory beda mialy 64 jadra, nie da sie ich programwoac w C++
> czy Jave. Ani nawet w Adzie. Potzrebny jest nowy paradygmat. Nat tym
> paradygmatem ludzie pracuja.
To już było:
http://en.wikipedia.org/wiki/SPARC_T3#Features
16 rdzeni/128 wątków wspieranych przez hardware na jednym procesorze.

Power5 było 2 rdzeniowe i pozwalało na łączenie do 64 procesorów - czyli
128rdzeni.

Model producent-konsument sprawdzał się na nich całkiem nieźle - nie
widzę, dlaczego by nie miał.


Karty graficzne mają już teraz tysiące rdzeni - programuje się je w
języku C-like.

--
Pozdrawiam
Michoo

do góry

W dniu 16.12.2010 02:37, Mariusz Marszałkowski pisze:
> To chyba jest niemozliwe, zaden kompilator ani JIT nie moze
> przewidziec
Może działać adaptacyjnie.

> kosztow wykonania bardziej skomplikowanych kawalkow kodu - inne dane
> to inny czas. Poza tym jak bylby narzut czasu na pomiary i
> przeprowadzanie
> takiej statysytki?
A performance counters? Wtedy dane zbierają się prawie "za darmo".

P.S.
Na zajęciach widziałem sytuację w javie, gdzie funkcja z ordynarną pętlą
opóźniającą for(int i=0;i<100000000;i++); wykonywała się pierwsze 2 razy
wolno a potem przyspieszała kilkaset razy ;).

--
Pozdrawiam
Michoo

do góry

W dniu 16.12.2010 00:03, A.L. pisze:
> No dobrze. Jak to takie proste, to proponuje zadanko:
>
> Dane sa sekcje krytyczne A, B, C, D, E, F
>
> Maja one nastepujace wlasiciwosci
>
> A ~ B (gdzie ~ nalezy czytac "wzajemnie sie wyklucza"
>
> B ~ D
> A ~ C
> C ~ F
> F ~ E
> B ~ E
> C ~ D

1. Wypisujemy zależności (czyli jakie sekcje muszą być puste, żeby można
było wejść do danej:
A: A,B,C
B: A,B,D,E
C: A,C,D,F
D: B,C,D
E: B,E,f
F: C,E,F
2. Dajemy każdej sekcji jeden mutex i zakładamy pobieranie ich w
kolejności alfabetycznej
3. Robimy graf uszeregowalności konfliktowej i sprawdzamy, czy nie
trzeba dodać dodatkowych, aby uniknąć deadlocka. (Nie chciało mi się
rysować, ale "na oko" nie trzeba).

Anyway, nie wiem, czy prostszym i szybszym rozwiązaniem nie byłby wątek
managera o wyskim priorytecie, który by udostępniał poszczególne sekcje
krytyczne w zależności od możliwości wejścia. (I pozwolił np. na
wprowadzenie elastycznych priorytetów.)


--
Pozdrawiam
Michoo

do góry