On Thu, 16 Dec 2010 21:35:06 +0100, Michoo <m...@v...pl> wrote:

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

Owszem, ja kiedys pracowalem na transputerach. Tez dobrze dzialaly.
NAwet do 128 procesorow. I teraz pytanei za 50 punktow: Dlaczego do
programwoania transputerow wymyslono jezyk Occam, i dlaczego, mimo ze
byl dostepny kompilator C, nikt nei uzywal C a wszyscy uzywali Occam?

Po drugie: jest pewna roznica miedzy 128 procesorami w architektuirze
multicore takiej jaka ona jest obecnie a 128 procesorami odizolowanymi
jako osobne jednostki. W obu architekturach procesury komunikuja sie w
inny sposob, w zwiazku z tym paradygmat programwoania i zrownoleglania
musi byc inny.

Jeszcze raz: wszystko mozna programowac w dolownym jezyku. Ale w
niektorych robi sie okreslone rzeczy latwiej a w innych trudniej.
Programowanei wspolbieznosci w ejzykach "wspierajacych" owa do latwych
nie nalezy. Stad moja sugestia, i nie tylko moja, bo o tym sie pisze w
lietraturze, ze paradygmat dla programowania wspolbieznego to bedzie
nastepna "wielka rzecz"

A.L.

do góry

W dniu 17.12.2010 16:38, A.L. pisze:
> On Thu, 16 Dec 2010 21:35:06 +0100, Michoo<m...@v...pl> wrote:
>
>> 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.
>>
>
> Owszem, ja kiedys pracowalem na transputerach. Tez dobrze dzialaly.
> NAwet do 128 procesorow. I teraz pytanei za 50 punktow: Dlaczego do
> programwoania transputerow wymyslono jezyk Occam, i dlaczego, mimo ze
> byl dostepny kompilator C, nikt nei uzywal C a wszyscy uzywali Occam?
Zmartwię Cię, bo programowałem transputery w Parallel C, który został
specjalnie na nie wymyślony (akurat na niego mieliśmy licencję). I
jedyny wniosek jaki mi się nasuwa to "bo schemat komunikacji na
transputerach to tzw. 'pain in the ass'".

>
> Po drugie: jest pewna roznica miedzy 128 procesorami w architektuirze
> multicore takiej jaka ona jest obecnie a 128 procesorami odizolowanymi
> jako osobne jednostki. W obu architekturach procesury komunikuja sie w
> inny sposob, w zwiazku z tym paradygmat programwoania i zrownoleglania
> musi byc inny.
Te podane przeze mnie rozwiązania to albo NUMA albo SMP, czyli jak
najbardziej multicore.


>
> Jeszcze raz: wszystko mozna programowac w dolownym jezyku. Ale w
> niektorych robi sie okreslone rzeczy latwiej a w innych trudniej.
> Programowanei wspolbieznosci w ejzykach "wspierajacych" owa do latwych
> nie nalezy. Stad moja sugestia, i nie tylko moja, bo o tym sie pisze w
> lietraturze, ze paradygmat dla programowania wspolbieznego to bedzie
> nastepna "wielka rzecz"
Jak na razie inny modny temat - "pamięć transakcyjna" - w takich
językach jak java czy ocaml osiągnięciem jest tysiąc transakcji na
sekundę. Intel STM compiler wyrabiał spokojnie setki tysięcy na kodzie C++.

Magia - w kodzie C++ dodajesz OMP, kompilujesz i program się zrównolegla
a kompilator dba o to, żeby dane były spójne. Mocno wydajne a
jednocześnie banalnie proste z punktu widzenia programisty.


--
Pozdrawiam
Michoo

do góry

W dniu 17.12.2010 16:25, A.L. pisze:
> No, Kolego, a prtobowales SAM cos zrownolegli, i to COS bylo sporych
> rozmiarow i sporej zlozonosco, czy tez wiesz to wszystko z czytania
> guuugla?...
Na "mocnym" sprzęcie (xeon) powyżej 32 wątków nie wychodziłem - brak
możliwości sprzętowych(jedynie 16 rdzeni). Niagary nikt nie chciał
studentowi udostępnić do testów ;) Testowałem m.i. wydajność struktur
lock-free i futexów właśnie w modelu producent-konsument.

Kartę graficzną ze 128 rdzeniami programowałem.

Teraz niestety siedzę w Javie, ale od nowego roku może się uda przenieść
na C++/CUDA.

--
Pozdrawiam
Michoo

do góry

On Fri, 17 Dec 2010 17:15:04 +0100, Michoo <m...@v...pl> wrote:

