W dniu czwartek, 18 grudnia 2014 14:12:28 UTC+1 użytkownik g...@g...com
napisał:
> W dniu środa, 17 grudnia 2014 17:08:33 UTC+1 użytkownik bartekltg napisał:
> > > Jezeli dana procedura (taka jak np. liczenie sinusa) gwarantuje,
> > > ze dla tego samego argumentu zawsze uzyskamy ten sam wynik, to nie
> > > ma zadnego powodu, dla ktorego kompilator nie mialby sam tablicowac
> > > wynikow. Nazywanie tego rodzaju optymalizacji "zmiana algorytmu"
> > > wydaje sie jednak dosc pretensjonalne
> >
> > Żeby zmienił sposób liczenia algorytmu - nie ma problemu.
> > Tak robi. Mi wszytko jedno, czy sin będzie policzony
> > koprocesorem czy szeregiem pędzonym SSE.
> > Natomiast zamiana na stablicowanie (nie w tym przypadku, tablica
> > o gęstości precyzyjnej jak sin[x] z interpolacją
> > liniową czy nawet kwadratową jest niepraktyczni duża ) powinna być
> > świadomą decyzją programisty.
> > Lepszym przykładem byłby dwumian newtona wielokrotnie liczony
> > dla małych parametrów. Czasem trzymam sobie go w pamięci,
> > ale czasem cache możę być znacznie przydatniejsze gdzie indziej,
> > i te kilka pętli jest lepszym wyjściem.
>
> Tzn oczywiscie, jezeli zamiast liczyc wynik, dokonujemy interpolacji,
> to tego rodzaju optymalizacja wydaje sie niedopuszczalna, chyba ze
> programista dopusci ja explicite
>
> > > Poza tym, jezeli nie mialoby to wplywu na obserwowalne zachowanie programu,
> > > to nie widze powodu, dla ktorego kompilator nie mialby w okreslonych
> > > okolicznosciach zamieniac bubblesorta na qsorta (choc w tym kontekscie
> > > oczywiscie stwierdzenie "zamiana algorytmu" wydaje sie jak najbardziej
> > > na miejscu).
> >
> > A skąd kompilator ma wiedzieć, co mam na myśli.
>
> Kompilator moze wiedziec, jaka funkcje realizuje Twoja procedura,
> i jezeli zna wydajniejsza procedure realizujaca te sama funkcje,
> to moze ja zastapic
>
> > To, że potrzebuję akurat stabilnego sortowania będzie w stanie wyłapać?
>
> Jezeli Twoj algorytm sortuje stabilnie, to oczywiscie -- zeby procedura
> wygenerowana przez kompilator realizowala te sama funkcje -- algorytm
> wynikowy musialby rowniez sortowac stabilnie
>
> > Pamiętaj, że kompilator na zanalizować kod, a nie widzi intencje przez
> > użycie sort czy stable_sort.
> > A może zawsze ten algorytm sortuje jedynie malutkie tablice.
> > Albo wstępnie posortowane (dla insertsorta).
>
> Oczywiscie, zdarzaja sie przypadki graniczne, dla ktorych
> wydajnosc kodu zoptymalizowanego przez kompilator jest gorsza,
> niz wydajnosci kodu niezoptymalizowanego
>
> > Kompilator musiałby zrozumieć nie tylko kod, ale i intencje
> > piszącego, oraz to, czy jest baranem, czy taki a nie inny
> > sposób przetwarzania danych wynika z jakiejś głębszej analizy.
>
> Dla kompilatora nie ma roznicy pomiedzy kodem a intencja
> piszacego. (Oczywiscie z tego wzgledu jest lepiej, jezeli
> jezyk programowania umozliwia programiscie dokladne wyrazanie
> swoich intencji)
>
> > > Istnieja ciekawe metody dotyczace optymalizacji algorytmow,
> > > opisane np. tutaj:
> > > http://repository.readscheme.org/ftp/papers/topps/D-
170.ps.gz
> >
> > Bardzo dokładnie się nie wczytałem, ale czy rozwiązywanie
> > sporych NP zupełnych problemów grafowych podczas kompilacji
> > nie jest chwilowo przesadą? ;-)
>
> To oczywiscie zalezy od sytuacji, ale czesto do rozwiazywania
> NP-trudnych problemow istnieja dobre heurystyki dzialajace
> wydajnie na typowych przypadkach
>
> > >>> jeszcze kombinowalem z rugowaniem castow i
> > >>
> > >> To samo. Każesz kompialtorowi liczyć danymi zmiennymi, musi nimi
> > >> liczyć.
> > >
> > > Nie bardzo rozumiem te uwage, ale znow: jezeli kompilator moze w jakims
> > > kontekscie dokonac czesciowej ewaluacji, to nie ma istotnego powodu, dla
> > > ktorego nie mialby tego robic
> >
> > Masz dwa programy. Jeden liczy coś intami, drugi na float.
> > Wyniki _NIE_ bądą identyczne, poza przypadkami, gdzie obłożymi
> > warunkami praktycznie wszystko.
>
> Wyglada na to, ze wyinterpretowales z wypowiedzi firra duzo wiecej
> niz ja :]
> Ja nie wiem, czy on dokonywal jakichs interpolacji na sinusach. Byc
> moze oryginalny algorytm byl napisany w taki sposob, ze sinusy byly
> brane tylko z pewnego dyskretnego rownomiernie rozlozonego podzbioru
> odcinka [0, 2pi) i bystry kompilator moglby teoretycznie to zauwazyc
> i stablicowac wartosci sinusa?
>
> Dalej firr rzeczywiscie pisal cos o interpolacjach -- i zgodze sie,
> ze tego rodzaju optymalizacja jest juz dla semantyki programu inwazyjna,
> ale z Twojej odpowiedzi wynikalo, ze zastapienie wywolan funkcji
> stablicowanymi wartosciami stanowi zmiane algorytmu. Oczywiscie mozna
> dzielic wlos na czworo i dowodzic, ze tak jest, ale moim zdaniem jest
> to jedna z prostszych nieinwazyjnych optymalizacj, jakie kompilator
> moglby przeprowadzac.

