W dniu czwartek, 21 marca 2013 23:00:13 UTC+1 użytkownik Wojciech Muła napisał:
> On Tuesday, March 19, 2013 10:34:18 PM UTC+1, R.e.m.e.K wrote:
> > I naszla mnie watpliwosc. Czy w ogole wspolczesne kompilatory, maszyny
> > wirtualne potrafia te featuresy wykorzystac?
> Potrafią.
No dobrze, ale skąd ta pewność? Czy jesteś pewny na 100% że nie
da się napisać kompilatora który dla przeciętnych programów
wygeneruje kod 2 razy szybszy?
Pozdrawiam

do góry

On 21.03.2013 23:09, M.M. wrote:
> W dniu czwartek, 21 marca 2013 23:00:13 UTC+1 użytkownik Wojciech Muła napisał:
>> On Tuesday, March 19, 2013 10:34:18 PM UTC+1, R.e.m.e.K wrote:
>>> I naszla mnie watpliwosc. Czy w ogole wspolczesne kompilatory, maszyny
>>> wirtualne potrafia te featuresy wykorzystac?
>> Potrafią.
> No dobrze, ale skąd ta pewność? Czy jesteś pewny na 100% że nie
> da się napisać kompilatora który dla przeciętnych programów
> wygeneruje kod 2 razy szybszy?

Cały czas to powstaje. Ostatnio np. w glibc zrobili podstawy obsługi
instrukcji stm w nowych procesorach intela.

--
Pozdrawiam
Michoo

do góry

On 2013-03-21 23:09, M.M. wrote:
> W dniu czwartek, 21 marca 2013 23:00:13 UTC+1 użytkownik Wojciech Muła napisał:
>> On Tuesday, March 19, 2013 10:34:18 PM UTC+1, R.e.m.e.K wrote:
>>> I naszla mnie watpliwosc. Czy w ogole wspolczesne kompilatory, maszyny
>>> wirtualne potrafia te featuresy wykorzystac?
>> Potrafią.
> No dobrze, ale skąd ta pewność? Czy jesteś pewny na 100% że nie
> da się napisać kompilatora który dla przeciętnych programów
> wygeneruje kod 2 razy szybszy?
Pewnie ze da sie, ale dopuki komitent standaryzacyjny bedzie sie
zajmowal abstrakcjami a nie wprowadzal do core jezyka nowych typow
danych ktore sie mapuja 1:1 na nowe sprzetowe rejestry to IMO nic sie
nie poradzi. Wynalazki w postaci intrinsic functions to nie to samo.


Pozdrawiam

Marek

do góry

W dniu piątek, 22 marca 2013 16:27:16 UTC+1 użytkownik Michoo napisał:
> Ca�y czas to powstaje. Ostatnio np. w glibc zrobili podstawy obs�ugi
> instrukcji stm w nowych procesorach intela.
Ano właśnie. Techniki optymalizacyjne implementuje się w kompilatorach
na bieżąco, można domniemać że jutro kompilatory będą lepsze, czyli dziś
są nie inne, tylko gorsze.

> Pewnie ze da sie, ale dopuki komitent standaryzacyjny bedzie sie
> zajmowal abstrakcjami a nie wprowadzal do core jezyka nowych typow
> danych ktore sie mapuja 1:1 na nowe sprzetowe rejestry to IMO nic sie
> nie poradzi. Wynalazki w postaci intrinsic functions to nie to samo
Kilkanaście lat temu rozmawiam ze znajomym. Był on wtedy wykładowcą
na UMK, uczył między innymi programowania w rożnych językach, głównie w C.
W trakcie rozmowy poruszam temat sensowności programowania w asemblerze w
celu przyspieszenia kodu. Pytam na ile dobry kod generują kompilatory
borlanda czy microsoftu. Prawie na mnie się wydarł że to jet niemożliwe
aby generowały nieoptymalny kod. Zdziwiłem się, bo wygenerowanie optymalnego
kodu jest niemożliwe. Pomyślałem więc, że chodzi po pierwsze o to, że
generują optymalny kod w stosunku do nakładu pracy jaki włożono w napisane
tych kompilatorów, a po drugie o to, że włożony nakład pracy był bardzo
duży. Uwierzyłem że są optymalne w takim sensie, że jak się zgromadzi
100 speców od optymalizacji kodu to przez 10 lat pracy napiszą kompilator
lepszy o góra 10%-20%. Tymczasem w ciągu nie więcej niż roku od naszej
rozmowy pojawiły się kompilatory tak efektywne, że czas wykonania wielu
programów skrócił się o 60%, rzadziej o 70%. Więc drugi raz na ten sam numer
nie dam się nabrać :) Ktoś by musiał napisać dużo więcej niż "w intelu się
starają", to wtedy bym uwierzył, że dzisiejsze kompilatory są u szczytu
możliwości. Być może są, ale ja na razie nie wierzę.
Pozdrawiam

do góry

On Thursday, March 21, 2013 11:09:28 PM UTC+1, M.M. wrote:
> W dniu czwartek, 21 marca 2013 23:00:13 UTC+1 użytkownik Wojciech Muła napisał:
>
> > On Tuesday, March 19, 2013 10:34:18 PM UTC+1, R.e.m.e.K wrote:
> > > I naszla mnie watpliwosc. Czy w ogole wspolczesne kompilatory, maszyny
> > > wirtualne potrafia te featuresy wykorzystac?
>
> > Potrafią.
>
> No dobrze, ale skąd ta pewność? Czy jesteś pewny na 100% że nie
> da się napisać kompilatora który dla przeciętnych programów
> wygeneruje kod 2 razy szybszy?

