On Friday, July 18, 2014 10:20:32 AM UTC+2, Borneq wrote:
> A wstawki assemblerowe - człowiek robi to co powinien robić komputer,
> zmieni się typ danych i cała wstawka do przerobienia.

Wstawki asemblerowe robi się dla celów wydajnościowych,
kompilatory nie zawsze dają radę. A już kompletnie nie
dają sobie rady w nietrywialnych przypadkach.

w.

do góry

On Fri, 18 Jul 2014 01:34:42 -0700 (PDT), Wojciech Muła
<w...@g...com> wrote:

>On Friday, July 18, 2014 10:20:32 AM UTC+2, Borneq wrote:
>> A wstawki assemblerowe - człowiek robi to co powinien robić komputer,
>> zmieni się typ danych i cała wstawka do przerobienia.
>
>Wstawki asemblerowe robi się dla celów wydajnościowych,
>kompilatory nie zawsze dają radę. A już kompletnie nie
>dają sobie rady w nietrywialnych przypadkach.
>
>w.

Dokladnie odwrotnie. Ciekawe jak sie zrobi wstawki asemblerowe dla
procesora z "pipeliningiem" tak aby nie naruszyc struktury strumienia?

Albo nie naruszyc strategii przydzialu rejestrow?

Kompilatory moga znacznie wiecej niz moze czkowiek. Wstawianie
"wkladek" asemblerowych dobre bylo w czasach 8086. Widac ta mentalnosc
niektorym zostala do dzis.

A.L.

do góry

W dniu 2014-07-18 10:47, A.L. pisze:
> On Fri, 18 Jul 2014 01:34:42 -0700 (PDT), Wojciech Muła
> <w...@g...com> wrote:
>
>> On Friday, July 18, 2014 10:20:32 AM UTC+2, Borneq wrote:
>>> A wstawki assemblerowe - człowiek robi to co powinien robić komputer,
>>> zmieni się typ danych i cała wstawka do przerobienia.
>>
>> Wstawki asemblerowe robi się dla celów wydajnościowych,
>> kompilatory nie zawsze dają radę. A już kompletnie nie
>> dają sobie rady w nietrywialnych przypadkach.
>>
>> w.
>
> Dokladnie odwrotnie. Ciekawe jak sie zrobi wstawki asemblerowe dla
> procesora z "pipeliningiem" tak aby nie naruszyc struktury strumienia?
>
> Albo nie naruszyc strategii przydzialu rejestrow?

Czasami tak, a czasami nie. Znany jest przykład korzystania z Altiveca
przez kompilatory gcc - przez długi czas robiły dużo złego przy
kompilacji - dopiero po długim okresie czasu poprawiono to. Więc jeśli
ktoś chciał wykorzystać moc altiveca w swoim programie często nie mogł
uniknąć wstawek....


> Kompilatory moga znacznie wiecej niz moze czkowiek. Wstawianie
> "wkladek" asemblerowych dobre bylo w czasach 8086. Widac ta mentalnosc
> niektorym zostala do dzis.

W większości przypadków to się zgadza, choć są sytuacje, gdzie trzeba
albo długo czekać, aż kompilator nauczy się poprawnie z czegoś
korzystać, albo ratować się wstawkami.


--
Kaczus
http://kaczus.ppa.pl

do góry

On Friday, July 18, 2014 10:47:11 AM UTC+2, A. L. wrote:
> On Fri, 18 Jul 2014 01:34:42 -0700 (PDT), Wojciech Mu�a
> Dokladnie odwrotnie. Ciekawe jak sie zrobi wstawki asemblerowe dla
> procesora z "pipeliningiem" tak aby nie naruszyc struktury strumienia?

Nie wiem, nigdy na taki nie pisałem.

> Albo nie naruszyc strategii przydzialu rejestrow?

Zobacz, jak się robi wstawki asemblerowe w GCC,
można zostawić kompilatorowi przydział rejestrów.

> Kompilatory moga znacznie wiecej niz moze czkowiek. Wstawianie
> "wkladek" asemblerowych dobre bylo w czasach 8086. Widac ta mentalnosc
> niektorym zostala do dzis.

Mogą znacznie więcej i lepiej, ale pokaż mi kompilator,
który potrafi zrobić to:
http://0x80.pl/articles/sse-popcount.html lub
http://0x80.pl/articles/sse4_substring_locate.html lub
http://0x80.pl/articles/simd-friendly-karp-rabin.htm
l lub
http://0x80.pl/articles/sse-itoa.html

w.

do góry

ztcw wlasciwie nigdy nie daja rady, z drugiej strony ztcw to co mozna ugrac takimi
optymalizacjami to jest czynnik rzedu 2X

