Użytkownik "AK" <n...@n...net> napisał:

> Lahey

Sorry, mialo byc HPF Fortran

AK

do góry

On Fri, 25 Aug 2017 07:04:07 -0700 (PDT), Adam M
<a...@m...com> wrote:
> Amdahl sie w grobie przewraca

Amdahl jest przereklamowany.

Zasadniczy kłopot to czy program ma robić "to samo", czy raczej "to
co chcemy". Im więcej wątków tym możemy chcieć więcej. A w takim
przypadku prawo Amdahla jest nieprzydatne.

do góry

On Fri, 25 Aug 2017 17:49:26 +0200, "AK" <n...@n...net> wrote:
> Syf jakich malo :)

Wyliczeniowe goto natenprzykład :)

Albo entry :)

Albo equivalence :)

...

do góry

On Friday, August 25, 2017 at 2:04:20 PM UTC-4, slawek wrote:
> On Fri, 25 Aug 2017 07:04:07 -0700 (PDT), Adam M
> > Amdahl sie w grobie przewraca
>
> Amdahl jest przereklamowany.

To jest bardzo mocne stwierdzenie. Wiekszosc programistow is projektantow systemo
ktorzy zajmoja sie projektowaniem systemow wspolbieznych raczej zgadzaja sie z
Amdahlem.
Pewnie zdaniem szanownego kolego rowniez Pitagoras tez jest przereklamowany - o
biednym Einsteinie to juz nawet nie warto wspominac.
>
> Zasadniczy kłopot to czy program ma robić "to samo", czy raczej "to
> co chcemy". Im więcej wątków tym możemy chcieć więcej. A w takim
> przypadku prawo Amdahla jest nieprzydatne.

Czy mozna poprosic o dokladniejsze wyjasnienie co tez kolega mial na mysli - tak na
prosty chlopski rozum ;-) - zawsze mnie uczono ze program ma robic "to samo" - to
znaczy ze przy takich samym zestawie danych wejsciowych powinnismy sie spodziewac
takich samych rezultatow wyjsciowych (nie odnosi sie to do sieci neuronowych ale nie
o nich tutaj ddyskutujemy).

do góry

On Friday, August 25, 2017 at 8:04:20 PM UTC+2, slawek wrote:
> On Fri, 25 Aug 2017 07:04:07 -0700 (PDT), Adam M
> <a...@m...com> wrote:
> > Amdahl sie w grobie przewraca
>
> Amdahl jest przereklamowany.
>
> Zasadniczy kłopot to czy program ma robić "to samo", czy raczej "to
> co chcemy". Im więcej wątków tym możemy chcieć więcej. A w takim
> przypadku prawo Amdahla jest nieprzydatne.

Ja pierdzielę, to tak jakby ktoś napisał, że prawo Ohma jest nieprzydatne...
Prawo Amdhala stwierdza wyłączenie, że istnieje górna granica przyspieszenia
dla przetwarzania jakiegoś zadania na n procesach.

w.

do góry

On Fri, 25 Aug 2017 11:57:45 -0700 (PDT), Adam M
<a...@m...com> wrote:
> On Friday, August 25, 2017 at 2:04:20 PM UTC-4, slawek wrote:
> > On Fri, 25 Aug 2017 07:04:07 -0700 (PDT), Adam M
> > Amdahl jest przereklamowany.

> To jest bardzo mocne stwierdzenie.

Wiem.

> Czy mozna poprosic o dokladniejsze wyjasnienie
> co tez kolega mial na mysli

Wyjaśnię to dwa razy: raz na chłopski rozum, raz na przykładzie
pewnego programu.

Wyobraź sobie że jesteś gospodarzem. Masz jakieś 20 morgów i 4
parobków. Prawo Ahmadla i zdrowy rozsądek podpowiadają że 4000
parobków nie zapewni 1000 krotnego wzrostu tempa żniw. True.

A co byłoby, gdybyś miał nie 20 morgów, ale 20 tysięcy morgów? Nadal
"zrównoleglenie" prac przez zatrudnienie armii tysięcy parobków nie
miałoby sensu?

Innymi słowy: gdyby kurczowo trzymać się prawa Ahmadla to nie
istniałaby takie firmy jak MS, Intel, Google, Samsung itd. - każda
zatrudnia olbrzymie ilości ludzi, a przecież z prawa Ahmadla wynika
że to niepotrzebne.

