Użytkownik Mariusz Kruk napisał:
> #v+
> quicksort [] = []
> quicksort (s:xs) = quicksort [x|x <- xs,x < s] ++ [s] ++ quicksort [x|x <- xs,x >=
s]
> #v-

To jest szkolny przykład. Nie nadaje się do produkcyjnego zastosowania,
z powodu mizernej wydajności ( Haskell również nie implementuje tak
qsorta)

> W sposób oczywisty widać, że kolejne wywołania rekurencyjne mają szansę w sposób
> naturalny zostać zrównoleglone. Napisz to teraz w C pilnując ręcznie
> wszystkiego, czego trzeba pilnować.

Taa jest to bardzo proste:
http://flyingfrogblog.blogspot.com/2010/08/parallel-
generic-quicksort-in-haskell.html

Pozdrawiam
KK

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Maciej Sobczak"
>BTW - Tak totalnie rozpieprzonych literek jeszcze nie widziałem. Czego
>używasz do pisania?

Hmm... U mnie jest iso, w nagłówkach jest iso. Znowu gógle sobie nie
radzą?

>> OK. Ka�dy j�zyk jest nieprzyjazny. Jeden mo�e bardziej, inny mniej, ale
>> to �rednio dobry argument. Kwestia "dobroci" kompilatora.
>Doświadczenia ostatnich 50 lat pokazują, że "dobroć kompilatora"
>łatwiej uzyskać przy językach imperatywnych.

Owszem. Najłatwiej przy asemblerze. Chyba tę argumentację już
przerabialiśmy.

>> >Kiedy� widzia�em do�� kr�tki artyku�, w kt�rym autor zastanawia�
siďż˝
>> >nad Haskellem. By�a tam funkcja sortuj�ca, bodaj�e quicksort w dw�ch
>> >(!) linijkach. Zapis �cina� z n�g. Gorzej z wydajno�ci�. Okaza�o
siďż˝,
>> >�e ten zajefajny zapis ma si� nijak to tego, co si� dzieje w pami�ci i
>> >co robi CPU.
>> Trochďż˝ mi siďż˝ przypomina argumentacja przeciwko programowaniu
>> obiektowemu podpierana tym, jak to pi�knie mo�na w asemblerze
>> przyoszcz�dzi� kilkana�cie bajt�w.
>Tu nie chodziło o kilkanaście bajtów, tylko w ogóle o sens stosowania
>tego w praktyce. O kilkanaście bajtów nikt by się nie spinał.
>
>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 r�bmy na si�� kalki z angielskiego.
>> >Nie r�b se jaj.
>> Nie robi� sobie jaj. L�knij przez �indo� na korner czy kar jeszcze stoi.
>Słabe.
>
>komputer, kompilator, programowanie, procedura, funkcja, ...
>
>Mamy jeszcze kalki z francuskiego, np. klawiatura.
>
>To są słowa, których używasz na codzień i które są stosowane w
>literaturze fachowej, czyli są powszechnie uznane w środowisku
>profesjonalnym.
>Twój przykład z karem na kornerze tu nie pasuje i pokazuje tylko, że
>nie masz się czego złapać.

Oczywiście, że pasuje. W przeciwieństwie do "komputera", dla którego nie
było żadnej sensownej alternatywy ("maszyna licząca"? nie żartuj), do
"języka funkcjonalnego" jest sensowny termin.
Podobnym przykładem niedbalstwa językowego jest strasznie ostatnio
często pojawiająca się "autentykacja".

>> >Po pierwsze, w tej bran�y kalki to najlepsze co mo�na
>> >zrobiďż˝, przynajmniej jest zgodnie ze wszystkimi innymi kalkami.
>> No w�a�nie niekoniecznie i nie zawsze.
>Ale masz problem z uzasadnieniem tej tezy.

Wiesz, czym innym jest zapożyczenie przy braku własnego słowa, a czym
innym jest bezmyślna kalka. (po raz kolejny przypomnę "technologię",
która się tak rozpleniła, że żal.pl).

