W dniu niedziela, 20 sierpnia 2017 09:46:42 UTC+2 użytkownik fir napisał:
> W dniu niedziela, 20 sierpnia 2017 02:46:36 UTC+2 użytkownik M.M. napisał:
> > On Saturday, August 19, 2017 at 11:17:57 PM UTC+2, fir wrote:
> > > gdy wydajnosc jest istotna to nawet zwykle wskazniki nie sa wskazane imo
> > >
> > > (kiedys mierzylem ile wolniejszy jest kod gdy dzialasz na tablicy
> > > bedacej wynikiem malloka w stosunku do w pewlni statycznej - i na
> > > malloku bylo auwazalnie 10-20% wolniej
> > Kiedyś chyba też widziałem różnice, ale to był bardzo dawno temu. Teraz
> > chyba tak się nie dzieje na nowych kompilatorach, na nowym sprzęcie i
> > na nowych bibliotekach/systemach?
> >
>
> raczej sie dzieje - trzebby zrobic konkretne testy bo mgliscie to pamietam ale
ustalony (fixed) blok ramu byl szybszy niz ten ze wskaznika
>
> (mozliwe ze bez intelowskiego mechanizmu wirtualizacji pamieci bylby jeszcze
szybszy ;c)
>
> tak czy owak sa to optymalizacyjne detala a dzis tak bardzo tym sie nie przejmuje
>
>
> >
> > > no ale niewazne moze to byla specyficzne sytuacje, podaje jako
> > > anegdote, ostatnio az tak bardzo nie przejmuje sie wydajnoscią
> > A ja jakoś ciągle mam z wydajnością problem. Wciąż szukam
> > szybszych: komputerów, implementacji, algorytmów, opcji kompilatora...
> > Może za trudne zadania liczę. Np. teraz się martwię, czy nie powinienem
> > zamienić drzew czerwono czarnych, na b-drzewa. Może wyszukiwanie w
> > b-drzewach byłoby na tyle szybkie, że nie trzeba robić sztuczki z
> > sortowaniem? Czasami będę miał rozkład prawie równomierny i
> > po posortowaniu będę mógł zastosować wyszukiwanie interpolacyjne.
> > Liczy się przyspieszenie o każde 10%.
> >
>
> szczerze mowiac to ja chyba nie wierze za bardzo w drzewa, nigdy tez zadnego nie
uzywalem - raczej probowalbym robilbym cos na lekkich listach/tablicach - [ale
ostatnio jak mowilem interesuje sie jedynie wybranymi tematami i bardziej chyba musze
skupic sie na skonczeniu pierwszej wersji mojego asemblera x86 a nie wiem czy juz nie
zaczalem sie meczyc :/ ]
>
> >
> >
> > > - nawet moge
> > > powiedziec, kiedys stawialem chyba gdzies tu pytanie jak ktos
> > > zrobilby trzymanie zawartosci edytora tekstowego w programie w c i
> > > kombinowalem wtedy cos w kierunku trzymania listy litych kawalkow
> > > ramu po powiedzmy okolo 500 kb kazdy - dzis
> > > raczej chyba zrobilbym przynajmniej na poczatek do testu tak ze
> > > kazda linijka w edytrze po prostu bylaby na odzielnym malloku
> > > (realokowany w miare
> > > edycji itd)
> > Czasami każdy edytor potrafi się zaciąć, gdy niechcący klikniemy na
> > pliku tekstowym o rozmiarze setek megabajtów lub o długich wierszach.
> > Musisz odpowiedzieć sobie na pytanie, do czego taki edytor ma
> > być używany. Nie ma jednego najlepszego rozwiązania do wszystkich
> > danych, ale jest jedno najlepsze rozwiązanie do rozkładu prawdopodobieństwa
> > tychże danych.
> >
> > Pozdrawiam

odnosnie optymalizacji to moge jeszcze dodac cos bo widzialm gdzies tu jak zwykle te
niemal bezdennie glupie klasyczne pseudodyskusje czy programista zoptymalizuje kod
lepiej niz kompilator itd itd

z tego jak ja to widze psrawa wyglada tak ze programista zoptymalizuje kod lepiej
problem jest jednak w czym innym - dzis - z tego jak to mi sie jawi - kody sa
memory-bound to nie asembler spowalnia kody tylko memory-bandwidth, innymi slowy
problem jest w tym ze nawet 100-krotne zoptymalizowanie arytmetyki moze spowodowac na
przyklad powiedzmy jedynie 1% przyspieszenia - Zupelnie inaczej bylo kiedys kiedy to
memory bound nie bylo widoczne i wszystki liczylo sie predkoscią poszcegolnych
instrukcji, w danej sytuacji przyspieszenie asemblera 100 razy dawalo przyspeszenie
100 razy... dzisiaj (jeli wywalic takie funkcja jak sin sqrt pow exp div) kody sa
glownie memory bound i dlatego przepisywania asma po prostu niewiele daje -
jak robic optymalizacje tego memory bound? nie zajmowalem sie tym za duzo ale zdaje
sie ze na przyklad unikanie malych zmiennych posrednich niewiele przyspiesza (na
szczescie - bo rownoczesnie to zanczy ze mozna ich uywac tj uzywani ich niewiele
spowalnia) .. przepisywanie arytmetyki
jak wspomnialem w sumie sporo daje (mam tu na mysli przepisywanie i upraszcanie
raczej na poziomie c a nie asma) ale i tak sprawa rozbija sie o memory bound (memory
bound jest dzisiaj sciana i jesli mozesz zoptymalizowac asma to tylko DO tej sciany a
nie poza nia - dlatego przepisywanie w asmie nie daje tak jak kiedys przyspieszen
rzedu 10x 30x i dlateo wlasnie nie jest tak wazne jak kiedys) samego memory bound nie
wiem jak przyspieszyc byc moze sie nie da - podstawowe moemory bound liczy sie po
prostu wielkoscią inputu i wielkoscia outputu (w megabajtach) t co ew mogloby to
przyspieszyc to jakies skomplikowane algorytmy selekcjonujace
input i output -- ale to jest skomplikowane i zaciemnia algorytmy
tak ze ja osobiscie o to zbytnie nie dbam
jak zwykle na koniec warto wspomniec
zapewne opencl bo GPU maja mamory bandwidth np 10 razy wiekszy niz procki tak ze jak
ktos chce robic potezny flow przetwazania to pewnie powinien si etego nauczyc ;c

(ogolnie to napisalem wyzej to co wiem na ten temat, sam ostatnio jednak zaczalem jak
wspomnielem mniej interesowac sie optymalizacją - choc ciagle interesuje mnie
rev-engeenereeng /disasembling, vide pisanie asemblera x86)