A teraz drugi przykład. Program czyta liczbę 64 bitową, wykonuje
obliczenia, wypisuje wynik jako ułamek dziesiętny. Czytania i
wpisywania nie da się zrównoleglić. Obliczenie każdej cyfry wyniku
jest całkowicie niezależne. Program oblicza wynik z dokładnością do 4
cyfr po przecinku.

Zgodnie z prawem Ahmadla nie ma sensu używać zbyt wielu procesorów.
To oczywiste.

Ale jeżeli zamiast 4 cyfr będziesz chciał mieć wynik z 40 cyframi
(albo z 40 tysiącami cyfr), to prawo Ahmadla nie podważa sensowności
zastosowania odpowiednio większej liczby procesorów.

Czyli prawo Ahmadla nie jest do stosowania w ciemno, bez sprawdzania
założeń przy jakich je sformułowano. Przecież nie używasz twierdzenia
Pitagorasa do obliczania objętości kuli.

Podobna sytuacja była ze słynnym "640 kilobajtów wystarczy każdemu".
To była prawda... Ale tylko przy założeniu że PC będzie służył tylko
do tego co robiono na Spectrum itp. A to założenie okazało się
fałszywe.

do góry

>> A aplikację
>> desktopową?
> Raczej nie każdą (ale w Javie też nie każdą się da napisać), ale może to da jakieś
wskazówki:
>
> http://reference.wolfram.com/language/guide/Creating
FormsAndApps.html
> http://reference.wolfram.com/language/guide/CustomIn
terfaceConstruction.html
>

Może się czepiam, ale to chyba odnośni się do budowy formularzy na
stronie. No ale widzę że jakiś parser języka na desktopy oferują, to
może i otwiera stronę w oknie.

--
Pozdrawiam,
Mateusz Bogusz

do góry

On Fri, 25 Aug 2017 11:57:45 -0700 (PDT), Adam M
<a...@m...com> wrote:
> zawsze mnie uczono ze program ma robic=
> "to samo" - to znaczy ze przy takich samym
> zestawie danych wejsciowych pow=


Problem z "to samo" jest głębszy niż Rów Mariański.


Jeżeli np. program A przynosi takie same zyski producentowi jak
program B, to z punktu widzenia księgowego robi "to samo".

Jeżeli program A to gra i program B to gra, to oba mogą robić "to
samo": zapewniają jakąś formę rozrywki. Choć jeden to np. M&M9 a
drugi to Wiedźmin 3. (Albo Angry Birds)

Jeżeli A to program sterujący lądownika Apollo, a B to program
sterujący wahadłowcem, to w zasadzie robią "to samo" - sterują
załogowym pojazdem kosmicznym.

Itp. Itd.

do góry

On Fri, 25 Aug 2017 13:22:23 -0700 (PDT), Wojciech
Muła<w...@g...com> wrote:
> Ja pierdzielę, to tak jakby ktoś napisał,
> że prawo Ohma jest nieprzydatne...

A co ci kiciuś pomoże prawo Ohma dla nadprzewodnika?

Nawet dla półprzewodnika (zjawiska nieliniowe) prawo Ohma
niespecjalnie wystarcza.

I drobiazg: prawo Ohma jest empiryczne.

do góry

On Friday, August 25, 2017 at 11:35:46 AM UTC+2, g...@g...com wrote:
> W dniu piątek, 25 sierpnia 2017 01:12:43 UTC+2 użytkownik M.M. napisał:
> > W dniu czwartek, 24 sierpnia 2017 17:32:35 UTC+2 użytkownik M.M. napisał:
> >
> > > Zależy do czego. Rzecz z bibliotekami ma się tak,
> > > że ich użyteczność ogranicza się zazwyczaj do celu,
> > > w jakim zostały zrobione. Mówiąc inaczej, to są przetarte
> > > szlaki, i do rozwiązania typowych problemów z reguły
> > > pewnie wystarczą.
> > No tak. Ale, o ile się nie mylę, podobnie jest w każdym języku.
> > Część zadań rozwiązuje się przy pomocy środków jakie są
> > dostarczane na poziomie języka, a drugą część na poziomie
> > środków z bibliotek. Jeśli jest więcej na poziomie
> > języka i język umożliwia bardziej zwartą składnię, to
> > można odnieść wrażenie, że język jest lepszy do danego
> > zadania. Lepszy w sensie że trzeba mniej kodu wpisać,
> > zapewne jest. Poza tym to nie wiem... Napisałeś kilka
> > postów powyżej, że niektóre języki nie są tylko językami
> > programowania, ale językami myślenia. Jeśli się myśli
> > algorytmami, to pewnie masz rację, chociaż... napiszę poniżej
> > coś o pewnym programie do gry w szachy. Ale jeśli myśli się
> > optymalnym rozwiązaniem danego problemu, to może język
> > C++ jest językiem myślenia?
>
> Nie wiem. Ja nie myślę algorytmami, tylko relacjami
> między pojęciami.
Tu się robi ciekawie, ale z góry się obawiam, że przejrzystej
rozmowy nie przeprowadzimy na temat myślenia algorytmami,
pojęciami, czy optymalizacją. Ale muszę zapytać: jak to jest
myśleć relacjami? Przykładowo piszę grę w szachy, jak to
jest myśleć relacjami?