>> >Po
>> >drugie, "funkcyjny", jak rozumiem, absolutnie �adn� kalk� nie jest,
>> >tak?
>> Owszem, nie jest.
>Bo jest to stare, rdzennie polskie słowo?

Wiesz, zaraz dojdziemy do wniosku, że żadne słowo nie jest rdzennie
polskie. Udajesz, czy naprawdę nie rozumiesz?

>> >Niby w czym kalka "funkcyjny" jest lepsza od kalki
>> >"funkcjonalny"?
>> http://sjp.pwn.pl/slownik/2460400/funkcyjny_I
>> http://sjp.pwn.pl/slownik/2558726/funkcjonalny
>Słabe. To jest słownik PWN, któro to wydawnictwo równocześnie wydaje
>książki mające "analiza funkcjonalna" w tytule. Znaczy - PWN ma
>*niekompletny* słownik. Niekompletny do tego stopnia, że nawet
>własnych tytułów książek nie obejmują.

Niestety, "analiza funkcjonalna" się przyjęła. Chociaż tu akurat nie ma
dwuznaczności. Nie jestem sobie w stanie wyobrazić co miałby oznaczać
przymiot funkcjonalności w odniesieniu do analizy. Natomiast język jak
najbardziej może być funkcjonalny (np. C), lub niefunkcjonalny (np.
Brainf*ck).

>Znajdź coś lepszego.
>
>(hint: jak poszukasz na grupach, to zobaczysz, że tą dyskusję już
>przerabiałem z dokładnie tymi samymi słabymi argumentami (nawet
>argument o PWN był) - spróbuj znaleźć coś, czego jeszcze nie było, bo
>trochę szkoda wszystko powtarzać; w każdym razie poprzednie dyskusje
>nie doprowadziły do żadnego wniosku, więc ta też nie doprowadzi)

Oczywiście. Przecież jeżeli argument nie jest Twój, to jest słaby
z definicji. Znasz takie powiedzenie o trzech osobach mówiących, że
jesteś pijany?

>> >> >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?
>> >S�abe.
>> Owszem. Twoje pytanie by�o s�abe. Nie do��, �e usi�owa�e�
generalizowaďż˝
>> z pojedynczego przypadku, to jeszcze usi�ujesz przekszta�ci� korelacj�
>> w implikacj�. Wi�ksze b��dy logiczne ci�ko by�oby pope�ni�.
>Podałem jakiś data point. Możesz argumentować, że ten jeden data point
>jest statystycznie nieistotny, ale jak wtedy nazwać całkowity brak
>jakichkolwiek przykładów z Twojej strony?

Wiesz, ja tu na razie nie argumentowałem, tylko czepiałem się
nieistotności Twojego "argumentu".

>> #v+
>> quicksort [] = []
>> quicksort (s:xs) = quicksort [x|x <- xs,x < s] ++ [s] ++ quicksort [x|x <- xs,x >=
s]
>> #v-
>> W spos�b oczywisty wida�, �e kolejne wywo�ania rekurencyjne maj�
szans� w spos�b
>> naturalny zosta� zr�wnoleglone.
>Tak. Ale jest jeszcze przekazywanie i składanie wyników. Co
>konkretnie, czyli na poziomie implementacyjnym, robi ten "++"?

Czyli przenosisz dyskusję na jakieś zupełne manowce. "Nie da się tego
zrobić, bo konkretna implementacja jest do dupy".

>To jest
>właśnie problem wynikający z zignorowania tego co się dzieje w pamięci
>i właśnie o tym był ten artykuł. Nie da się pisać wydajnych programów
>skupiając się wyłącznie na jednym aspekcie takim jak równoległość.

A królowa Bona wciąż nie żyje.

>Nie pokazuj mi teoretycznych dwulinijkowych przykładów, na których "w
>sposób oczywisty widać". Pokaż mi *realny* system, który dzięki temu
>był szybszy.
>
>Ja pokazałem *realny* system, który był szybszy w języku imperatywnym.