Nie wiem, jak wywnioskowałeś, że coś takiego twierdzę. :)

w.

do góry

W dniu piątek, 22 marca 2013 22:50:53 UTC+1 użytkownik Wojciech Muła napisał:
> On Thursday, March 21, 2013 11:09:28 PM UTC+1, M.M. wrote:
> > No dobrze, ale skąd ta pewność? Czy jesteś pewny na 100% że nie
> > da się napisać kompilatora który dla przeciętnych programów
> > wygeneruje kod 2 razy szybszy?
> Nie wiem, jak wywnioskowałeś, że coś takiego twierdzę. :)

Bardzo prosto :)
Padło pytanie:
> I naszla mnie watpliwosc. Czy w ogole wspolczesne kompilatory, maszyny
> wirtualne potrafia te featuresy wykorzystac?
Odpowiedziałeś:
> Potrafią.

Kontekstem była umiejętność generowania przez kompilatory efektywnego
kodu. Więc tak jakbyś napisał nie tylko że potrafią, ale także że
potrafią to robić bardzo dobrze.

Ale proszę, nie kłóćmy się, w gruncie rzeczy nie chcę Ci imputować
że coś takiego napisałeś. Potraktuj to jako zwykłe pytanie. Czy
jesteś pewny że w rozsądnym nakładzie pracy nie da się napisać
kompilatora który wygeneruje kod:
a) 10 razy szybszy od obecnych,
b) 5 razy szybszy
c) 3 razy szybszy
d) 2 razy szybszy

Pozdrawiam :)

do góry

Dnia Fri, 22 Mar 2013 09:49:48 -0700, M.M. wyszeptal:

> W dniu piątek, 22 marca 2013 16:27:16 UTC+1 użytkownik Michoo napisał:
>> Ca�y czas to powstaje. Ostatnio np. w glibc zrobili podstawy obs�ugi
>> instrukcji stm w nowych procesorach intela.
> Ano właśnie. Techniki optymalizacyjne implementuje się w kompilatorach
> na bieżąco, można domniemać że jutro kompilatory będą lepsze, czyli dziś
> są nie inne, tylko gorsze.

Tak, ale nie aż tyle. Poza tym TM nie jest optymalizacją.

> Tymczasem w ciągu nie więcej niż roku od naszej
> rozmowy pojawiły się kompilatory tak efektywne, że czas wykonania wielu
> programów skrócił się o 60%, rzadziej o 70%. Więc drugi raz na ten sam numer
> nie dam się nabrać :)

Powiem wprost: nie wierzę. Jestem w stanie uwierzyć, że ze 100 testów
syntetycznych jeden się wykonuje na tym samym procu 2.5x szybciej (co
oznacza, że powstał w ramach regression testing), ale nie ogólnie. Pokaż
jakiś przykład.

--
Edek

do góry

W dniu sobota, 23 marca 2013 01:16:11 UTC+1 użytkownik Edek Pienkowski napisał:
> Powiem wprost: nie wierz�. Jestem w stanie uwierzy�, �e ze 100 test�w
> syntetycznych jeden siďż˝ wykonuje na tym samym procu 2.5x szybciej (co
> oznacza, �e powsta� w ramach regression testing), ale nie og�lnie. Poka�
> jaki� przyk�ad.
Nie pokażę, zbyt dużo czasu minęło i nic nie mam. To były pierwsze dobre
kompilatory na pentium I. Przyspieszenie względem starszych kompilatorów
było 2-3 razy.
Pozdrawiam

do góry

W dniu sobota, 23 marca 2013 01:16:11 UTC+1 użytkownik Edek Pienkowski napisał:
> Powiem wprost: nie wierz�. Jestem w stanie uwierzy�, �e ze 100 test�w
> syntetycznych jeden siďż˝ wykonuje na tym samym procu 2.5x szybciej (co
> oznacza, �e powsta� w ramach regression testing), ale nie og�lnie.
> Pokaďż˝
Sorry że tak na raty odpisuję...

Ówczesne kompilatory mogły mieć problem z rozwijaniem funkcji inline. Nowością
była możliwość wykonania kilku instrukcji w jednym takcie (przez procesor). Na
architekturę 32bitową rzadko kto w ogóle programował. Pojawiły się potoki, potok
mógł być przerwany przez skoki warunkowe i dochodziło do ogromnego spowolnienia.
Czyli mamy 4 cechy. Każda cecha niech da przyspieszenie powiedzmy 1.2 razy, to
razem mamy 2.07. Do tego lepsza ogólna optymalizacja kodu i mamy
oszacowanie 2.50.

Przyspieszenie 2.5 raza jakie uzyskano w tamtych czasach mnie nie dziwi.

Pozdrawiam

do góry

ja moge powiedziec tyle ze jak przepisywalem
pewne proste procedury (wzor na przeciecie
promiania ze sfera itp) na asma fpu (zwyklego
nie optymalizowanego tylko po prostu wklepanie
wprost) to osiagalem OIP przyspieszenia 150 - 200 %
ale to w konkurencji ze starym 10-letnim czy
nawet 150letnim dzis komilatorem -
teraz do klepania c/winapi uzywam cztrech malych
kompilatorow naraz (bcc dmc lcc mingw) tak
ze s sumie moglbym skompilowac zdisasemblowac
pomierzyc i porownac jakosc kodu - ale akurat
teraz nie ma troche zajawki na testy, ale moze
pozniej kiedys jak nie bede mial co robic wrzuce

do góry