On Tue, 29 Aug 2017 06:26:44 -0700 (PDT), g...@g...com
wrote:
> A jak by takie coś wyglądało w Javie albo C++?
> Ja sobie wyobrażam mniej więcej coś takiego [...]

Można lepiej: nie używać funkcji pow(), tylko mnożenia; tylko dwie
pętle po x i y, natomiast z obliczyć; do obliczeń użyć algorytmu
liczenia pierwiastka kwadratowego na liczbach całkowitych lub jeżeli
szybciej FPU. To się nawet da zwektoryzować i/lub rozbić na wątki
(pętla po x), ale nie przesadzajmy.

I tu jest cały myk: czy Haskell domyśli się że jest O(N**2) czy
będzie forsowała O(N**3), a może cudownie zejdzie po analizie reszty
kodu do O(1) dzięki lazy evaluation?

do góry

On Tuesday, August 29, 2017 at 6:46:59 PM UTC+2, slawek wrote:
> On Tue, 29 Aug 2017 06:26:44 -0700 (PDT), g...@g...com
> I tu jest cały myk: czy Haskell domyśli się że jest O(N**2) czy
> będzie forsowała O(N**3), a może cudownie zejdzie po analizie reszty
> kodu do O(1) dzięki lazy evaluation?

Dobre pytanie.
Pozdrawiam

do góry

Użytkownik "Adam M" <a...@m...com> napisał:

> Przyklad kolegi w typ przypadku jest nie na miejscu - w czasie zaczynania
aptymalizacji kodu ale
> emulatora
> nie bylo wiadomo czy 80286 bedzie dostepny (a dodatkowo z dalaczonym 80287 - w
tamtych czasach
> duzo
> PC AT nie mialo dokladanego 20287 bo kosztowal extra - > dodakowo byly ograniczenia
COCOM na
> sprzedaz do demoludow).
> W tym przypadku optymalizazja byla uzasadniona - jak to mowi przyslowie (niestety
po angielsku) -
> hindsight is always 20/20.

Nie. Nie byla. Przyspieszenie nowego/zoptymalizowanego emulatora bylo rzedu kilku
procent w
stoosunku do dostarczanych
z kompilatorami (TC i MS C).
..a o COCOMie nie ucz Ojca dzieci...

> Na problem nad-optymalizacji C++ cierpia glownie programisci starszego pokolenia

Nieprawda, Jest dokladnie odwrotnie.
My starzy dobrzre wiemy ze prawdziwy handicap daje algorytm.
Top Wy mlodzi swiecie wierzycie w sprzet/procesor.paiec
My (a przynajmniej ja) starzy, rozwiazujac skomplikowana numeryke na takiej
Odrze1325 z 32kBslow dobrze wiedzielismy ze nie ma co liczyc na sprzet ale na
rozwiazanai/algorytmy/pomysly.
To Wy jestescie obciazenie GHz i GB

> Ale zobaczysz :) Sam jestem ciekaw.
> Podstaw Pythona nauczysz sie w godzine.

> Tak - wszyscy tak bardzo kochaja Pythona - zycze wielu skucesow w napisaniu
> wielowatkowego programu w Pythonie (a dokladnie w CPythonie - najpopularniejszej
wersji) bez
> odwolywania sie do magicznych sztuczek. Python jest bardzo fajnym jezykiem do
prototypowania
> i szybkiej roboty - ale bez przesady - napisanie duzego systemu w Pythonie to
> czysty masochizm.

