On Saturday, March 23, 2013 12:28:41 AM UTC+1, M.M. wrote:
> Bardzo prosto :)
> Padło pytanie:
>
> > I naszla mnie watpliwosc. Czy w ogole wspolczesne kompilatory, maszyny
> > wirtualne potrafia te featuresy wykorzystac?
>
> Odpowiedziałeś:
>
> > Potrafią.
>
> 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

No właśnie, chodziło o to, że nie twierdziłem, że się *nie da*
[albo nadal czegoś nie jarzę].

Ale ok, nie da się. :) Z faktu, że procesory są coraz szybsze i kompilatory
coraz lepiej optymalizują (zarówno wykorzystując cechy procesora, jak i
przeprowadzając coraz bardziej zaawansowaną analizę przepływu danych i
sterowania) nie wynika, że stanie się cud.

Trochę się bawiłem w ręczną wektoryzację kodu i widzę, że to jest loteria.
Tzn. pewne problemy w oczywisty sposób się zrównoleglają, inne słabo lub
wcale.

Ostatecznie zawsze ogranicza nas złożoność obliczeniowa. :)

w.

do góry

W dniu sobota, 23 marca 2013 11:26:24 UTC+1 użytkownik Wojciech Muła napisał:

> Ale ok, nie da się. :)
Może się nie da, ale ja tego nie wiem :)


> Z faktu, że procesory są coraz szybsze
Chodziło mi bardziej o fakt, że kolejne wersje procesorów w większym lub
mniejszym stopniu różnią się miedzy sobą, a to z kolei wymusza inne
zasady optymalizowania kodu. Inne zasady optymalizowania pociągają za
sobą konieczność zmian w kompilatorach. Absolutnie bym się nie zdziwił,
gdyby prace nad zmianami w kompilatorach były mocno opóźnione.

Często panuje pogląd że wykonanie softu to najprostszy etap projektu, a
najtrudniejsze
jest wykonanie sprzętu. Praktyka pokazuje, że często bywa odwrotnie.
Choćby taki Itanium.... procesor wydajny, a było (może nadal nie ma) dobrego
optymalizatora. Po skompilowaniu i zmierzeniu czasu przegrywał z
przeciętnym tanim komputerem. Podobnie było z alphami które testowałem.


> i kompilatory
> coraz lepiej optymalizują (zarówno wykorzystując cechy procesora, jak i
> przeprowadzając coraz bardziej zaawansowaną analizę przepływu danych i
> sterowania) nie wynika, że stanie się cud.
Z kolei ja nie twierdzę że stanie się cud. Zastanawiam się tylko, o ile
szybszy kod wygenerowałby kompilator, jakby pracowało nad optymalizatorem ze
stu specjalistów przez kilka lat.

> Trochę się bawiłem w ręczną wektoryzację kodu i widzę, że to jest loteria.
> Tzn. pewne problemy w oczywisty sposób się zrównoleglają, inne słabo lub
> wcale.
Dużo osób wypowiada się w podobny sposób na ten temat, dziś bardzo trudno
jest obliczyć czas wykonania kodu, głównie z powodu różnego czasu dostępu
do pamięci.


> Ostatecznie zawsze ogranicza nas złożoność obliczeniowa. :)
Ale w ramach tego ograniczenia można trochę zdziałać.

Pozdrawiam

do góry

On 22/03/2013 15:54, Marek Borowski wrote:
> On 2013-03-21 23:09, 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?
> 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

a jak sobie wyobrażasz specyfikację języka który mapuje typy 1:1 na
sprzętowe rejestry? I jak ma to pomóc w optymalizacji przeciętnych
programów?


B.

do góry

On 2013-03-23 21:42, Bronek Kozicki wrote:
> On 22/03/2013 15:54, Marek Borowski wrote:
>> On 2013-03-21 23:09, 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?
>> 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
>
> a jak sobie wyobrażasz specyfikację języka który mapuje typy 1:1 na
> sprzętowe rejestry? I jak ma to pomóc w optymalizacji przeciętnych
> programów?
>
char, int, long -> mapuje sie w rejestry uniwersalne
float, double -> mapuje sie w rejestry koprocesora

Swiat idze do przodu, rejestry uniwersalne sie wydluzyly i pojawily sie
rejestry jednostek wektorowych, a w C/C++ juz niekoniecznie.


co za problem dodac uint8_vt, uint16_vt, uint32_vt i operacje na nich ?

uint8_vt = 0x03030303;
uint8_vt = 0x02020202;
uint8_vt = v1*v3; // 0x06060606

z vektorowym float byloby nieco trudniej ale cos mozna wykombinowac.


Co do drugiej czesci:

Wspolczesne CPU i tak za zbyt szybkie dla przecietnych programow, moga
wykorzystywac 1/10 funkcjonalnosci i bedzie dobrze. Pozatym przecietny
program po stronie klienta to niedlugo bedzie pisany wylacznie
javascripcie wiec prymitywne typy danych i tak nie beda mialy znaczenia.