> W moim odczuciu myślenie, którego
> uczy C++, jest raczej dość kulawe, co bierze się stąd,
> że jest w nim dużo niespójności i przypadkowych decyzji.
Nie wiem. O jakie przypadkowe decyzje chodzi? Czy
chodzi o to, że jedno zadanie można zrealizować na
wiele sposobów, czyli że można użyć wektora, tablicy,
wskaźników i programista myśli co lepsze, a nie jak
po prostu zrealizować zadanie? Jeśli wydajność jest
ważna, to testuje się wszystko, a jeśli nie, to albo
bierze się Javę, albo programuje w C++ tak jak w Javie,
czyli bierze się wektor.

> W rezultacie tego rodzaju wzorzec może podszeptywać
> programistom, że "z niespójnościami da się żyć" i że
> "przypadkowe decyzje są nie do uniknięcia". Nawet jeśli
> z niespójnościami da się żyć, a przypadkowe decyzje są
> nie do uniknięcia, wydaje mi się, że to nie jest dobra
> nauka.
Kiedyś tak mówili o basicu. Słyszałem nawet, że kto programuje w
basicu, to już nie może się nauczyć programowania w innych
językach, bo ma tak dużo złych nawyków. Potem Javę reklamowano
jako język w którym łatwo pisać programy nie zawierające
błędów i że jest językiem pozbawionym wad C++. Teraz chyba
Java też jest niedobra bo jest ruby, R i inne pytony.

Jeśli chodzi o zalety programowania w C++, to ja zauważyłem
jedno. Programiści którzy zadali sobie trud nauki programowania
w C++, potem lepiej i szybciej odnajdowali się w innych
środowiskach.

Nie wiem czy nasza rozmowa do czegoś doprowadzi. W niektórych
językach na pewno można uzyskać bardziej zwarte rozwiązanie
niektórych problemów niż w innych. I to jest faktem. Kiedyś
używałem R do zadań optymalizacyjnych, np. do trenowania sztucznych
sieci neuronowych. Można było w R zrobić bardzo wiele przy pomocy
małej ilości kodu. Jakbym chciał w R napisać aplikację okienkową,
to też byłoby tak gładko? Chyba nie?

> Nie znam takiego słowa. Może masz na myśli to, co określa
> się mianem pseudokodu?
Tak, mnie jakoś lepiej brzmi meta-kod. Pseudo kojarzy mi się z
podróbką, ale zapewne o tym samym mówimy.


> Ale skoro tak, to dlaczego ów "metakod" nie miałby być
> językiem, który od razu można wykonać na komputerze?
Nie wiem dlaczego, może dlatego że jeszcze nie mamy
sztucznej inteligencji? Swoją drogą, chyba opracowałem
fajny model sztucznych sieci neuronowych, ale to jeszcze
nie ta era, żeby programy zamieniały metakod na asembler :)



> Wrócę do tego wątku mniej więcej za miesiąc, proszę
> o cierpliwość :)
To napisz chociaż co planujesz?


> Jasne, zdecydowanie tak.
> To jest też powód, dla którego cenię Pythona -- bo daje wskazówki
> odnośnie tego, jak należy w nim programować. Z tego też względu
> wolę Scheme'a, bo nie stawia dziwacznych ograniczeń na nazewnictwo
> zmiennych.

W C++ trzeba się umówić jak co nazywamy.


> Masz na myśli Scalę, czy angielski? :)
> Jeżeli idzie o Scalę, to przyznam, że nie do końca rozumiem
> fenomen, ale chyba zamysł był taki, żeby ułatwić programistom
> Javy wejście w świat programowania funkcyjnego.

Ciekawe jak potem działają programy napisane w scali.


