W dniu sobota, 26 sierpnia 2017 16:04:34 UTC+2 użytkownik AK napisał:
> Użytkownik "fir" <p...@g...com> napisał:
>
> > pewnie pomysle o optymalizacji jak ktos zacznie z sensem asemblowac tym
asemblerem
>
> Nikt nie zacznie, bo zwykly popularny kompilator C zrobi to o wiele wydajniej niz
twoj assembler.
>
> > na razie jakos tego zapotrzebowania wogole nie widze ;c
>
> .. co mnie w ogole nie dziwi.. czy ty widzisz cokolwiek dalej niz czubek wlasnego
nosa :) ?
>
> > gorzej ze nie che mi sie wklepywac tych wszystkich menmonikow, glownie chodzi o
te wersje
> > na charow i shortow, AX AH AL BX BL BH etc,
> > zreszta chyba nawet zwykle skoki albo nawet mov eax maja wersje skrocone (tj
takie ktorych
> > operand nie jes 32 bitowy tylko jakies krotsze wersje 16 bit 8 bit)..
>
> no to d..pa ! :)
>
> np. ...na stosowaniu tych wersji skrocoonych polegala kiedys optymalizacja kodu
assemblerowego.
>
> np powszechnie stosowalo sie (i kompiltaory C tez to wtedy juz umialy):
>
> push cs
> call near ptr addr_fun
>
> zamiast mniej wydajnego ;
>
> call far ptr addr_fun
>
> Takich "sztuczek" bylo wiele.
> Ja np. stosowalem dosc czesto:
>
> mov bx, sp
>
> i indeksowalen stos bx-em
>
> zamiast standarowej wtedy "rozbiegowki" funkcji:
>
> push bp
> mov bp, sp
> ...
> pop bp
>
> ale nie miejsce i pora. Raczej ciekawostka historyczna. z czasow x86
>
> PS: Dobrym assemblerowcem bedziesz, gdy bedziesz mial w kapuscie
> wryte zarowno mnemoniki jak i czasy wykonania rozkazow (no ok, dzis
> juz nie tak - cale szczescie - wazne:). Juz nic nie pamietam prawie
> ale CF (far ret) i C3 (near ret) wrylo sie w stary leb.
> Robilo wrazenie gdy (slawek zapewne pamieta/potwierdzi) pisalo sie
> w niejakim programie "debug" programy "z palca" szesnastkowo :)
> PS1: Kiedys rozpoznawalo sie prawiczka w ASM86 gdy pisal mov ax, 0
> miast xor ax,ax. Dzis (i znow cale szczecie:) przestalo i to miec znaczenie.
>

dzisiaj te instrukcja na AX AH i AL nie sa specjalnie krytycznie potrzebne,

pytanie czy wspolczesne kompilatory je nawet wogole generują (i pytanie jest raczej
ZTCW czy generuja je w ilosci mikro czy wogole)

moglby moze miec sens gdyby pomagaly w optymalizacji ale chyba tego nie robia (wogole
dzisaj gdy
cpu wogole nie jest krytyczne tylko memory bandwidth (MB) to co by sie
liczylo to pewnie prostota - i moze ewentualnie 'compactness' w sensie
pewnie lepsza specjalizowana instrukcja do iloczyny skalarnego dwu float4 niz jej
brak) (a to i tak wszystko w tyle za MB)

ew tylko przydalyby sie pewnie

mov byte ptr [eax], value

(bo inaczej pisanie poszczegolnych bajtow byloby utrudnione)

ew
mov eax, byte ptr [ecx]

do czytania pojedynczych bajtow

(ta granulacja bajtowa wogole przydaje sie chyba tylko do ascii
i kompletnie niczego wiecej -
to jak wspominalem chyba by znaczylo ze nalezaloby zrezygnowac z ascii na rzecz
sensownego unicode
i przerzucic sie na 32bitowe bajty]