Natomiast co do innych zastosowac to wystarczy spojrzec w kod np. VLC
(precyzujac bibliotek) Jakos tak sie dziwnie sklada ze najbardziej
krytyczne fragmenty np. transformata cosinusowa sa jednak pisnanie z
uzyciem niestandartowych rozszezen czy wrecz asemblerze. Jakby dalo sie
napisac czysty kod ktory kompilator by zoptymalizowal dostatecznie
dobrze na jednostke wektorowa to by chyba tam byl jedyny, nie uwazasz ?


Marek

do góry

W dniu sobota, 23 marca 2013 23:21:58 UTC+1 użytkownik Marek Borowski napisał:
> char, int, long -> mapuje sie w rejestry uniwersalne
> float, double -> mapuje sie w rejestry koprocesora
Mapuje, ale co do jakości tego mapowania nie jestem
przekonany. W programach szachowych wykorzystuje się fakt, że
zarówno plansza ma 64 pola, a typ long long ma 64 bity. Robiąc
operacje logiczne uzyskuje się równoległość. Często i gęsto
widać wstawki asemblerowe do tych operacji. Choć są to
maleńkie wstawki to przyspieszają cały programy o kilka procent.
O jakich wstawkach mowa? Np. o zliczaniu bitów na procesorze
który nie ma tej instrukcji sprzętowo. Wersja asemblerowa
przyspiesza cały program o kilka procent.

Pozdrawiam

do góry

bylo juz o tym na grupie (plc, w styczniu 2012
w watku pt "typy proste i operatory dla sse")

do góry

W dniu niedziela, 24 marca 2013 00:06:09 UTC+1 użytkownik firr kenobi napisał:
> bylo juz o tym na grupie (plc, w styczniu 2012
> w watku pt "typy proste i operatory dla sse")
Zdaje się, że nieraz wracałeś do tego tematu :)
Teraz temat wrócił :)
Pozdrawiam

do góry

W dniu piątek, 22 marca 2013 17:49:48 UTC+1 użytkownik M.M. napisał:
> 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ę.
>

co do kompilatorow to tez moze byc wlasnie
tak ze intel icc optymalizuje lepiej niz gcc
i vcc, np w tym benchmarku

http://benchmarksgame.alioth.debian.org/u32/performa
nce.php?test=mandelbrot

najszybszy okazal sie intelowy fortran i to
prawie dwa razy szybszy niz c w gcc :/ - nie
przypuszczam zeby fortran byl szybszy od c

wiec wychodziloby ze roznica wynika z
optymalizacji kodu w asemblerze (icc vs gcc)

o ile tak jest tp jest troche straszne bo mz
znaczyloby ze icc albo jest w optymalizowaniu dobry albo jaki taki (bo tego tez nie
wiadnomo
czy on jet taki hiperdobry w stosunku do
recznego specjalisty) natomiast gcc i vcc sa byc moze dosyc slabe

jest to pewnego rodzaju hipoteza ale jak kogos to
interesuje to powinien pomierzyc lub conajmniej poczytac jakies w miare aktualne
porownania bo
pewnie sa jakies w necie (i moglby wpisac
wyniki na grupe)

mnie osobiscie jak na dzis bardziej interesuje
poznanie rwguł optymalizacji kodu samemu niz
posiadanie hiperoptymalizujacego kompilatora,
oczywiscie wolalbym raczej by kompilator ktorego
uzywam generowal na zadanie lepszego asma
ale nawet bardziej interesuje mnie reczna
optymalizacja - umiem optymalizowac kody w c
choc chcialbym sie nauczyc robic to lepiej
i troche umiem optymalizowac na poziomie asma
(ale tutaj slabo - tez chcialbym sie nauczyc
optymalizowac lepiej )

do góry

W dniu poniedziałek, 25 marca 2013 08:08:34 UTC+1 użytkownik firr kenobi napisał:
> co do kompilatorow to tez moze byc wlasnie
> tak ze intel icc optymalizuje lepiej niz gcc
> i vcc, np w tym benchmarku
> http://benchmarksgame.alioth.debian.org/u32/performa
nce.php?test=mandelbrot
> najszybszy okazal sie intelowy fortran i to
> prawie dwa razy szybszy niz c w gcc :/
No proszę. Tak podejrzewałem, ale nie wiedziałem.
Teraz widać, różnice dwa razy to coś czego można
się spodziewać.