(i to moze predzej dla skladanej optymalizacji tj redukowaniu i profilowaniu w c
(ktore tez jest bardzo pracochlonne ) + przepisywanie w asmie, niz dla pojedyńczej
(choc moze jestem tu nieco zbyt pesymistyczny i przydobrej znajomosci asma moglo by
to byc moze nieco wiecej, ale rzad przyspieszenia jaki mozna tu osiagnac to mz jest
'w granicach' 2X)

nie sa to dokladne dane ale chodzi mi z grubsza o rząd,
(nie jest to wiec tyle ile zdarzalo sie osiagac
optymalizujac kod bcc32 gdzie to przyspieszenie
to zdarzalo sie byc np 15X)

do góry

On Fri, 18 Jul 2014 02:35:43 -0700 (PDT), Wojciech Muła
<w...@g...com> wrote:

>On Friday, July 18, 2014 10:47:11 AM UTC+2, A. L. wrote:
>> On Fri, 18 Jul 2014 01:34:42 -0700 (PDT), Wojciech Mu�a
>> Dokladnie odwrotnie. Ciekawe jak sie zrobi wstawki asemblerowe dla
>> procesora z "pipeliningiem" tak aby nie naruszyc struktury strumienia?
>
>Nie wiem, nigdy na taki nie pisałem.
>
>> Albo nie naruszyc strategii przydzialu rejestrow?
>
>Zobacz, jak się robi wstawki asemblerowe w GCC,
>można zostawić kompilatorowi przydział rejestrów.
>
>> Kompilatory moga znacznie wiecej niz moze czkowiek. Wstawianie
>> "wkladek" asemblerowych dobre bylo w czasach 8086. Widac ta mentalnosc
>> niektorym zostala do dzis.
>
>Mogą znacznie więcej i lepiej, ale pokaż mi kompilator,
>który potrafi zrobić to:
>http://0x80.pl/articles/sse-popcount.html lub
>http://0x80.pl/articles/sse4_substring_locate.html lub
>http://0x80.pl/articles/simd-friendly-karp-rabin.ht
ml lub
>http://0x80.pl/articles/sse-itoa.html
>
>w.

No, jakies gowno open source niekoniecznie potrafi

A.L.

do góry

On Friday, July 18, 2014 11:31:19 PM UTC+2, A. L. wrote:
> No, jakies gowno open source niekoniecznie potrafi

A czy kompilator Microsoftu z 2013 jest wystarczająco
niegówniany? Albo intelowski ICC?

w.

do góry

W dniu 2014-07-16 o 09:36, Borneq pisze:
> Do najpopularniejszych języków, zwłaszcza Javy i C#.

i nie tylko,
również porównywanie procesorów.
http://www.cpu-world.com/Compare/288/Intel_Core_i3_i
3-3220_vs_Intel_Pentium_Dual-Core_G2030.html
Mamy różne benchmarki, i3 dla pojedynczego wątku jest szybszy jedynie o
zegar, ale dużo szybszy dla wielu wątków.

do góry

On Friday, July 18, 2014 10:34:42 AM UTC+2, Wojciech Muła wrote:
> Wstawki asemblerowe robi się dla celów wydajnościowych,
> kompilatory nie zawsze dają radę.
> A już kompletnie nie
> dają sobie rady w nietrywialnych przypadkach.
Temat wraca. Nie wiem co to są nietrywialne przypadki.
Moim zdaniem kompilatory rzadko generują optymalny kod,
ale często nie stanowi to problemu. W niektórych wersjach
kompilatorów miałem wrażenie, że mała wstawka w asemblerze
pogarszała wydajność.

Pozdrawiam

do góry

W dniu wtorek, 16 grudnia 2014 23:53:06 UTC+1 użytkownik M.M. napisał:
> On Friday, July 18, 2014 10:34:42 AM UTC+2, Wojciech Muła wrote:
> > Wstawki asemblerowe robi się dla celów wydajnościowych,
> > kompilatory nie zawsze dają radę.
> > A już kompletnie nie
> > dają sobie rady w nietrywialnych przypadkach.
> Temat wraca. Nie wiem co to są nietrywialne przypadki.
> Moim zdaniem kompilatory rzadko generują optymalny kod,
> ale często nie stanowi to problemu. W niektórych wersjach
> kompilatorów miałem wrażenie, że mała wstawka w asemblerze
> pogarszała wydajność.
>
ostatnio mialem drastyczny przyklad na to ze to co powtarzaja niektorzy ze kompilator
zoptymalizuje sam albo ze generuje dobry kod to sa kompletne bajki
9byc moze generuje dobry kod ale z dobrego ciezko zoptymalizowanego zrodla)

konkretny przypadek z tym kodem gdzie chailem wyswietlic teksturowaną kopułe
w trojwymiarowym prototypie (co obejmuje wyznaczenie wektora kierunku w 3d dla
kazdegio piksela ekranu i zrobieni look up w teksturze na podstawie kierunku)

inicjalna wersja trwala jakies 100 czy nawet 150 ms ms a to glownie dziki temu ze
czas zarly dwa sinusy i pierwiastek na piksel jeszcze z jakims dzieleniem i
rzutowaniami (jak uzyjesz sinusa w kodzie to program jest wydajnosciowym trupem tak
bardzo sinus jest wolny) po stablicowaniu sinusów i normalizacji i jeszcze ze dwu
dniach glowienia sie nad petla czas spadl do 20 i w koncu do 13 milisekund 9prawie 10
razy szybciej niz normalny kod dla gcc) ciegle uwazalem ze to za duzo i zaczalem
przepisywac kod na kafelki gdzie mogelem zrobic na kafelkach pewna interpolacje i
pewne tam drobne rozroznienia, to bylo troche trudne ale spowodowalo ze cza sspadl do
6-10 ms, 910-20 razy sszybciej "niz gcc", jeszcze kombinowalem z rugowaniem castow i
rozwijaniem petli na kafelku i co sie okazalo - zanotowalem zjazd do wlaciwie 2-5 ms
(te 5 ms moglbym jeszcze obnizyc ale to znowu wiaze sie z kolejnymi przepisakami
ktore mi sie nie chcialo robic - wlasciwie to normalny czas tego co mocniej
przyoptymalizowalem spadł do 2 ms (co juz jest mega imponujacym wynikiem) - 50 razy
szybciej wzgledem podejscia ze nie ma co optymalizowac bo nic nie pomoze ;-0

do góry