>> Owszem, ja kiedys pracowalem na transputerach. Tez dobrze dzialaly.
>> NAwet do 128 procesorow. I teraz pytanei za 50 punktow: Dlaczego do
>> programwoania transputerow wymyslono jezyk Occam, i dlaczego, mimo ze
>> byl dostepny kompilator C, nikt nei uzywal C a wszyscy uzywali Occam?
>Zmartwię Cię, bo programowałem transputery w Parallel C, który został
>specjalnie na nie wymyślony (akurat na niego mieliśmy licencję). I
>jedyny wniosek jaki mi się nasuwa to "bo schemat komunikacji na
>transputerach to tzw. 'pain in the ass'".
>

Po pierwsze, wyrazam kondolencje z powodu uzywania C. Po drugie, na
OCCAM nei tzreba bylo miec licencji. Po tzrecie, "model komunikacjny
transputerow" to nei ejst bynajmniej "pain in the ass"

Przypominam ze Hoare ktory wymyslil monitory - obecnie mechanizm
wspierajacy wspolbieznosc w Javie - po neijakim czasie okreslil owe
monitory jako "tragiczna pomylke swego zycia" i wymyslik CSP
(Communicating Sequential Processes), To wlasnei implementuje Occam,
Erlang i pare innych jezykow.

Neistety, model CSP jest troche formalny, i dlatego wielu programistow
ma z nim problemy.

>>
>> Po drugie: jest pewna roznica miedzy 128 procesorami w architektuirze
>> multicore takiej jaka ona jest obecnie a 128 procesorami odizolowanymi
>> jako osobne jednostki. W obu architekturach procesury komunikuja sie w
>> inny sposob, w zwiazku z tym paradygmat programwoania i zrownoleglania
>> musi byc inny.
>Te podane przeze mnie rozwiązania to albo NUMA albo SMP, czyli jak
>najbardziej multicore.
>

No to co z tego?
>
>>
>> Jeszcze raz: wszystko mozna programowac w dolownym jezyku. Ale w
>> niektorych robi sie okreslone rzeczy latwiej a w innych trudniej.
>> Programowanei wspolbieznosci w ejzykach "wspierajacych" owa do latwych
>> nie nalezy. Stad moja sugestia, i nie tylko moja, bo o tym sie pisze w
>> lietraturze, ze paradygmat dla programowania wspolbieznego to bedzie
>> nastepna "wielka rzecz"
>Jak na razie inny modny temat - "pamięć transakcyjna" - w takich
>językach jak java czy ocaml osiągnięciem jest tysiąc transakcji na
>sekundę. Intel STM compiler wyrabiał spokojnie setki tysięcy na kodzie C++.
>
>Magia - w kodzie C++ dodajesz OMP, kompilujesz i program się zrównolegla
>a kompilator dba o to, żeby dane były spójne. Mocno wydajne a
>jednocześnie banalnie proste z punktu widzenia programisty.

Mit o "automagicznym zrownoleglaniu", "zrownoleglajacych
kompilatorach" itede istnieje prawie tak dlugo jak ja zyje na tym
Bozym swiecie. A zyje dlugo. I jak dotad czolowi specjalisci od
programowania rownoleglego okreslaja go jako "publiczne cwiczenia w
poboznych zyczeniach".

Nei neuje ze bardzo specjalizowane zastosowanie daja sie tak
zrownoleglic, ale to jeszcze bardzo daleko do powszechnosci.

A.L.

do góry

