On Thursday, August 24, 2017 at 6:23:30 PM UTC-4, g...@g...com wrote:
> W dniu czwartek, 24 sierpnia 2017 23:48:16 UTC+2 użytkownik Adam M napisał:
>
> > >
> > > 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.
> >
> > Widzę że wszyscy tutaj wieszaja psy na tych biednych krzyżowcach
>
> nie "wieszają psy", tylko używają argumentów.
>
> > - ale jak mówi przsłowie - Jak trwoga to do Boga
> > - i tak jeśli musisz napisac program który musi rozmawiac
> > ze sprzętem to masz tak naprawdę tylko trzy jezyki popularne
> > do dyspozycji: Macro Assembler (nazwywanie tego językiem to
> > dość duże naciągniecie - ale niech bedzie), C lub C++
> > (przez miłosierdzie nie wspominam tu ADY ;-) )
> >
> > Osobiście uważam ze ignorowanie sprzetu prowadzi braku
> > zrozumienia dlaczego oprogramowanie zachowuje sie w ten
> > a nie inny sposób.
>
> często właśnie ignorowanie sprzętu jest zbawienne dla twojego programu.
> dlatego jak uruchamiasz program napisany w clojure czy erlangu
> na 16-rdzeniowym komputerze, to działa prawie 16 razy szybciej
> niż na 1-rdzeniowym. A w C++, o ile nie użyjesz jakichś bibliotek,
> to raczej nie masz co liczyć na tego rodzaju przyspieszenie (a jeśli
> nawet użyjesz, to pewnie i tak masz błędy)

To jest przyklad tzw. magicznego myslenia - napisze program w Erlangu (to nic ze
dziadowski algorytm i jest tylko jedno-watkowy) ale uruchomie go na 16-to rdzeniowym
procesorze i to spowoduje magiczne ulepszenie algorytmu i 16-kroty przyrost
predkosci. Czysta magia. Amdahl sie w grobie przewraca jak slyszy takie nonsensy na
temat przyrostu predkosci na systemach wieloprocesorowych.
Dodakowo ten biedny Erlang wie w jakis magiczny sposob jak ma to uruchomic na tym
16-rdzeniowym procesorze.
>
> > Jeśli kolega zadaje takie pytanie to tutaj jest link który
> > może się przydać aby zrozumieć za automatyczne zwalnianie
> > i odśmiecanie nie zawsze jest dobrym rozwiązaniem:
> > https://www.dynatrace.com/resources/ebooks/javabook/
impact-of-garbage-collection-on-performance/
>
> problem z tą lekturą jest taki, że niewiele z niej wynika.
> proponuję zerknąć np, tutaj
> https://scholarship.rice.edu/bitstream/handle/1911/1
6127/8900220.PDF?sequence=1&isAllowed=y
> albo tu
> https://www.scss.tcd.ie/Lucy.Hederman/LHMScDissertat
ion.pdf
> albo tu
> http://www.pipeline.com/~hbaker1/Share-Unify.html
> albo tu
> https://pdfs.semanticscholar.org/5fe3/c770c0dfbb05a1
6fe1b969678c8ee3b1a461.pdf
>
> zasadniczo możliwością, którą brak automatycznego odśmiecania
> przed Tobą otwiera, jest możliwość robienia wycieków pamięci.

Nie uwazam że ośmiecanie jest całkowicie złe - w wielu przpadkach daje bezpieczeństwo
(zwłaszcza niedoświadczonym programistom). Moim nawi ększym problemem jest podejście
wszystko albo nic do automatycznego zwalniania pamięci i odśmiecania - zabiera to
wolnosc programiscie w decydowaniu jak program ma sie zachowywac. Podjeście ze
alternatywą do automatycznego zwalniania i odśmiecania sa wycieki pamięci jest jak
proponowanie wprowadzenia zakazu sprzedazy nozy - no bo przecież można kogoś zadzgać.