Powiedz to Googlowi, Facebookowi (Tornado: https://pypi.python.org/pypi/tornado/).
No dobra. Niech beda polskie firmy. Powiedz to Onetowi i WP (i jeszcze O2) ktorych np
obsluga poczty jest napisana w Pythonie.
Jednym z najszybszych serwerow ftp to tez Python.
W sensie/swiecie multitaskingu nie wszytsko watkami stoi, a nawet GIL (gdy ktos sie
zna i umie)
nie jest tez nieprzekraczalna bariera, a ostatnio asyncio (w rozmnych odmianach -
nastepca i
kontynuator
Twisted-a) wymiata.
W dodatku wielo(mikro)watkowo pisze sie tak jak sekwencyjnie a nie
callbackowo/zdarzeniowo
jak w innych jezykach/technologiach.

PS: Masz dokladnie 0-we pojecie o Pythonie. Errata. No nie., Jakies tam maasz - "z
prasy" :)

AK

do góry

Użytkownik "M.M." <m...@g...com> napisał:

> W latach 90tych było inaczej. Kompilatory nie dość że kompilatory generowały
> kiepski kod, to jeszcze nie umiały malutkich funkcji wstawiać inline.
> Wszelkie próby napisać kodu przyjaznego dla kompilatora kończyły się
>totalną sieczką z punktu programisty czytającego ten kod.

...kolejne mity...
Bylo_dokladnie_ odwrotnie.
To prosty zwykly kod byl przyjazniejszy dla kompilatora/optymalizatora.

AK

do góry

On Wednesday, August 30, 2017 at 12:50:38 AM UTC+2, AK wrote:
> Użytkownik "M.M." <m...@g...com> napisał:
>
> > W latach 90tych było inaczej. Kompilatory nie dość że kompilatory generowały
> > kiepski kod, to jeszcze nie umiały malutkich funkcji wstawiać inline.
> > Wszelkie próby napisać kodu przyjaznego dla kompilatora kończyły się
> >totalną sieczką z punktu programisty czytającego ten kod.
>
> ...kolejne mity...
> Bylo_dokladnie_ odwrotnie.
> To prosty zwykly kod byl przyjazniejszy dla kompilatora/optymalizatora.

Żadne mity tylko dziesiątki albo nawet setki pomiarów czasów.
Do czasów borlnad C++ w wersji około 5.0 - 6.0 (32bity) ja mam rację,
potem Ty. GCC i G++ był wtedy jeszcze gorszy. W VC++ było podobnie,
dopiero gdzieś od wersji 6.0 generował akceptowalny kod.

Pozdrawiam

do góry

> Powiedz to Onetowi i WP (i jeszcze
> O2) ktorych np
> obsluga poczty jest napisana w Pythonie.

Ciekawe skąd ten pomysł?!? Ja parę lat temu osobiście byłem na
przesłuchaniu w sprawie pracy w wp.pl i tam powiedzieli mi, że szukają
gości do pisania w C demona rozproszonego na Linuxy do obsługi poczty.
Parę lat minęło, więc chyba już go skończyli... Z Onetem to nie wiem,
ale jeśli chodzi o o2.pl to połączyło się parę lat temu z wp.pl. Ale czy
to oznacza, że teraz działa na tym co wp.pl - tego nie wiem...

do góry

On Wednesday, August 30, 2017 at 12:50:38 AM UTC+2, AK wrote:
> Użytkownik "M.M." <m...@g...com> napisał:
>
> > W latach 90tych było inaczej. Kompilatory nie dość że kompilatory generowały
> > kiepski kod, to jeszcze nie umiały malutkich funkcji wstawiać inline.
> > Wszelkie próby napisać kodu przyjaznego dla kompilatora kończyły się
> >totalną sieczką z punktu programisty czytającego ten kod.
>
> ...kolejne mity...
> Bylo_dokladnie_ odwrotnie.
> To prosty zwykly kod byl przyjazniejszy dla kompilatora/optymalizatora.
>

Nigdy tego nie zauważyłem. Natomiast często widziałem, żę
w starszych kompilatorach wystarczyło zamiast funkcji użyć
makra i już kod był wyraźnie o parę procent szybszy. O
zamianie operacji na tablicy na operacje wskaźnikach nie
wspomnę - zresztą, dziś też widać co się dzieje, gdy się
zrobi te same operacje na wektorze, iteratorach i wskaźnikach.
Pozdrawiam

do góry

On Wednesday, August 30, 2017 at 2:00:25 AM UTC-4, M.M. wrote:
> On Wednesday, August 30, 2017 at 12:50:38 AM UTC+2, AK wrote:
> > Użytkownik "M.M." <m...@g...com> napisał:
> >
> > > W latach 90tych było inaczej. Kompilatory nie dość że kompilatory generowały
> > > kiepski kod, to jeszcze nie umiały malutkich funkcji wstawiać inline.
> > > Wszelkie próby napisać kodu przyjaznego dla kompilatora kończyły się
> > >totalną sieczką z punktu programisty czytającego ten kod.
> >
> > ...kolejne mity...
> > Bylo_dokladnie_ odwrotnie.
> > To prosty zwykly kod byl przyjazniejszy dla kompilatora/optymalizatora.
>
> Żadne mity tylko dziesiątki albo nawet setki pomiarów czasów.
> Do czasów borlnad C++ w wersji około 5.0 - 6.0 (32bity) ja mam rację,
> potem Ty. GCC i G++ był wtedy jeszcze gorszy. W VC++ było podobnie,
> dopiero gdzieś od wersji 6.0 generował akceptowalny kod.
>
> Pozdrawiam

w 100% zgadzam się z przedpiszcą - zwlaszcza Bornland byl wtedy marnej jakosci (ale
był względnie tani), dodakowo linker Borlanda byl szybki ale wiązał wszysko co mu
podeszło - zadnej optymalizaji (library pruning). Z tego okresu miło wspominam Watcom
C++ i SAS C++, a co do compilatorow C to TopSpeed C i Aztec C.

do góry

On Tuesday, August 29, 2017 at 6:47:32 PM UTC-4, AK wrote:

>
> > Przyklad kolegi w typ przypadku jest nie na miejscu - w czasie zaczynania
aptymalizacji kodu ale
> > emulatora
> > nie bylo wiadomo czy 80286 bedzie dostepny (a dodatkowo z dalaczonym 80287 - w
tamtych czasach
> > duzo
> > PC AT nie mialo dokladanego 20287 bo kosztowal extra - > dodakowo byly
ograniczenia COCOM na
> > sprzedaz do demoludow).
> > W tym przypadku optymalizazja byla uzasadniona - jak to mowi przyslowie (niestety
po angielsku) -
> > hindsight is always 20/20.
>
> Nie. Nie byla. Przyspieszenie nowego/zoptymalizowanego emulatora bylo rzedu kilku
procent w
> stoosunku do dostarczanych
> z kompilatorami (TC i MS C).
> ..a o COCOMie nie ucz Ojca dzieci...
No nie wiem - moze te pre procent przyspieszenia bylo potrzebne - moze nie - wszystko
zalezy od potrzeb - czlowiek jest zawsze madrzejszy po fakcie.
>
> > Na problem nad-optymalizacji C++ cierpia glownie programisci starszego pokolenia
>
> Nieprawda, Jest dokladnie odwrotnie.
> My starzy dobrzre wiemy ze prawdziwy handicap daje algorytm.
> Top Wy mlodzi swiecie wierzycie w sprzet/procesor.paiec
> My (a przynajmniej ja) starzy, rozwiazujac skomplikowana numeryke na takiej
> Odrze1325 z 32kBslow dobrze wiedzielismy ze nie ma co liczyc na sprzet ale na
> rozwiazanai/algorytmy/pomysly.
> To Wy jestescie obciazenie GHz i GB

Milo mi slyszec że naleze do tzw młodego pokolenia bo komputerami zajmuje się od 1982
;-).
Osobiscie nie mialem doczynienia z Odra (chociaz koledzy chwalili sobie ten system)
and pracowalem na MERA-300 i MERA-60 a pozniej na PDP-11, HP2000 i HP3000.
A co do obciazenia GHz i GB to programuje systemy czasu rzeczywistego (MCU i DSP) na
ktorych RAM mierzy sie KB (czasami 64KB RAM to wszysto) i wiekszosc procesorow jest
jedno-rdzeniowa (lub ma dodatkowe co-porocesory wymagajace spcjalizowanego
programowania w assemblerze) a predkosc mierzy sie w MHz - czasami 200MHz to juz
bardzo szybko.
Dodaktowo wymaganiem jest wysoka niezawodnosc oprogramowania - polecam poczytac MISRA
C i MISRA C++ standard.