A.L. wrote:
> On Thu, 16 Dec 2010 15:07:43 -0800 (PST), Maciej Sobczak
> <s...@g...com> wrote:
>
>> On Dec 16, 1:17 pm, A.L. <l...@a...com> wrote:
>>
>>> A jak idzie o jezyk Ada i jego wsparcie dla wspolbieznosci, to keidys
>>> zdarzylo mi sie wspolpracowac z firma 8888 gdzie uzywano Ady, ale tak
>>> zwanego "bezpiecznego podzbioru". Ten podzbior wykluczal Adowe "taski"
>>> ze wzgledu na niepzrewidywalnosc ich wykonywania pod wzgledem
>>> czasowym.
>> To musiało być bardzo "kiedyś". Bo dzisiaj te "taski" wykorzystuje się
>> właśnie dzięki ich przewidywalności.
>>
>> http://en.wikipedia.org/wiki/Ravenscar_profile
>>
>>> Gdy procesory beda mialy 64 jadra, nie da sie ich programwoac w C++
>>> czy Jave. Ani nawet w Adzie. Potzrebny jest nowy paradygmat.
>> To bardzo odważne twierdzenie. Michoo już odpisał, jak to wygląda, nie
>> będę powtarzał.
>>
>
> Bardzo cenie to co mocho odpisal, ale nie przywiazuje do tego wiekszej
> wago dopoki mnie nie przekona ze jego wiedza pochodzi z doswiadczen a
> nie wikipedii.
>
>>> Zas wracajac do meritum: Jakie jest doswiadczenie Kolego z jezykamu
>>> funkcyjnymi ze wydaje takie stanowcze opinie?... Czy to na podstawie
>>> "hands on" czy tez teoretycznej wszechwiedzy?...
>> To nie jest meritum, bo to jest Twoja kolejna proba zdyskredytowania
>> kogoś na forum. Meritum byłoby gdybyś zapytał jakie jest moje
>> doświadczenie w tworzeniu złożonych i wydajnych systemów *BEZ* użycia
>> języków funkcjonalnych. Wbrew pozorom te dwa pytania nie są
>> równoważne, analogicznie do powyższych o Google'u.
>
> To nie ejst dyskredytowanie. ja po prostu chce wiedziec skad ktos
> podajacy stwierdzenie "na pewno sie nadaje" czy "na pewno sie nie
> nadaje" ma informacje pozwalajaca na wygenerowanei takich konkluzji? Z
> wlasnej praktyki czy z Wikipedii?...
>
> Chcialbym zwrocic uwage ze ja mie dodaje slowka "na pewno", bo na
> pewno to nic nei wiadomo.
>
> A z tego ze Google nie uzywa Haskella nei wynika nic oprocz tego ze
> Google nei uzywa Haskella. Google tez nei uzywa Prologa. Ale nic stad
> nie wynika ani dla Prologa ani dla Googla. Podobnie Google nie uzywa
> Ady. I znow nic z tego nie wynika...

Ale skad wiesz, moze Qrczakowego Kogoota uzywaja ;) W koncu to jezyk
funkcyjny. Haskell jest zdecydowanie za malo intuicyjny dla dobrego
(nawet bardzo dobrego) programisty. Do tego juz potrzeba doktoratu.

do góry

Mariusz Kruk wrote:

>>Komputery mają swoją fizyczność i idące z nią ograniczenia. Jeśli je
>>zignorujesz, to ograniczysz się do eksploracyjnej niszy.
>
> Oczywiście, że mają. Trick polega na tym, że często łatwiej
> (w szczególności - taniej) dołożyć pamięci, czy nawet postawić obok
> drugi serwer, niż inwestować w kolejnego programistę.

Nie wszystkie zagadnienia się zrównoleglają, więc nie zawsze drugi serwer
coś pomoże.
Jeśli system wymaga do działania dwóch serwerów zamiast jednego, wzrasta
prawdopodobieństwo awarii systemu.
Ogólnie to często słyszę hasło o tanim sprzęcie i drogich programistach -
niejednokrotnie osoby, które tym hasłem regularnie się posiłkują, tworzą
rozwiązania kilkadziesiąt razy wolniejsze niż inne, które wcale wiele więcej
wysiłku by nie wymagały.

do góry

On Dec 16, 12:17 pm, A.L. <l...@a...com> wrote:
> Autor Haskela kiedys popelnil papier "How industry is using functional
> languages and why not".

Niedawno slyszalem o tym, że Credit Suisse zaczyna używać F# w swojej
analityce.

R.

do góry

> zautomatyzować zamiast ręcznego Invoke?). Z przeskokiem z Delphi też
> moim zdaniem nie powinno być problemu - filozofia wyklikiwania
> interfejsu jest bardzo podobna (co niestety umożliwia tworzenie
równie
> paskudnego kodu jak w Delphi), a sam język coś tam się od Pascala
różni,


może i kod jest paskudny, ale dzisiaj liczy się szybkość, a wyklikanie
kodu trochę sprawę przyśpiesza....




Rf










--
http://hitarget.sxar.pl/ odbiornik geodezyjny gps

do góry