kolega b sobie wymyslil ze ja cos twierdze co mu sie nie podoba i zaczal nawet uzywac
slowek (obok serji glupot
rzekomo odnoszacych sie do tego co ja mowie) - teraz nie che mi sie nawet do tego
odnosci bo to sa przygnebiajace durnoty na ktore nie mam po prostu czasu,

nie odchodze na razie z tej grupy (dont panic;o) ale tego rodzaju rozmowy już sobie
raczej daruje

do góry

On Tuesday, December 16, 2014 11:53:06 PM UTC+1, M.M. wrote:
> On Friday, July 18, 2014 10:34:42 AM UTC+2, Wojciech Muła wrote:
> > Wstawki asemblerowe robi się dla celów wydajnościowych,
> > kompilatory nie zawsze dają radę.
> > A już kompletnie nie
> > dają sobie rady w nietrywialnych przypadkach.
> Temat wraca. Nie wiem co to są nietrywialne przypadki.

Podałem przykłady.

> Moim zdaniem kompilatory rzadko generują optymalny kod,
> ale często nie stanowi to problemu.

Oczywiście, w większości zastosowań wydajność nie ma kluczowego
znaczenia. Problem pojawia się, gdy trzeba przetworzyć np. sto
milionów rekordów w ciągu godziny.

> W niektórych wersjach kompilatorów miałem wrażenie, że
> mała wstawka w asemblerze pogarszała wydajność.

Ja po prostu mierzę, intuicja mnie zawiodła tyle razy, że
powinienem się z nią rozwieść. :) Dużo można zyskać dzięki
lepszemu rozmieszczeniu danych w pamięci.

w.

do góry

On Thursday, December 18, 2014 7:34:38 PM UTC+1, Wojciech Muła wrote:
> On Tuesday, December 16, 2014 11:53:06 PM UTC+1, M.M. wrote:
> > On Friday, July 18, 2014 10:34:42 AM UTC+2, Wojciech Muła wrote:
> > > Wstawki asemblerowe robi się dla celów wydajnościowych,
> > > kompilatory nie zawsze dają radę.
> > > A już kompletnie nie
> > > dają sobie rady w nietrywialnych przypadkach.
> > Temat wraca. Nie wiem co to są nietrywialne przypadki.
>
> Podałem przykłady.
>
> > Moim zdaniem kompilatory rzadko generują optymalny kod,
> > ale często nie stanowi to problemu.
>
> Oczywiście, w większości zastosowań wydajność nie ma kluczowego
> znaczenia. Problem pojawia się, gdy trzeba przetworzyć np. sto
> milionów rekordów w ciągu godziny.
>
> > W niektórych wersjach kompilatorów miałem wrażenie, że
> > mała wstawka w asemblerze pogarszała wydajność.
>
> Ja po prostu mierzę, intuicja mnie zawiodła tyle razy, że
> powinienem się z nią rozwieść. :) Dużo można zyskać dzięki
> lepszemu rozmieszczeniu danych w pamięci.