>
> > Ale zobaczysz :) Sam jestem ciekaw.
> > Podstaw Pythona nauczysz sie w godzine.
>
> > Tak - wszyscy tak bardzo kochaja Pythona - zycze wielu skucesow w napisaniu
> > wielowatkowego programu w Pythonie (a dokladnie w CPythonie - najpopularniejszej
wersji) bez
> > odwolywania sie do magicznych sztuczek. Python jest bardzo fajnym jezykiem do
prototypowania
> > i szybkiej roboty - ale bez przesady - napisanie duzego systemu w Pythonie to
> > czysty masochizm.
>
> Powiedz to Googlowi, Facebookowi (Tornado: https://pypi.python.org/pypi/tornado/).

Nie wiem jak inni ale wydawalo mi sie ze Facebook uzywa wlasnego , wysoko
zoptymalizowanego PHP.
> No dobra. Niech beda polskie firmy. Powiedz to Onetowi i WP (i jeszcze O2) ktorych
np
> obsluga poczty jest napisana w Pythonie.
> Jednym z najszybszych serwerow ftp to tez Python.
> W sensie/swiecie multitaskingu nie wszytsko watkami stoi, a nawet GIL (gdy ktos sie
zna i umie)
> nie jest tez nieprzekraczalna bariera, a ostatnio asyncio (w rozmnych odmianach -
nastepca i
> kontynuator
> Twisted-a) wymiata.
> W dodatku wielo(mikro)watkowo pisze sie tak jak sekwencyjnie a nie
callbackowo/zdarzeniowo
> jak w innych jezykach/technologiach.
>
> PS: Masz dokladnie 0-we pojecie o Pythonie. Errata. No nie., Jakies tam maasz - "z
prasy" :)
>
Skoro ten Python jest taki dobry do wszystkiego i taki szybki to dlaczego nie
uswiadczysz go na MCU/DSP albo nawet na wiekszosci SOC (i prosze nie wyciągac mi tu
Raspberry Pi - nikt zdrowy na umysle i traktujacy swoich klientow powaznie nie uzyje
RPi do zastosowan profesjonalnych - dodatkowo jako test proponuje napisac program w
Pythonie na RPi obslugujacy 8 do 16 portow szeregowch z predkoscia transmisji 1.5MB
na kazdym porcie i praktycznie ciaglym naplywem danych - a nastepnie powtorzyc to
cwiczenie w C++ lub C)
> AK

do góry

On Wed, 30 Aug 2017 07:09:02 -0700 (PDT), Adam M
<a...@m...com> wrote:
> Skoro ten Python jest taki dobry do wszystkiego
> i taki szybki to dlaczego nie uswiadczysz go na
> MCU/DSP albo nawet na wiekszosci SOC

Przy 1kB SRAM to raczej nie doradzałbym Pythona.

Ale ludzie dziwne rzeczy robią. Np. używają Delphi do pisania dla
MCU.

do góry