Pięknie usiłujesz przejść na zupełnie inne kryterium. Problem polega na
tym, że często "szybkość" nie jest najistotniejszym kryterium. Często
wystarczy, żeby rozwiązanie było "wystarczająco dobre". Wtedy istotnymi
kryteriami są takie, jak cena, czy łatwość utrzymania.
Po raz kolejny powtórzę - powtarzasz argumenty, jak miłośnicy C ze
wstawkami w asemblerze jakieś 10-15 lat temu.

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

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Krzysiek Kowaliczek"
>> #v+
>> quicksort [] = []
>> quicksort (s:xs) = quicksort [x|x <- xs,x < s] ++ [s] ++ quicksort [x|x <- xs,x >=
s]
>> #v-
>To jest szkolny przykład. Nie nadaje się do produkcyjnego zastosowania,
>z powodu mizernej wydajności ( Haskell również nie implementuje tak
>qsorta)

Oczywiście. To jest kwestia pokazania mechanizmu, a nie konkretnej
implementacji.

>> W sposób oczywisty widać, że kolejne wywołania rekurencyjne mają szansę w sposób
>> naturalny zostać zrównoleglone. Napisz to teraz w C pilnując ręcznie
>> wszystkiego, czego trzeba pilnować.
>Taa jest to bardzo proste:
>http://flyingfrogblog.blogspot.com/2010/08/parallel
-generic-quicksort-in-haskell.html

Łomatko. Przepisz to sobie w czym chcesz. To nie musi być Haskell jako
taki. Uzyłem go, bo przykład jest prosty i, ze względu na przejrzystą
składnię, łatwo zrozumiały.

--
d'`'`'`'`'`'`'`'`'`'`'`'`'Yb
`b K...@e...eu.org d'
d' http://epsilon.eu.org/ Yb
`b,-,.,-,.,-,.,-,.,-,.,-,.d'

do góry

Użytkownik Mariusz Kruk napisał:
> epsilon$ while read LINE; do echo \>"$LINE"; done < "Krzysiek Kowaliczek"
>>> #v+
>>> quicksort [] = []
>>> quicksort (s:xs) = quicksort [x|x <- xs,x < s] ++ [s] ++ quicksort [x|x <- xs,x
>= s]
>>> #v-
>> To jest szkolny przykład. Nie nadaje się do produkcyjnego zastosowania,
>> z powodu mizernej wydajności ( Haskell również nie implementuje tak
>> qsorta)
>
> Oczywiście. To jest kwestia pokazania mechanizmu, a nie konkretnej
> implementacji.
>

No właśnie ten ładnie wyglądający algorytm nie ma szans na wydajną
realizację. Wydajne nie wyglądają tak ładnie, ale to tym nie wspominają
w tutorialach.

>> Taa jest to bardzo proste:
>> http://flyingfrogblog.blogspot.com/2010/08/parallel-
generic-quicksort-in-haskell.html
>
> Łomatko. Przepisz to sobie w czym chcesz. To nie musi być Haskell jako
> taki. Uzyłem go, bo przykład jest prosty i, ze względu na przejrzystą
> składnię, łatwo zrozumiały.
>

Sam pisałeś o naturalnym zrównolegleniu. A ja twierdze, wbrew temu
co piszesz, że jest to *bardzo* *trudne*. I nie ważne czy jest to język
imperatywny czy deklaratywny. Podałem przykład jak goście męczą się
z implementacją wielowątkowej i *produkcyjnej* wersji qsorta dla
Haskell-a. Te "naturalne" zrównoleglenie będzie miała nieakceptowalną
wydajność dla przemysłu.

Pozdrawiam
KK

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Krzysiek Kowaliczek"
>>>> #v+
>>>> quicksort [] = []
>>>> quicksort (s:xs) = quicksort [x|x <- xs,x < s] ++ [s] ++ quicksort [x|x <- xs,x
>= s]
>>>> #v-
>>> To jest szkolny przykład. Nie nadaje się do produkcyjnego zastosowania,
>>> z powodu mizernej wydajności ( Haskell również nie implementuje tak
>>> qsorta)
>> Oczywiście. To jest kwestia pokazania mechanizmu, a nie konkretnej
>> implementacji.
>No właśnie ten ładnie wyglądający algorytm nie ma szans na wydajną
>realizację. Wydajne nie wyglądają tak ładnie, ale to tym nie wspominają
>w tutorialach.

