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