🚀 go-pugleaf

W dniu sobota, 28 grudnia 2019 12:11:16 UTC+1 użytkownik (fir) napisał:
> W dniu sobota, 28 grudnia 2019 11:58:53 UTC+1 użytkownik (fir) napisał:
> > W dniu sobota, 28 grudnia 2019 11:52:58 UTC+1 użytkownik (fir) napisał:
> > > W dniu sobota, 28 grudnia 2019 11:50:11 UTC+1 użytkownik M.M. napisał:
> > > > On Saturday, December 28, 2019 at 10:26:57 AM UTC+1, (fir) wrote:
> > > > > W dniu sobota, 28 grudnia 2019 10:11:26 UTC+1 użytkownik (fir) napisał:
> > > > > > W dniu sobota, 28 grudnia 2019 03:44:41 UTC+1 użytkownik M.M. napisał:
> > > > > > > On Friday, December 27, 2019 at 10:01:25 PM UTC+1, (fir) wrote:
> > > > > > > > W dniu piątek, 27 grudnia 2019 21:54:14 UTC+1 użytkownik M.M. napisał:
> > > > > > > > > On Friday, December 27, 2019 at 8:18:46 PM UTC+1, (fir) wrote:
> > > > > > > > > > W dniu piątek, 27 grudnia 2019 20:12:09 UTC+1 użytkownik M.M. napisał:
> > > > > > > > > > > On Friday, December 27, 2019 at 7:48:22 PM UTC+1, (fir) wrote:
> > > > > > > > > > > > a co z dezasemblacja? to calkiem proste a wiele by wyjasnilo
> > > > > > > > > > > 
> > > > > > > > > > > Jest kilka problemów z tym. Nie znam zasad łączenia instrukcji w pary/trójki 
> > > > > > > > > > > żeby procesor mógł je wykonać równocześnie, o czasach wykonania nie wspomnę.
> > > > > > > > > > > No i bym musiał procedurę zostawić w asemblerze, dopracować ją (czytaj: napisać
> > > > > > > > > > > lepiej niż kompilator) i utrzymywać w asemblerze. Wiec nawet jak znajdę
> > > > > > > > > > > wyjaśnienie, to chyba nic mi z tego.
> > > > > > > > > > > 
> > > > > > > > > > > Pozdrawiam
> > > > > > > > > > 
> > > > > > > > > > chodzi o dezasemblacje i zobazenie co sie zmienilo miedzy ta wolniejsza a szybsza wersje a nie o pisanie asma (ktore nie jest zreszta wcale takie trudne mysle ze idzie sie nauczyc w dzien (choc sam nie pisalme jeszcze 64 bitowego asma)
> > > > > > > > > 
> > > > > > > > > Zgodzę się, że dla kogoś kto biegle zna i używa asemblera na 386, byłby to
> > > > > > > > > dobry przykład jak należy, a jak nie należy pisać wydajny kod w asemblerze.
> > > > > > > > > Ja piszę w C++, dla mnie wstawka jednej instrukcji w asemblerze (np. to
> > > > > > > > > popcount, xchange, rot) maksymalne użycie asemblera. Taki ktoś jak ja 
> > > > > > > > > chyba nie wyniesie z tego żadnej nauki?
> > > > > > > > > 
> > > > > > > > jak to nie - zdezasembluj a dostaniesz odpowiedz na swoje pytaie czemu jest szybciej..jak nie umiesz czytac asma to zapostuj go na grupie tylko trzeba by zdizasemblowac odpowiednie kawalki
> > > > > > > 
> > > > > > > Nie chciałem powiedzieć, że nie można się dowiedzieć z asemblera, tylko że jak
> > > > > > > się dowiem, to nie spożytkuję tej wiedzy w innych programach. Ale nie ma
> > > > > > > problemu, to tylko dodanie opcji -S do kompilatora:
> > > > > > > 
> > > > > > > https://pastebin.com/xriqX0SS
> > > > > > > 
> > > > > > > Które to kawałki - trudno powiedzieć. Może testy oddziela instrukcja:
> > > > > > > 
> > > > > > > movabsq	$6364136223846793005
> > > > > > > 
> > > > > > > Pozdrawiam
> > > > > > > 
> > > > > > > Pozdrawiam
> > > > > > 
> > > > > > potrzebujesz napisac test w minimalnej wersji w c (tak zeby nie nylo niepotrzebnych wywolan) po czym zdizasemblowac wlasnie ten kawalek
> > > > > > (najlepiej w tej normalnej skladni a nie w tej i z komentarzami)
> > > > > > 
> > > > > > tutaj ja bym znalazl latwo te kawalki ale nie je pisalem bazowy kod i nie mam go w pamieci (zwlaszcza ze jest napisany w durnym dla mnie c++) po co tu sa wywolywane te wywolania do marsenne twister mialo chodzic o oryginalny kod z loopami, ciezko mi zmapowac to na kod w c ktorego nie znam, choc generalnie widac ze jest jak kawa na lawe - jako ze pokazuje nazwy funkcji ktore wola wywolaj sobie cos o uniklanej nazwie na poczatklu i koncu kawalka i znajdz przec control+f w teksiecie
> > > > > > 
> > > > > > widac ze np jedna z oimawianych petli jest 
> > > > > > 
> > > > > > .L76:
> > > > > >     movl    28832(%rsp), %eax   # rndBuf.select, D.82123
> > > > > >     leal    1(%rax), %edx   #, tmp522
> > > > > >     testb   $1, %al #, D.82123
> > > > > >     movl    %edx, 28832(%rsp)   # tmp522, rndBuf.select
> > > > > >     jne .L138   #,
> > > > > >     movq    28824(%rsp), %rbp   # rndBuf.i2, D.82124
> > > > > >     cmpq    %r14, %rbp  # tmp566, D.82124
> > > > > >     je  .L139   #,
> > > > > > .L72:
> > > > > >     leaq    4(%rbp), %rax   #, tmp555
> > > > > >     movq    %rax, 28824(%rsp)   # tmp555, rndBuf.i2
> > > > > >     movl    0(%rbp), %eax   # *_756,
> > > > > >     addq    %rax, %r13  # D.82120, sum
> > > > > >     subq    $1, %r12    #, D.82120
> > > > > >     jne .L76    #,
> > > > > > .L137:
> > > > > > 
> > > > > > 
> > > > > > ale nei wiem dokladnie ktory to kawalek jak mowie trzeba to zdizasemblowac kawalkami i najlepiej napisac to w c wtedy widac co i jaki nie ma tez w tym nic trudnego tyle ze mi nieprzyjemnie jest debugowac czyjs kod na ktory nie moge patrzec bo jest w c++ i nie mam ogarniete jak on w calosci wyglaa
> > > > > 
> > > > > testowanie i optymalizowanie wymaga duzo przepisywania tak ze mysle ze kolega powinien byc gotow na rozbicie tych 5-ciu czy tam ile testow na 5 minimalnych kilkolinijkowcow w c i zdezasemblowanie ich
> > > > 
> > > > Nadal nie rozumiem jakie korzyści z analizy asemblera będę miał jako 
> > > > programista C++. Kiedyś byle jak napisana procedura w AMS działała 3
> > > > razy szybciej niż porządnie napisana w C i z 5 razy szybciej niż w C++.
> > > > Ale te czasy minęły, teraz trzeba bardzo dużo pracy włożyć aby czasami
> > > > pokonać kompilator o parę procent. Ja raczej bym chciał lepiej wiedzieć 
> > > > jak pisać w C++ aby kompilator generował efektywny kod przy zachowaniu 
> > > > chociaż minimalnej przejrzystości kodu i podatności na rozbudowę. 
> > > > 
> > > jaki korzysci? poprostu odpowiedz na kolegi pytanie dlazego tu jest wolniej a dlaczego szybciej - akurat ta odpowiedz warto sobie sprawdzic a nie jest to wcale duzo roboty 
> > > 
> > > gdyby ja to pisal sprawdzilbym sobie to mysle w ciagu 20 minut i bym po prostu wiedzial
> > 
> > co do tego przyspieszania o kilka procent to nie jestem taki pewien, mi samemu nie chce sie grzebac w asmie ale to zalezy od tego jaki wogole jest powod do optymalizacji (gdybym mial to bym zaczal pewnie na pisanie kodow przy pomocy skalarow lub intrinsicow ale ogladal tez kod w asmie)
> > 
> > ogolnie to jak pisalem sam nie robie teraz optymalizacji czyli tutaj bym wzial zwykle rand()%modulo ew napisal sobie w minute druga wersje z cache w postaci tablicy statycznej n elementow gdyby mi naprawde bardziej zalezalo
> > 
> > duzo wiekszym problemem w programowaniu jest dla mnie teraz kreatywnosc a nie optymalizacja - (ale nie neguuje ze warto sie jej nauczyc, warto jej tez uzywac tez nie neguje, tyle ze dla mnie osobiscie to nie jest ten moment)
> 
> 
> ew niech kolega napisze ze dwa te testy
> w czystym c w postaci jednego pliku c (moge byc bez funkcji miezenia czasu, sam rdzen sprawy
> 
> 
> test1() {.. }
> test2() {.. }
> 
> main()
> {
>   test1();
>   test2();
> }
> 
> to ew moge zdizasemblowac u siebie (co prawda to chyba bez sensu bo ja ciagle siedze na 32 bitowym xp (z wlasnego wyboru), a moj komp w win10 od lat w drugim pokoju porasta kurzem (i nie che mi sie na nim testowac bo musialbym przynosic odkurzac, przyzwyczajac sie do edytorow i okienek na zimniejszym w odczuciu systemie itd itd)
> 
> sama dizasemblacje z kolei lubie spozieranie w asma nie jest zle (dodam ze sam jestem tworca asemblera (org-asm, fajne bajery z tym asmem) sam sie zastanawiam czy nie warto by wrocic i w nim pogrzebac

aha w sumie to mozna zdizasemblowac online, ale wolalbym by kolega napisal ten kod w wersji c i mozemy zobaczyc