Ostatnio w swoich programach nie robię żadnej innej
optymalizacji, poza optymalizacją algorytmiczną i rozmieszczeniem
danych w ram, albo na dysku. Nie mam czasu na taką zabawę.


Pozdrawiam

do góry

W dniu czwartek, 18 grudnia 2014 19:54:23 UTC+1 użytkownik M.M. napisał:
> On Thursday, December 18, 2014 7:34:38 PM UTC+1, Wojciech Muła wrote:
> > On Tuesday, December 16, 2014 11:53:06 PM UTC+1, M.M. wrote:
> > > On Friday, July 18, 2014 10:34:42 AM UTC+2, Wojciech Muła wrote:
> > > > Wstawki asemblerowe robi się dla celów wydajnościowych,
> > > > kompilatory nie zawsze dają radę.
> > > > A już kompletnie nie
> > > > dają sobie rady w nietrywialnych przypadkach.
> > > Temat wraca. Nie wiem co to są nietrywialne przypadki.
> >
> > Podałem przykłady.
> >
> > > Moim zdaniem kompilatory rzadko generują optymalny kod,
> > > ale często nie stanowi to problemu.
> >
> > Oczywiście, w większości zastosowań wydajność nie ma kluczowego
> > znaczenia. Problem pojawia się, gdy trzeba przetworzyć np. sto
> > milionów rekordów w ciągu godziny.
> >
> > > W niektórych wersjach kompilatorów miałem wrażenie, że
> > > mała wstawka w asemblerze pogarszała wydajność.
> >
> > Ja po prostu mierzę, intuicja mnie zawiodła tyle razy, że
> > powinienem się z nią rozwieść. :) Dużo można zyskać dzięki
> > lepszemu rozmieszczeniu danych w pamięci.
>
> Ostatnio w swoich programach nie robię żadnej innej
> optymalizacji, poza optymalizacją algorytmiczną i rozmieszczeniem
> danych w ram, albo na dysku. Nie mam czasu na taką zabawę.
>
mz troche optymalizowac chyba "należy",
ale czy "optymalizowac dużo" to juz jest calkiem inny problem
- nie dosc ze te sesje optymalizacyjne troche trwają (zwykle chyba co najmniej z
tydzien, po czym z drugie tyle jak nie wiecej na odpoczynek [co prawda wlasciwie
zawsze mz te sesje mi sie oplacają]) - to samo nauczenie sie tej optymalizacji (i
internalsów) zajmuje juz raczej pare lat siedzenia na tylku w temacie
(nawet nie wiem czy w moim wypadku by sie to dalo rozdzielic i zajac "po prostu
produkcją", - ludzi spowalnie chyba zresztą nie tylko 1) optymalizacja ale
2) skomplikowanie ich wlasnej bazowej technologii 3) wielosc dostepnych 'tematow'

inna sprawa ze ja np chyba jestem wyjatowo wolnym koderem (wnioskuje np po czytanie
blogow niektorych i widze jak sie szybko uczą 50 rzeczy w tym czasie gdy ja sie
potrafie nauczyc pewnie dwu)
- kod pisze raczej mw tak samo szybko jak kazdy (te pareset lini na dzien, raz
mniejsze parestet raz wieksze) ale o wiele wolniej przychodzi mi sie uczenie takich
rzeczy jak platformy (frameworki/api/jezyki), zawsze mi to szlo jakos bardzo wolno -
przyswajanie nowych "tematow" (dziedzin) tez bardzo wolno..

do góry

W dniu czwartek, 25 grudnia 2014 10:08:02 UTC+1 użytkownik firr napisał:
> (frameworki/api/jezyki), zawsze mi to szlo jakos bardzo wolno - przyswajanie nowych
"tematow" (dziedzin) tez bardzo wolno..