>
> > > Pytanie, skąd się uczyłeś C++a
> > Z literatury.
>
> No jo. Tyle że książek jest dużo.
I dużo miałem na biurku.

> Jak wspominałem, ja się uczyłem z "Język C++" Stroustrupa.
> To może nie być zbyt dobra książka do nauki.
>
> > > I jeżeli im mają i im działa, to dobrze. Ale trzeba mieć
> > > świadomość, że to jest w dużej mierze owoc tego, co się im
> > > jako firmie udało wyrzeźbić z tego kloca, jakim jest C++.
> > > A jeśli rzeźbili, to podejrzewam, że było dużo prób i błędów.
> > > Pytanie, ile te próby i błędy kosztowały.
> >
> > Ja się zgadzam, że C++, za wyjątkiem sytuacji gdy już są
> > gotowe biblioteki, nie jest najlepszym języku do szybkiego
> > wykonania aplikacji. Natomiast jak "rzeźbiłem z tego kloca"
> > aplikację która obsługiwała bazę ram 1TB, to w C++ chociaż
> > mogłem wyrzeźbić, a we wszelkich innych językach/narzędziach
> > by padło przy 100GB, a może przy 20GB. W rozwiązaniu
> > pilotażowym opartym o PHP + JS + PgSQL nawet nie ruszyło.
>
> Nie wiem, czy we wszystkich. Myślę że Clojure albo Scala
> mogłyby spokojnie pociągnąć. Kiedyś też zdarzało mi się przetwarzać
> wielkie zbiory danych w Perlu, i radził sobie doskonale.

Bardzo w to wątpię. Myślę, że z powodu narzutu pamięciowego te
dane w RAM by się nawet nie zmieściły.


> > > Ja jestem całkowicie przeciwny. Jedyną rzeczą, jaka powinna się liczyć
> > > przy pisaniu kodu, jest wygoda programisty i łatwość refaktoryzacji.
> > > Jeżeli wszystko ma działać szybko, powinniśmy tworzyć dobre narzędzia
> > > optymalizujące.
> > Mi też tak mówili wiele razy, wiele osób, w wielu sytuacjach.
> > A potem narzędzi optymalizacyjnych nie było i dupa.
>
> Zgadzam się, że to jest w praktyce wielki problem, dlatego
> moim zdaniem powinniśmy się skupić na opracowywaniu tego rodzaju
> narzędzi.
Idea fajna, ale czy to jest w ogole możlie? Człowiek może przepisać
program z Javy na C++, ale bez dokumentacji też nie zawsze mu się
uda. Sztucznej inteligencji jeszcze nie ma.


> Pewnie "linia najmniejszego oporu" przebiega przez ręczne
> optymalizowanie aplikacji w C++, ale z punktu widzenia "rozwoju ludzkości"
> bardziej racjonalne wydaje się wykonanie optymalizacji tylko raz
> dla wszystkich programów, a nie tyle razy, ile jest programów.
Masz rację, tylko pytanie, czy to jest możliwe?


> Ale zgodzę się, że z dobrymi narzędziami jest taki problem,
> że albo ich nie ma, albo nie wiemy o tym, że są.


> > Pewnie że
> > ja też bym chciał programować tylko w Javie, bo się zakochałem w
> > tym języku. Gdy wydajność nie jest ważna, to powinno się sięgać
> > po takie języki.
>
> Nie rozumiem jak można się zakochać w Javie :)
Nie ma tu nic do rozumienia, albo język się podoba, albo nie.


> To jest akurat najprostsza rzecz: jeżeli masz program w C++ korzystający
> z STLowych kolekcji, to łatwo powinno być napisać np. algorytm genetyczny,
> który zadany zbiór przypadków testowych bada na różnych konfiguracjach
> kolekcji.
Ja zazwyczaj podstawiam kilka kombinacji i mierzę czas wykonania. Moim
zdaniem sensowne używanie algorytmów genetycznych do optymalizowania
kodu będzie możliwe też dopiero gdy będzie dostępna sztuczna inteligencja.
Do takich zadań jest potrzebna procedura, która rozstrzygnie, czy dwa
programy dadzą takie same dane wyjściowe dla dowolnych dopuszczalnych
danych wejściowych. W przeciwnym razie programista musi ograniczyć
zbiór rozwiązań dla AG, a to już nie jest ani proste, ani przyjemne.