On 16/12/2010 22:44, Maciej Sobczak wrote:
> On Dec 16, 12:40 pm, Andrzej Jarzabek<a...@g...com>
>
>> Nie zgadzam się. SQL jest mainstreamowy na ten przykład.
>
> Bo będąc 4GL jest bardziej zrozumiały dla człowieka (widziałem kiedyś

No więc nie jestem przekonany, czy jakiś bardziej złożony select jest
bardziej zrozumiały niż jego wersja imperatywna. Z całą pewnością jednak
się bardzo ładnie skaluje bez konieczności specyfikowania jakichkolwiek
elementów współbieżności - czy to wątków, locków, czy czego tam jeszcze
może używać.

>> W przypadku znacznie większych programów komercyjnych, [...]
>
> No właśnie - teraz pojawia się pytanie, czy języki funkcjonalne, ze
> swoją specyficzną idiomatyką są odpowiednie do takich systemów.

Pytasz, czy w tej chwili są, czy z zasady są? Z zasady nie widzę
powodów, żeby nie miały być, jeśli chodzi o tu i teraz, to powody
zapewne są, ale według mnie nie mają nic wspólnego z idiomatyką.

> Zauważ też, że obecnie w takich systemach współbieżność jest zwykle
> zarządzana nie przez programistę, tylko przez jakiś framework. Czy to
> centralny broker, czy to serwer aplikacyjny, czy jeszcze coś -
> wszystko jedno. To znaczy, że zarządzanie wielowątkowością, przydział
> zadań, itd. są robione niejawnie i poza głównym kodem. I bardzo
> dobrze, ale jednocześnie jest to cecha, którą niby chcemy uzyskać w
> nowych językach. Tylko że to żaden postęp, bo to już dawno jest.

Nie wiem, o jakich frameworkach mówisz. Jest jakiś framework, który
zrównolegli mi mój przykład z a, b i c?

>> Problem jest w tej chwili taki, i to jest druga połowa odpowiedzi na
>> Twoje pytanie, że ten język jeszcze nie istnieje. Ale pracuje się nad
>> tym i wiadomo, że takie wymagania znacznie łatwiej mozna spełnić
>> językiem funkcyjnym lub zbliżonym, niż językiem imperatywnym.
>
> Dlaczego?

Dlatego, że model imperatywny opiera się na tym, że specyfikujesz
kolejność wykonania operacji, które potencjalnie modyfikują stan
programu. Jeśli masz rzeczywistą zależność gdzie C zależy od A i B, ale
A i B nie zależą od siebie nawzajem, to zapisując ją w postaci
imperatywnego programu A, B, C gubisz informację, która pozwoliłaby
kompilatorowi zadecydować, że A i B mogą być wykonane równolegle.

> Hint: są języki imperatywne, które współbieżność mają wbudowaną w
> swoją konstrukcję. Pytanie jest o to, czego ciekawego nie można nimi
> uzyskać a co przyniosą nam nowe języki.

Patrz wyżej.

>> Wnoszą tyle, że można napisać jeden program i patrzeć jak się skaluje.
>> Imperatywnie i na jawnych wątkaach można teoretycznie zrobić tak samo
>> albo nawet lepiej, ale będzie to oznaczało kupę pracy programistów,
>> wielokrotne przepisywanie kodu, trudne do namierzenia bugi itd.
>
> To spory skok myślowy. Nie widzę powodu, dla którego miałoby tak być.
> Automatycznie skalujące się pule wątków to nawet w Javie są - a to
> jest język imperatywny.

Nie mówię o pulach wątków. Mówię o tym, że SQL-owy select bez problemów
skaluje się na praktycznie dowolną ilość wątków bez _żadnego_ wysiłku ze
strony programisty (piszącego tego selecta) aby uczynić go równoległym.
Dlatego właśnie, że nie jest imperatywny.

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Wojciech Jaczewski"
>>>Komputery mają swoją fizyczność i idące z nią ograniczenia. Jeśli je
>>>zignorujesz, to ograniczysz się do eksploracyjnej niszy.
>> Oczywiście, że mają. Trick polega na tym, że często łatwiej
>> (w szczególności - taniej) dołożyć pamięci, czy nawet postawić obok
>> drugi serwer, niż inwestować w kolejnego programistę.
>Nie wszystkie zagadnienia się zrównoleglają, więc nie zawsze drugi serwer
>coś pomoże.
>Jeśli system wymaga do działania dwóch serwerów zamiast jednego, wzrasta
>prawdopodobieństwo awarii systemu.
>Ogólnie to często słyszę hasło o tanim sprzęcie i drogich programistach -
>niejednokrotnie osoby, które tym hasłem regularnie się posiłkują, tworzą
>rozwiązania kilkadziesiąt razy wolniejsze niż inne, które wcale wiele więcej
>wysiłku by nie wymagały.

Och, jaka subtelna próba wyzwania mnie od nieuków :-P
Niestety, ja akurat prędzej z drugiej strony barykady. Owszem, wolę
kupić drugi serwer za, powiedzmy, 10kzł, niż płacić 50kzł za kolejne
miesiące "optymalizacji". (kwoty możesz sobie przeskalować w
którąkolwiek stronę chcesz).

--
[------------------------]
[ K...@e...eu.org ]
[ http://epsilon.eu.org/ ]
[------------------------]

do góry