Użytkownik "bartekltg" <b...@g...com> napisał:

> Jeśli to jest drzewo, to w dół idzie unique_ptr, a w górę choćby goły
> wskaźnik. Ten goły zawsze jest ważny, bo obiekt w którym jest istnieje
> tylko, jesli obiekt nadrzędny istnieje.

Nie goly wskaznik, tylko normalniej: weak_pointer

PS: Najlepiej zapomniec o "zwyklych"/"golych"wskaznikach.
Doposzczalne winny byc jedynie w narzedziowce i to "on demand; (tak jak to
zrobiono w C#)

AK

do góry

On Saturday, August 19, 2017 at 9:52:57 PM UTC+2, AK wrote:
> Użytkownik "bartekltg" <b...@g...com> napisał:
>
> > Jeśli to jest drzewo, to w dół idzie unique_ptr, a w górę choćby goły
> > wskaźnik. Ten goły zawsze jest ważny, bo obiekt w którym jest istnieje
> > tylko, jesli obiekt nadrzędny istnieje.
>
> Nie goly wskaznik, tylko normalniej: weak_pointer
>
> PS: Najlepiej zapomniec o "zwyklych"/"golych"wskaznikach.
> Doposzczalne winny byc jedynie w narzedziowce i to "on demand; (tak jak to
zrobiono w C#)
>
> AK

Gdy wydajność nie jest istotna, to trzeba korzystać z wszelkich
tego typu udogodnień.
Pozdrawiam

do góry

W dniu sobota, 19 sierpnia 2017 23:02:17 UTC+2 użytkownik M.M. napisał:
> On Saturday, August 19, 2017 at 9:52:57 PM UTC+2, AK wrote:
> > Użytkownik "bartekltg" <b...@g...com> napisał:
> >
> > > Jeśli to jest drzewo, to w dół idzie unique_ptr, a w górę choćby goły
> > > wskaźnik. Ten goły zawsze jest ważny, bo obiekt w którym jest istnieje
> > > tylko, jesli obiekt nadrzędny istnieje.
> >
> > Nie goly wskaznik, tylko normalniej: weak_pointer
> >
> > PS: Najlepiej zapomniec o "zwyklych"/"golych"wskaznikach.
> > Doposzczalne winny byc jedynie w narzedziowce i to "on demand; (tak jak to
zrobiono w C#)
> >
> > AK
>
> Gdy wydajność nie jest istotna, to trzeba korzystać z wszelkich
> tego typu udogodnień.
> Pozdrawiam

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

no ale niewazne moze to byla specyficzne sytuacje, podaje jako anegdote, ostatnio az
tak bardzo nie przejmuje sie wydajnoscią - 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)

do góry

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?


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



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

do góry

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

do góry

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)

do góry

W dniu niedziela, 20 sierpnia 2017 10:14:33 UTC+2 użytkownik fir napisał:
> samego memory bound nie wiem jak przyspieszyc byc moze sie nie da -

to dlaczego memory bound jest takie jak jest zalezy od producentow hardware (okazuje
sie wlasnie ze to nie predkosc procka mimo ze wszyscy ciagle o tym mowia jest wlasnie
dzis kluczowa tylko predkosc ramu ) CZEMU to nie jest przyspieszane (bo wydaje sie ze
mozna tylko trzeba poszerzac jakies magistrale itd co chyba mozna robic) pytalem na
roznych forach ale nikt nie wiedzial i nikt nic nie powiedzial - jak ktos sie dowie
niech mi powie ;\ (mozliwe tez ze w koncu to zrobia i kompy znowu ruszą z kopyta, ale
nie wiem bo to bajanie jesli nei wiadomo co jet przyczyna i o co tu chodzi)

do góry

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

> gdy wydajnosc jest istotna to nawet zwykle wskazniki nie sa wskazane imo
[...]

Boooże jedyny ! Niemozliwe satlo sie faktem !
Fir wreszcie napisal cos w miare ("w miare" - bo mysle ze testowal samegpo malloca :)
a nie tylko
pamiec nim przydzielona)
sensownego !

AK

do góry

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

> A ja jakoś ciągle mam z wydajnością problem.

Ba! :)

> Wciąż szukam szybszych: komputerów,

daj se spokoj...

> implementacji, algorytmów,

Tu poswiec 99% czasu !

> opcji kompilatora...

daj se spokoj...

> Może za trudne zadania liczę.

Brawo. Takie sa najsmaczniejsze :)

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

Znow az milo czytac :)

> Liczy się przyspieszenie o każde 10%.

Dobierajac/"customizujac" dobry /sprawdzony algorytm mozna zyskac
nawet 10^x (x >=1) a nie tylko "marne" 10^-1

AK

do góry

W dniu niedziela, 20 sierpnia 2017 10:26:20 UTC+2 użytkownik fir napisał:
> W dniu niedziela, 20 sierpnia 2017 10:14:33 UTC+2 użytkownik fir napisał:
> > samego memory bound nie wiem jak przyspieszyc byc moze sie nie da -
>
> to dlaczego memory bound jest takie jak jest zalezy od producentow hardware
(okazuje sie wlasnie ze to nie predkosc procka mimo ze wszyscy ciagle o tym mowia
jest wlasnie dzis kluczowa tylko predkosc ramu ) CZEMU to nie jest przyspieszane (bo
wydaje sie ze mozna tylko trzeba poszerzac jakies magistrale itd co chyba mozna
robic) pytalem na roznych forach ale nikt nie wiedzial i nikt nic nie powiedzial -
jak ktos sie dowie niech mi powie ;\ (mozliwe tez ze w koncu to zrobia i kompy znowu
ruszą z kopyta, ale nie wiem bo to bajanie jesli nei wiadomo co jet przyczyna i o co
tu chodzi)

dla kompletnosci moge dodac jeszcze temat cache - cache w tym co ja mierzyl;em nigdy
nie mialo znaczenia tj kod zachowywal sie tak jakby zawsze dzialal ze 100% trafnoscią
w cache czyli z predkoscią ramu - mozliwe ze te problemy z cache bardziej dotyczna
starszych kompow typu pentium 3 lub tez mozliwe ze dotycza zle napisanych kodow z
duza iloscia skakania po danych - moich kodow to jakos wogol enie dotyczylo

inna ew ciekawa kwestia jest taka - memory bound jest odzielna na rdzen tj
dwa rdzenie maja dwukrotnosc memory bandwidth jednego rdzenia, nie wiem
natomiast jak to jest z tymi logicznymi rdzeniami - czy dwa logiczne rdzenie maja 2x
memory bandwidth czy tez dzielą jedną pulę
jakby na pół (nie mam pojecia a od
wyniku odpowiedzi na to pytanie szczerze mowiac sporo zalezy jesli chodzi o kwestie
patrzenia na te logiczne rdzenie - spodziewam sie jednak szczerze mowiac gorszej
wiadomosci tj ze dzielą pule na pol)

do góry