>
>
> > > Tyle że programiści często myślą, że to, że C++ daje dużą kontrolę
> > > nad sprzętem, to dobra rzecz.
> > > Myślę, że jest dokładnie odwrotnie. Im mniej intymnych szczegółów
> > > język może wiedzieć o systemie, na którym jest uruchamiany, tym
> > > lepszą robotę mogą odwalić narzędzia uruchomieniowe.
> > Taka jest teoria. W praktyce byśmy musieli mieć sztuczną inteligencję
> > do kompilowania kodu w językach wysokiego poziomu. Kompilator
> > musiałby wiedzieć jakiej puli algorytmów może użyć aby zapewnić
> > poprawne wyjście dla wszystkich dozwolonych wejść.
>
> Tak.
To jednak się zgadzamy co do tego, niepotrzebnie się rozpisywalem powyżej :)


> Naprawdę, jedyne, co brak automatycznego zwalniania pamięci umożliwia,
> to pisanie programów z wyciekami pamięci.
Już pisałem o tym. Weka jest napisana w Javie. Nie ma więc wycieków pamięci.
Moje programy pewnie jakieś wycieki czasami mają. Gdy jednak uczę prosty
preceptron w środowisku Weka, to z systemu znika 1.2GB - 1.5GB RAM. Danych
mam z 80tys wierszy i 15 kolumn. Gdy to samo robię w C++, to nie wiem
czy chociaż 3MB są potrzebne. Czas uczenia w C++ jest o rzędy wielkości
mniejszy. Czy Wekę pisali idioci? Oczywiście nie!!! Napisano ją "bardzo
dobrze w Javie".

Czasami patrzę jak używają programu do czegoś związanego z CNC. Program
ten jest napisany w Pythonie. Program ten używa algorytmów których nie
znam tak dobrze jak uczenie perceptronu, więc nie chcę się wypowiadać
kategorycznie, ale na oko, też zajmuje za dużo pamięci, za często się
zawiesza i za późno jest reakcja na działania użytkownika.

>
> > > Nie wiem, nie używałem nigdy (i wolałbym nie używać), ani nie implementowałem.
> > Ok.
> >
> > > Ostatnio implementowałem dużo algorytmów grafowych czysto funkcyjnie,
> > > ale niestety powodowało to narzut złożoności algorytmicznej w stosunku
> > > do wersji korzystających z mutacji.
> > > Stąd teraz mam taką zabawę, że wymyślam metody automatycznej
> > > transformacji programów napisanych funkcyjnie w wydajniejsze
> > > programy stosujące mutację.
> > Nie wiem co to jest mutacja. Jak to się zachowuje po optymalizacji,
> > spadła złożoność algorytmiczna?
>
> Mutacja, czyli modyfikacja istniejącego obiektu.
> Na przykład takie coś, co wyszło w rozmowie z AK, w Pythonie:
>
> a = [1,2,3]
> b = [4,5,6]
> a += b
>
> w trzeciej linijce tablica "a" została zmodyfikowana, czy też
> doszło do "mutacji". faktycznie może "mutacja" nie ma w języku polskim
> najlepszej konotacji, ale często mówi się np. o obiektach albo zmiennych
> niemutowalnych.
>
> przykład, którym na razie się zajmowałem, to haskellowy wariant
> quicksorta:
>
> qsort [] = []
> qsort (pivot:rest) = (qsort below) ++ [pivot] ++ (qsort above)
> where below = [x | x <- rest, x < pivot]
> above = [x | x <- rest, x >= pivot]

Podoba mi się, choć nie rozumiem. Piękny zwarty kod, bym chciał
tak na co dzień programować. Czy mierzyłeś wydajność w porównaniu do
C++? Czy tam jest już zawarte inne sortowanie gdy danych jest
zbyt mało na quick sorta?


> problem z tym, że ta funkcja nie jest "quick", i że -- tak jak
> oryginalny Quicksort Hoare'a działał podstawiając elementy tablicy
> w miejscu (czyli mutując tablicę), tak ten generuje bardzo dużo
> śmieci. Ale istotę jego działania widać jak na dłoni.
Aha, czyli moje pytania powyżej są już nieważne. Tu się zgadzam z
Tobą, mnie też się podoba ten zapis, widać jak na dłoni, pomimo że
nie rozumiem składni języka.


> > Jakby to działało, gdybyś od razu w C++ lub Javie napisał?
>
> Za mniej więcej miesiąc podeślę, to będziesz mógł sam ocenić,
> ale podejrzewam, że raczej bym czegoś takiego nie napisał w C++
> ani w Javie
Dlaczego?


Pozdrawiam

do góry