Pamiętam jak kiedyś dobierałem drobiazgi implementacyjne w
programie szachowym na bardzo wczesnym etapie realizacji.
Chodziło dosłownie o przesuwanie bierek po planszy i o
update kilku pomocniczych statystyk przy okazji przesuwania.
Kompilowałem gcc, wtedy jeszcze na platformę 32bitową. Od
czasu do czasu zauważałem, że po jakiejś drobnej zmianie
kompilator wygenerował kod 2-3 razy szybszy. Dosłownie 50
różnych pomysłów, różnice w wydajności pomiędzy pomysłami
o ułamki procenta, a czasami/nagle różnica o 200-300%. Taki
kod skompilowany potem przy pomocy MSVC++ działał o wiele
wolniej. To było tak, jakbym dobrał konstrukcje językowe,
które kompilator gcc akurat umie zoptymalizować. Więc kilka
przesłanek na to jest, że jakby sztab fachowców przysiadł, to
by napisał kompilator 2-3 razy wydajniejszy.


> - nie przypuszczam zeby fortran byl szybszy od c
Nie zdziwiłbym się, jakby napisanie optymalizatora do
frotrana/ady, było łatwiejsze niż do C/C++.

> wiec wychodziloby ze roznica wynika z
> optymalizacji kodu w asemblerze (icc vs gcc)
No chyba tak, chyba potwierdzają się moje przypuszczenia.

> jest to pewnego rodzaju hipoteza ale jak kogos to
> interesuje to powinien pomierzyc lub conajmniej poczytac
> jakies w miare aktualne porownania bo
> pewnie sa jakies w necie (i moglby wpisac
> wyniki na grupe)
Liczyłem że ktoś bardzo doświadczony w asemblerze coś konkretnego
powie w tym wątku, na razie wszyscy łącznie ze mną bazujemy na
przypuszczeniach.

Przed laty wyszła książka "procesory pentium, narzędzia optymalizacji"
autorstwa Micheal L. Schmit. W którymś z rozdziałów pokazał ręcznie
zoptymalizowaną procedurę w asemblerze, po czym dodał coś w rodzaju
"nie sądzę aby jakikolwiek kompilator zdołał tak zoptymalizować". Myślę,
że to stwierdzenie nadal w jakimś stopniu jest aktualnie, ciekawe tylko w
jakim :)

Odbiegając od tematu...
Ostatnio napisałem w proceduralnym C++ prosty program optymalizacyjny.
Prosty, bo kodu tam raptem 1000 linijek, z czego kod obliczeniowy to
może 400 linii. Kod jest bardzo sprytnie zoptymalizowany, ale patrzę na
niego, patrzę na podejrzane wyniki i się zastanawiam... czy tam na pewno
nie ma błędu? No i właśnie dziś przepisuję w wysokopoziomowym C++,
nafaszerowanym klasami i vectorami... co byłoby gdybym miał ten kod
napisany w asemblerze? Pewnie bym po pierwszej procedurze miał dosyć i
bym wrócić do wysokopoziomowego C++ albo do Javy :)

Pozdrawiam





>
>
>
> mnie osobiscie jak na dzis bardziej interesuje
>
> poznanie rwguł optymalizacji kodu samemu niz
>
> posiadanie hiperoptymalizujacego kompilatora,
>
> oczywiscie wolalbym raczej by kompilator ktorego
>
> uzywam generowal na zadanie lepszego asma
>
> ale nawet bardziej interesuje mnie reczna
>
> optymalizacja - umiem optymalizowac kody w c
>
> choc chcialbym sie nauczyc robic to lepiej
>
> i troche umiem optymalizowac na poziomie asma
>
> (ale tutaj slabo - tez chcialbym sie nauczyc
>
> optymalizowac lepiej )

do góry

M.M. <m...@g...com> wrote:
> W dniu poniedziałek, 25 marca 2013 08:08:34 UTC+1 użytkownik firr kenobi napisał:
>> mnie osobiscie jak na dzis bardziej interesuje
>>
>> poznanie rwguł optymalizacji kodu samemu niz
>>
>> posiadanie hiperoptymalizujacego kompilatora,
>>
>> oczywiscie wolalbym raczej by kompilator ktorego
>>
>> uzywam generowal na zadanie lepszego asma
>>
>> ale nawet bardziej interesuje mnie reczna
>>
>> optymalizacja - umiem optymalizowac kody w c
>>
>> choc chcialbym sie nauczyc robic to lepiej
>>
>> i troche umiem optymalizowac na poziomie asma
>>
>> (ale tutaj slabo - tez chcialbym sie nauczyc
>>
>> optymalizowac lepiej )
... i tak i nie. Pamietaj ludzki umysl jest ograniczony, uwzgldenienie
wielu parametrow na wielu poziomach w wielu procedurach itp. No i podstawowa
kwestia, niktomu nie bedzie chcialo sie bawic programowaniem tej ilosci kodu w asm;-)
Kiedys duzo programowalem w asm na 68xxx, kod dawal sie optymalizowac ale
z kazda wersja kompilatora C bylo coraz trudniej. Pod koniec mojej zabawy, roznice
byly juz prawie minimalne, miedzy tym co ja robilem i kompilator. Z powazaniem
Adam Przybyla

do góry