sa ludzie ktorzy potrafia to robic szybko,
wydawaloby sie ze skoro robia to szybko to moze robia to kiepsko, ale nie - oni
potrafia robic to i szybko i dobrze;
ja do nich nie naleze, z kolei moim plusem jest chyba umiejetnosc robienia
pewnego rodzaju filozofii- (czemu jednak nie umiem tak szybko lykac tych platform i
tematow to nie wiem, troche sie to moze zmiania bo badz co badz troche doswiadczenia
juz jest, zarazem tez sie czuje nieststy troche juz przjechany walcem zycia (problemy
zdrowotne itp) tak ze sam ciekaw jestem co z tego bedzie dalej] 9obecnie statram sie
rozwiklac format pe/ by miec to z glowy ale metne tutoriale mnie przygnebiaja trzebe
bylo to zrobic z 10 lat temu ;/

do góry

On Thursday, December 25, 2014 10:26:59 AM UTC+1, firr wrote:
> sa ludzie ktorzy potrafia to robic szybko,
> wydawaloby sie ze skoro robia to szybko to moze robia to
> kiepsko, ale nie - oni potrafia robic to i szybko i dobrze;
Po doświadczeniach wyniesionych z programowania szachów widzę, że
nie ma osób które robią to dobrze i szybko. Każdy się motał
strasznie, każdy miał wiele kiepskich pomysłów, potem poprawiał, w
końcu brał pomysły wypracowane przez lata doświadczeń innych
programistów. Generalnie to jest praca na całe lata. A przecież
szachy, to jeszcze nie taki trudny problem... 64 pola, parę figur,
parę ruchów.

Pozdrawiam

do góry

W dniu czwartek, 25 grudnia 2014 12:41:29 UTC+1 użytkownik M.M. napisał:
> On Thursday, December 25, 2014 10:26:59 AM UTC+1, firr wrote:
> > sa ludzie ktorzy potrafia to robic szybko,
> > wydawaloby sie ze skoro robia to szybko to moze robia to
> > kiepsko, ale nie - oni potrafia robic to i szybko i dobrze;
> Po doświadczeniach wyniesionych z programowania szachów widzę, że
> nie ma osób które robią to dobrze i szybko. Każdy się motał
> strasznie, każdy miał wiele kiepskich pomysłów, potem poprawiał, w
> końcu brał pomysły wypracowane przez lata doświadczeń innych
> programistów. Generalnie to jest praca na całe lata. A przecież
> szachy, to jeszcze nie taki trudny problem... 64 pola, parę figur,
> parę ruchów.
>
nie wiem jak w szachach ale sa ludzie ktory potrafia szybko przyswoic i 'zakodowac'
nową technoligie albo nowy temat - sa tacy ;/

(wspominam troche bez zwiazku bo mnie naszlo, czytam czasem na blogach itp jak
niektorzy czasem szybko lykaja rozne technologie, ja taki oblatany nie jestem ;/

do góry

On Thursday, December 25, 2014 1:24:36 PM UTC+1, firr wrote:
> W dniu czwartek, 25 grudnia 2014 12:41:29 UTC+1 użytkownik M.M. napisał:
> > On Thursday, December 25, 2014 10:26:59 AM UTC+1, firr wrote:
> > > sa ludzie ktorzy potrafia to robic szybko,
> > > wydawaloby sie ze skoro robia to szybko to moze robia to
> > > kiepsko, ale nie - oni potrafia robic to i szybko i dobrze;
> > Po doświadczeniach wyniesionych z programowania szachów widzę, że
> > nie ma osób które robią to dobrze i szybko. Każdy się motał
> > strasznie, każdy miał wiele kiepskich pomysłów, potem poprawiał, w
> > końcu brał pomysły wypracowane przez lata doświadczeń innych
> > programistów. Generalnie to jest praca na całe lata. A przecież
> > szachy, to jeszcze nie taki trudny problem... 64 pola, parę figur,
> > parę ruchów.
> >
> nie wiem jak w szachach ale sa ludzie ktory potrafia szybko przyswoic i 'zakodowac'
nową technoligie albo nowy temat - sa tacy ;/
>
> (wspominam troche bez zwiazku bo mnie naszlo, czytam czasem na blogach itp
> jak niektorzy czasem szybko lykaja rozne technologie, ja taki oblatany nie
> jestem ;/
Opłaca się to zwłaszcza gdy nowa technologia jest do dupy. Jak było gdy się
uczyłeś WINAPI? Miała być taka rewelacyjna? A teraz jak powiesz ze umiesz
w tym programować, to znaczy że jesteś idiotą, bo stracileś czas na opanowanie
technologii.

do góry