(wynika tez chyba z tego ze zasadniczo by byc przyjaznym nowoczesnemu hardware
wypadaloby nielubic chara (przynajmniej w jego typowych zastosowaniach - [ew lubic
go tylko w unikalnych sytuacjach gdy pozwala zmniejszyc memory bandwidth (bo
teoretycznie moglby) ale nie wiem czy te sztuczki by dzialaly) ]

w sumie nie wiadomo co jest bardziej pozyteczne - korzysc wynikajaca z malego
rozmiaru pamieci na teksty wynikajaca z ciagle masowego uzywania charow
czy niekorzys wynikajaca z calego babrania sie z unalignmentami w procku (ciezko mi
powiedziec bo
faktem jest ze procek jest bardziej skomplikowany ale ewna korzysc ze
spakowania tekstow tez jest ;c )

do góry

Użytkownik "fir" <p...@g...com> napisał:

> dzisiaj te instrukcja na AX AH i AL nie sa specjalnie krytycznie potrzebne,

Chopie a jak chcesz wziac konkretne bajty/slowa to bedziesz bez potrzeby shiftowal ?
Ja zwykle masz ograniczona wyobraznie :(

AK

do góry

On Friday, August 25, 2017 at 4:52:15 PM UTC-4, slawek wrote:
> On Fri, 25 Aug 2017 11:57:45 -0700 (PDT), Adam M

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

To bardzo ładne stwierdzenia - niestety nie do końca prawdziwe:
- po pierwsze kolega myli problem szczegółowy z problemami ogólnym biorac przyklad
kolegi z morgami - tak to jest prawda ze do 20tysiecy potrzeba znacznie wiecej
parobkow - ale problem tych 20morgow dalej jest tak samo trudny - miałem niestety
doczyniania wielokrotnie z takimi programistami/projektantami systmow - z punktu
wiedzy byli nie do pobicia - znali wiele języków perfekcyjnie, znali algorytmy, cala
teoria w jednym palcu - jednym slowem tytan wiedzy - gdy przyszlo do rozwiazania
problemu to padali jak muchy bo nie potrafili sie zdecydowac jak zabrac sie za
problem (widzieli drzewa ale nie las)
- co do ilosci procesorow - niestety jest bardzo wiele problemow ktore sa niestety
typowo jedno-watkowe - w tym przypadku zastosowanie nawet miliona procesorow nic nie
pomoze dopuki toria algorytmow nie znadzie lepszego algorytmu - ktory da sie
zrownoleglic.

Nie jestem fundamentalista w dziedzinie programowania - ale slepa wiara ze da sie
oderwac programowanie od sprzetu, ze mozna poprawnie programowac bez zrozumienia jak
sprzet na ktorym program bedzie sie wykonywal dziala prowadzi do bardzo poprawnie i
elegancko napisanych i bardzo nieefektywnie dzialajacych programow. I nie mam tu na
mysli 100 linikowego programu pokazujacego wyzszosc np Erlang czy Rust nad C++ ale
zlozonego systemu zaierajacego setk tysiecy lini kodu. Np. eie zycze napisania w
Pytonie czegos wiekszego jak 10-15tys lini kodu:
a) jest to zadanie dla masochisty
b) wiekszosc czasu zostanie spedzona na wyszukiwani bledow spowodowanych zlymi
nazwami zmiennych lub nieporawnymi konwersjami pomiedzy typami (ktore rzekomo w
Pytnie nie powinny stanowic problemu).
c) przez litosc nie wspomne tu nawet o wielowatkowosci w Pytonie

do góry

On Saturday, August 26, 2017 at 3:02:46 PM UTC+2, AK wrote:
> Użytkownik "M.M." <m...@g...com> napisał:
>
> >> > Potem Javę reklamowano [...]
> >> > i że jest językiem pozbawionym wad C++.
> >>
> >> Bo to szczera prawda :)
> >
> > W C++ też można pisać ładny kod, podobny do Javy. Można do
> > minimum ograniczyć preprocesor, przeciążanie operatorów,
> > [...]
>
> Alez mozna!, ale da sie tez zle (i to latwo/"normalnie").
> W Javie sie tak latwo nie da i to jest ta "drobna" roznica
Przyznaję rację.



> > Problem jest w ludziach.
>
> Tak. Jak zawsze.
> Ludzie ogolnie sie dziela na:
> 1. ku potomnosci (blizni mi brat)
> 2. po mnie chocby potop (mam to/innych w d..)
> Tak sie sklada ze od poczatku swej drogi zawodowej
> wykres czestosci obu postaw wsrod polskich progranistow
> przypomina X. Ostatnie lata to nawt wydaje mi sie megalomansko,
> ze prawa-dolna noga tego x jest neico krotsza tylko dlatego ze
> opiera sie jedynie na mym brzuchu. Gdy jego zabraknie (a to juz niebawem)
> to osiagnie wreszcie "upragnione" 0 :)
Ważne żeby sumowały się do jedynki ;-)