Mam wrażenie, że ma (może jeszcze nie w tej chwili, ale już niedługo)
szanse na _wystarczająco wydajną_ realizację.

>>> Taa jest to bardzo proste:
>>> http://flyingfrogblog.blogspot.com/2010/08/parallel-
generic-quicksort-in-haskell.html
>> Łomatko. Przepisz to sobie w czym chcesz. To nie musi być Haskell jako
>> taki. Uzyłem go, bo przykład jest prosty i, ze względu na przejrzystą
>> składnię, łatwo zrozumiały.
>Sam pisałeś o naturalnym zrównolegleniu. A ja twierdze, wbrew temu
>co piszesz, że jest to *bardzo* *trudne*. I nie ważne czy jest to język
>imperatywny czy deklaratywny. Podałem przykład jak goście męczą się
>z implementacją wielowątkowej i *produkcyjnej* wersji qsorta dla
>Haskell-a.

Dla konkretnej implementacji Haskella - owszem.

>Te "naturalne" zrównoleglenie będzie miała nieakceptowalną

Au!. "To"!

>wydajność dla przemysłu.

Czy ja tu gdzieś już nie pisałem, że zależy od zastosowania?

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

do góry

Użytkownik Mariusz Kruk napisał:
> Mam wrażenie, że ma (może jeszcze nie w tej chwili, ale już niedługo)
> szanse na _wystarczająco wydajną_ realizację.

To trzymam kciuki.

>> Te "naturalne" zrównoleglenie będzie miała nieakceptowalną
[...]
> Czy ja tu gdzieś już nie pisałem, że zależy od zastosowania?

Mnie nie interesuje podniecanie się przyspieszeniem rozwiązania, które
na wstępie mają wydajność dużo gorszą od optymalnej. Sztuka dla sztuki.

Pozdrawiam
KK

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Krzysiek Kowaliczek"
>>> Te "naturalne" zrównoleglenie będzie miała nieakceptowalną
>[...]
>> Czy ja tu gdzieś już nie pisałem, że zależy od zastosowania?
>Mnie nie interesuje podniecanie się przyspieszeniem rozwiązania, które
>na wstępie mają wydajność dużo gorszą od optymalnej. Sztuka dla sztuki.

Znaczy, swoje kompilaty jeszcze ręcznie optymalizujesz?
Bo to jest dopiero sztuka dla sztuki.

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

do góry

W dniu 2010-12-16 23:20, Norbert pisze:

> Moze Real Basic?
>
> http://www.realsoftware.com/realstudio/compare.php
>
> Niedrogi, basic - wiec powinien byc dosc latwy, klikany interfejs,
> multiplatformowy - kompilat dziala na Windows, Linux i MacOS!, nowoczesny
> wyglad i stale rozwijany, pozwala budowac aplikacje webowe.
> Nie wiem jak z multimediami, bo nie znam tego srodowiska z autopsji, ale
> warto sprawdzic, bo moze byc ciekawie.

Wygląda fajnie, ale mam wrażenie że wszystkie, dosłownie wszystkie te
"multiplatformowe" produkty jak realbasic, livecode i parę innych bazują
na jakiejś wspólnym jądrze, na jakiejś "praprzyczynie". Najbardziej
charakterystycznym przykładem tego jest dla obsługa MOV na dzień dobry w
każdym z takich środowisk a dla odmiany wielkie problemy z avi, nie
mówiąc już o bardziej zaawansowanych rzeczach jak livestream z tunera tv
cze kamery nie wspominając.
Jasne, do wszystkie można dopisać bibliotekę i oprotezować...
No nic, macam dalej.

Maciek

do góry

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


No, Kolego, a prtobowales SAM cos zrownolegli, i to COS bylo sporych
rozmiarow i sporej zlozonosco, czy tez wiesz to wszystko z czytania
guuugla?...

A.L.

do góry

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

A.L.

do góry