> >> > 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.
> >>
> >> Zauwazyles czy "wydumales" ?
>
> > Zauważyłem.
>
> Ok. No to mamy diametralnie inne perspektywy.
> Ciekawe ktora prawdziwsza/blizsza rzeczywistosci.
Mogę przyznać tylko tyle, że nie obserwowałem zbyt często, ale
przewaga w próbie była tak duża, że uznałem to za regułę. Jest
jeszcze taka opcja, że czytając/pisząc te same słowa, myślimy o
czymś innym.

>
> > Ale ja nie mówię o programistach kompulsywnych bez motywacji :)
> > Mówię o programistach którzy chcą programować w innych językach.
>
> Ceownik/Krzyzowiec chcacy pisac w innych jezykach ? Raczej zupelny unikat.
To chyba ja już wiem, dlaczego mamy diametralnie inne perspektywy.
Obserwowałem tylko takich, którym bardzo zależało, wręcz wychodzili
sami z inicjatywą.


> O wiele czesciej "muszacy" (vide slawetny Ober-Ayatollah C++
> Sektor van Skijlen)
Jeśli musi a nie chce, to mamy mucha po urwaniu ostatniej nogi
traci słuch :)



> > Mogę przyznać jedynie odrobinę racji, że gdy programują w Javie i
> > coś zamula, to myślą, że w C++ by to zoptymalizowali - a nie po
> > to biorą Javę.
>
> Mowilem tu lata temu wiec powtorze jakze IMHO ma wciaz prawdziwa maksyme:
>
> "Czym sie rozni programista C++? Tym, ze zanim jeszcze zakoduje,
> juz optymalizuje!"
A ja powiem, że to nic złego, przynajmniej nie zawsze. A jeśli nie
chcesz tak mocno optymalizować, to ja mówię: albo weź Javę, albo
pisz w C++ prawie tak jak w Javie. Ok, masz rację, że ta pokusa
do optymalizacji się pojawia mimowolnie.


> >> Moze sie pobawimy ? Zadania trywialne (nie trzeba stosowac nic poza samym
jezykiem).
> >> Zobaczymy jak sie odnajdziesz w pythonie.
> >>
> >> 1. Sprawdz w petli w C++ i w Pythonie czy wszystkie elementy kolekcji
> >> sa > 3.4 i <= 56.8.
> >> 2. Znajdz w petli w C++ i w Pythonie pierwszy element kolekcji > 3.4 i <= 56.8.
> >> 3. Znajdz w petli w C++ i w Pythonie wszystkie element kolekcji > 3.4 i <= 56.8.
> >>
> >> (kazde w/w to osobne zadanie).
> >
> > Hmmm może moje słowa "lepiej i szybciej odnajdowali się" brzmią trochę
> > jak "znali składnię innego języka bez nauki", ale na pewno nie to
> > miałem na myśli.
>
> Ok, ale pobawmy sie.
> Napisz prosze w C++ i w Pythonie w/w zadanka.
> Napisz je po ptostu "tak z palca", jak umiesz, zeby bylo uczciwie i adekwatnie.
> Chce (a i dla Ciebie mysle byloby to cenne) jak/na ile C++ wycisnal na Tobie
pietno.

Może coś nie tak z moją spostrzegawczością, ale naprawdę nie widzę w tym
nic cennego dla mnie. Po drugie, teraz już na 99% jestem pewny, że
myślimy o czymś innym. Ty proponujesz jednej osobie która nie zna
Pythona napisanie jednej/kilku linii kodu w Pytonie i wyciąganie z
tego jakiś wniosków. Ja mam na myśli wpływ ciężkiego treningu, jaki
przeszła osoba dobrze programująca w C++, na postępy w innych, bardziej
lub mniej podobnych językach programowania. Mówiłem też coś o
chęci i motywacji. Jakbyś mi zaproponował kurs Pythona i kontrakt na
1-2 lata, to wtedy może bym pomyślał, że mamy na myśli to samo.

Pozdrawiam

do góry

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

>> Ceownik/Krzyzowiec chcacy pisac w innych jezykach ? Raczej zupelny unikat.
> To chyba ja już wiem, dlaczego mamy diametralnie inne perspektywy.
> Obserwowałem tylko takich, którym bardzo zależało, wręcz wychodzili
> sami z inicjatywą.

..i tak trzymaj ! (powaznie). Na innych szkoda zwyczajnie czasu.

>> O wiele czesciej "muszacy" (vide slawetny Ober-Ayatollah C++
> > Sektor van Skijlen)
>
> Jeśli musi a nie chce, to mamy mucha po urwaniu ostatniej nogi traci słuch :)

Pracodawca/zycie/rzeczywistosc mu urwal wszystkie nogi (zmusil do C#:)
Z satysfakcja obserwowalem jak zaczal.. chawilc C# :)
(choc oczywiscie te jego chwalenia juz zawsze trzeba brac z rezerwa -
zapewne znow chwali tylko to co.. ON sam zna/uzywa :)

>> Mowilem tu lata temu wiec powtorze jakze IMHO ma wciaz prawdziwa maksyme:
>>
>> "Czym sie rozni programista C++? Tym, ze zanim jeszcze zakoduje,
>> juz optymalizuje!"
>
> Ok, masz rację, że ta pokusa do optymalizacji się pojawia mimowolnie.

Alez chce (i czynie to!), ale dopiero wtedy _gdy to rzeczywiscie jest potrzebne_,
ale nie za wczasu.
PS: Pamietam dobrze taki fakt z moje pierwszej "przemyslowej" pracy (WSK Rzeszow
87r).
Kolega z zespolu - doskonaly inzynier i numeryk napisal w czystym ASM na PC obsluge
floating point bo w/g niego orginalne emulatory z kompilatorow/osobne typu emu287
byly za wolne - i fakt ze byly ale... Sprawa byla powazna bo dotyczyla metod FEM
ktorych
obliczenia trwaly (uklady rownan rozniczkowych czastkowych) dniami i nocami.
Kod byl doskonaly, scisle zoptymalizowany (timingi rozkazow uwzglednione itp).
Wydawalo sie wypas (bo byl to z programistycznego punktu widzenia wypas!) choc ja
mialem
wlasne zdanie w sensie celowosci tego, choc wiedza merytoryczna nie dorastalem
Koledze
do piet (no ale mialm juz za soba kilka ladnych lat z duzych maszyc wiec..)
Skutek finalny: _w praktyce_ zysk byl kilka procent , a za kilka miesiecy pojawili
sie AT-ki
z koprocesorami i cala jego robota (kilka miesiecy) poszla sie zwyczajnie (...) pasc
:(

> Może coś nie tak z moją spostrzegawczością, ale naprawdę nie widzę w tym
> nic cennego dla mnie.

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

AK

do góry

On Sat, 26 Aug 2017 10:32:20 -0700 (PDT), Adam M
<a...@m...com> wrote:
> To bardzo ładne stwierdzenia
> - niestety nie do końca prawdziwe

Tłumacząc na zwykły język: "to prawda z którą nie potrafię się
pogodzić".

Przypominam - wyśmiewałeś tezę że prawo Ahmadla ma zastosowania
ograniczone przez założenia przy jakich zostało sformułowane.

> - co do ilosci procesorów
> - niestety jest bardzo wiele problemow
> ktore sa niestety typowo jedno-watkowe

Istnieje więcej niż jeden problem którego rozwiązanie nie zyskuje na
zwiększaniu liczby wątków. Istnieje więcej niż jeden problem dla
którego zwiększanie liczby wątków jest dobre. Stąd logiczne wnioski:
istnieje wiele problemów jednowątkowych; istnieje wiele problemów
wielowątkowych. Co z tego wynika?
Programowanie wielowątkowe jest potrzebne.

To tak jak z gwoździkami i śrubkami. Ja twierdzę że niekiedy śruby są
potrzebne. Ty upierasz się że wszystko da się zmontować przy pomocy
gwoździ (programów jednowątkowych).

Co ciekawsze: wydaje mi się (ale wymagałoby to głębszego
rozplanowania), że wielowątkowość jest sensowniejszym sposobem
modelowania, bo świat jako taki jest massive parallel.

do góry

W dniu niedziela, 27 sierpnia 2017 08:08:56 UTC+2 użytkownik AK napisał:
wiec..)
> Skutek finalny: _w praktyce_ zysk byl kilka procent , a za kilka miesiecy pojawili
sie AT-ki
> z koprocesorami i cala jego robota (kilka miesiecy) poszla sie zwyczajnie (...)
pasc :(
>

nie cala oszla bo w programowanie (programowanie "czegos") sklada sie z dwu rzeczy -
z 'rozkminiania' i z pisania, /'wdrazania', 'uruchamiania'

rozkminianiae jest chyba mozna powiedziec 'ciezsze' tj trudniejsze
i dluzej trwa (choc pisanie moze byc bardziej ryjące/meczace)

widac to po tym ze jesli ktos juz rozkmini tematy to moze poznij kod
napisac od zera (od czystych plikow) imponujaco szybko
(tak jak ja ostatnio asembler x86 w tydzien - co jest dobrym wynikiem -
a mozliwe bylo to dlatego ze wiekszosc potrzebych rzeczy rozkminilem wczesniej ..
pewnie teraz gdy rozkminilem jeszcze wiecej moglbym napisac od zera asembler w 2 dni)

do góry

Użytkownik "fir" <p...@g...com> napisał:

> a mozliwe bylo to dlatego ze wiekszosc potrzebych rzeczy rozkminilem wczesniej ..
> pewnie teraz gdy rozkminilem jeszcze wiecej moglbym napisac od zera asembler w 2
dni)

I co z tego ?
Chopie nigdy nie bedziesz dobrym programista :(.

Programowanie to sztuka/rzemioslo - tworzone "ku potomnosci" - znaczy: "dla innych".
Ty widzisz tylko czubek wlasnego nosa i nikogo/niczego poza tym, co skutkuje
tworzeniem
nikomu niepotrzebnych (bo juz dawno zrobionych - rozkimanych) rzeczy - czyli
"wymyslaniem
kola na nowo".
Slowem: nie ty jestes tu podmiotem, ale "dzielo" (jego jakosc, a glownie
_przydatnosc_).
Dorosnij, jesli chcech byc programista, a nie jeno kolejnym pryszczatym POspolitym
koderem-sobkiem :(

AK

do góry

W dniu niedziela, 27 sierpnia 2017 12:22:38 UTC+2 użytkownik AK napisał:
> Użytkownik "fir" <p...@g...com> napisał:
>
> > a mozliwe bylo to dlatego ze wiekszosc potrzebych rzeczy rozkminilem wczesniej ..
> > pewnie teraz gdy rozkminilem jeszcze wiecej moglbym napisac od zera asembler w 2
dni)
>
> I co z tego ?
> Chopie nigdy nie bedziesz dobrym programista :(.
>
> Programowanie to sztuka/rzemioslo - tworzone "ku potomnosci" - znaczy: "dla
innych".
> Ty widzisz tylko czubek wlasnego nosa i nikogo/niczego poza tym, co skutkuje
tworzeniem
> nikomu niepotrzebnych (bo juz dawno zrobionych - rozkimanych) rzeczy - czyli
"wymyslaniem
> kola na nowo".
> Slowem: nie ty jestes tu podmiotem, ale "dzielo" (jego jakosc, a glownie
_przydatnosc_).
> Dorosnij, jesli chcech byc programista, a nie jeno kolejnym pryszczatym POspolitym
> koderem-sobkiem :(
>

dziekujemy za wypowiedz...

sam mam inna opinie ale nie bronie koledze miec swojej

do góry

On Sunday, August 27, 2017 at 8:08:56 AM UTC+2, AK wrote:
> Pracodawca/zycie/rzeczywistosc mu urwal wszystkie nogi (zmusil do C#:)
> Z satysfakcja obserwowalem jak zaczal.. chawilc C# :)
> (choc oczywiscie te jego chwalenia juz zawsze trzeba brac z rezerwa -
> zapewne znow chwali tylko to co.. ON sam zna/uzywa :)
Może to jest tak jak w tym kawale, w którym szef nie wie czy ma
leniwych pracowników, czy kiepskich. Jak im daje dwa razy większą
wypłatę, to ma pewność ;-)

A poważnie, to powinno być inaczej niż piszesz. Przejście z Javy,
C#, Pythona na C++ kojarzy mi się z takimi i innymi perturbacjami.
W Javie, C# i Pythonie łatwiej się programuje, trzeba mniej napisać,
głowę ma się mniej zaprzątniętą optymalizacją, szybciej jest radocha z
efektów. Szczególnie jest fajnie, gdy mam narzucone takie języki, bo
wtedy za potencjalnie zbyt małą wydajność i brak pamięci nie ja
odpowiadam. Dla mnie programować w takich językach, to radość w sercu.


> Alez chce (i czynie to!), ale dopiero wtedy _gdy to rzeczywiscie jest potrzebne_,
> ale nie za wczasu.
Szkoda że mogę rozmawiać tylko o amatorskich programach, jak np.
szachach. Dobrze jednak, że właśnie to przydarzyło mi się w
trakcie programowania szachów. Koledzy interfejs konsolowy mieli
napisane na typie char[256], ja, może bardziej wprawiony w
C++, nonszalancko zrobiłem na stringu i text-buforze. Potem
zacząłem robić turnieje z głębokością przeszukiwania ustawioną
na 2 ruchy w głąb. Wąskie gardło z przeszukiwania drzewa
przeszło na readLine, konwersje unicode, konwersje daty, i
mallocki w stringu. Cała praca poszła do kosza, musiałem
robić od nowa, oczywiście doświadczenie mi zostało, protokołów
nie musiałem się uczyć od nowa.


> PS: Pamietam dobrze taki fakt z moje pierwszej "przemyslowej" pracy (WSK Rzeszow
87r).
> Kolega z zespolu - doskonaly inzynier i numeryk napisal w czystym ASM na PC obsluge
> floating point bo w/g niego orginalne emulatory z kompilatorow/osobne typu emu287
> byly za wolne - i fakt ze byly ale... Sprawa byla powazna bo dotyczyla metod FEM
ktorych
> obliczenia trwaly (uklady rownan rozniczkowych czastkowych) dniami i nocami.
> Kod byl doskonaly, scisle zoptymalizowany (timingi rozkazow uwzglednione itp).
> Wydawalo sie wypas (bo byl to z programistycznego punktu widzenia wypas!) choc ja
mialem
> wlasne zdanie w sensie celowosci tego, choc wiedza merytoryczna nie dorastalem
Koledze
> do piet (no ale mialm juz za soba kilka ladnych lat z duzych maszyc wiec..)
> Skutek finalny: _w praktyce_ zysk byl kilka procent , a za kilka miesiecy pojawili
sie AT-ki
> z koprocesorami i cala jego robota (kilka miesiecy) poszla sie zwyczajnie (...)
pasc :(

Cóż mogę powiedzieć. Raczej wszystko jest oczywiste. Po pierwsze, trudno jest
oszacować i nakład pracy na optymalizację, i rozwój sprzętu komputerowego,
choć ostatnimi czasy w operacjach jednowątkowych procesory nie przyspieszają, a
nawet zwalniają. Po drugie, trudno jest przewidzieć o ile się przyspieszy
daną optymalizacją. Po trzecie, nie zawsze wiadomo, jaki będzie zysk z
przyspieszenia o 10%, o 20%, itd. Decyzję o przeprowadzeniu optymalizacji
podejmujemy zazwyczaj w warunkach ogromnej niepewności. Więc rzucanie się
na pisanie dużego fragmentu kodu w takim asemblerze, że w razie zmian w
kodzie/sprzęcie całość pójdzie do kosza, jest zazwyczaj szaleństwem, albo
treningiem, ludzie chcą często z ciekawości lub w ramach nauki sprawdzić.
Z drugiej strony, C++ to nie jest taki asembler, a czasami zwykłe
zakodowanie w C++ z minimalną ilością optymalizacji - wystarczy.
Kolejne optymalizacje zazwyczaj wymagają i więcej pracy, i mniej
przyspieszają.

Jakiś czas temu pisałem program w C++ właśnie bardzo normalnie z minimalną
ilością optymalizacji. Ani razu w trakcie rozwoju projektu nie zapędziłem
się w optymalizacyjny kozi róg. Nawet trzy systemy udało mi się zintegrować w
jeden, co prawda, przy integracji trochę kodu przepisałem, ale to
było relatywnie mało w porównaniu do całego nakładu pracy.


> > Może coś nie tak z moją spostrzegawczością, ale naprawdę nie widzę w tym
> > nic cennego dla mnie.
>
> Ale zobaczysz :) Sam jestem ciekaw.
> Podstaw Pythona nauczysz sie w godzine.

Ale co zobaczę? Chcesz mi pokazać że w pythonie pisze się znacznie mniej
kodu - to wiem, naprawdę szkoda naszego czasu i wysiłku. Chcesz udowodnić, że w
pół godziny jako programista C++ nie rozwiążę tamtych zadań optymalnie,
myślę że masz rację, a ja nie o to się kłóciłem - to jest totalne
nieporozumienie. Czy może chcesz się pośmiać ze mnie, że pętlę
umieszczam na zewnątrz klamerek [], zamiast w środku, a ja się
pośmieję, że nawet w pythonie są krotki w celach optymalizacyjnych?
To by była totalna głupota, więc chyba tego też nie chcesz... Nie
wiem do czego zmierzasz, co zobaczę? A może chcesz mi pokazać że to
będzie działało szybciej niż C++? To tak, to podejmuję wyzwanie.
Albo chcesz mi udzielić darmowej lekcji Pythona... to nie wiem czy
warto, bo w sieci jest sporo materiałów.

Pozdrawiam

do góry