slawek <s...@h...pl> napisał(a):

>
> Użytkownik " M.M." <m...@W...gazeta.pl> napisał w wiadomości grup
> dyskusyjnych:jlqhf7$9i8$...@i...gazeta.pl...
> > Jeśli to ma być szybko, to bez ifów i z wykorzystaniem specyficznych cech
> ....
> > zmieniać. W przypadku gdy a > b to musimy zamienić 32 bity młodsze ze
> > starszymi.
> >
> > Mniej/więcej coś takiego:
> > uint64 swp_corners( uint64 input ) {
> > const uint32 tmp = ( ( input & x_corner_1 ) >> offset_x1 ) < ( ( input &
> ....
>
> Dziecko drogie, a jaka jest różnica pomiędzy jawnie napisanym
> if(a > b) - a > operacją porównywania a > b ?
Pokażesz w moim poście gdzie napisałem że jest taka różnica? Zdaje
się że też pisałem coś o uniknięciu operatora porównywania.


> Na poziomie kodu maszynowego - żadna. Musi być jakieś cmp, musi być potem
> skutek tego cmp. Nie ma się co szamotać, że "uda się bez if" - bo te if
> będzie dalej, tyle że zagrzebane w nieczytelnym kodzie.
Chrzanienie, wiele razy taki zabieg się udaje.


> Kolejna sprawa - pakowanie bitów do czegoś. Ok. Może mieć sens. Ale jeżeli
> pakujesz 4 int16 do int64 ... to po prostu robisz niepotrzebną rzecz -
> szybciej i łatwiej będzie to np. działało na strukturze czy nawet
> oddzielnych zmiennych. Znowu liczy się kod maszynowy - a nie twoje dobre
> chęci.
A Twoje chęci się liczą tak i Twoja analiza dwuliniowej procedury w
oderwaniu od pozostałej części programu ma sens?

Pozdrawiam


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 08.04.2012 15:04, slawek wrote:
>
>
> Dziecko drogie, a jaka jest różnica pomiędzy jawnie napisanym if(a > b)
> - a operacją porównywania a > b ?
A ty nie wiesz?

>
> Na poziomie kodu maszynowego - żadna. Musi być jakieś cmp, musi być
> potem skutek tego cmp. Nie ma się co szamotać, że "uda się bez if" - bo
> te if będzie dalej, tyle że zagrzebane w nieczytelnym kodzie.
W tym przypadku akurat to nie ma sensu, ale stosuje się konstrukcje,
gdzie używa się wynik porównania w obliczeniach zamiast if po to aby:
- nie psuć pipeline
- nie wykonywać niepotrzebnych skoków
- nie powiększać kodu

A w przypadku shaderów było to na początku niezbędne (brak instrukcji
skoku).


--
Pozdrawiam
Michoo

do góry

Użytkownik " M.M." <m...@W...gazeta.pl> napisał w wiadomości grup
dyskusyjnych:jlsfgo$6fo$...@i...gazeta.pl...
> się że też pisałem coś o uniknięciu operatora porównywania.

Jakieś przykre doświadczenia?

> Chrzanienie, wiele razy taki zabieg się udaje.

Jaki, komu? Obejrzyj co wyprodukuje kompilator...

> A Twoje chęci się liczą tak i Twoja analiza dwuliniowej procedury w
> oderwaniu od pozostałej części programu ma sens?

Nie jest dwuliniowa (bilinear) - ale dwulinijkowa. Nie żartuję, tu masz
definicję:

http://en.wikipedia.org/wiki/Bilinear_form

do góry

Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości grup
dyskusyjnych:jlsg2a$jig$...@m...internetia.pl...
> A ty nie wiesz?

Nie wiem?

> W tym przypadku akurat to nie ma sensu, ale stosuje się konstrukcje, gdzie
> używa się wynik porównania w obliczeniach zamiast if po to aby:

Goedelizacja. Czasem z lekką nutą logiki rozmytej. Komputery kwantowe.

do góry

On 08.04.2012 19:10, slawek wrote:
>
> Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości grup
> dyskusyjnych:jlsg2a$jig$...@m...internetia.pl...
>> A ty nie wiesz?
>
> Nie wiem?
Już wiesz, bo napisałem dlaczego w klasycznych programach się to rozróżnia.
>
>> W tym przypadku akurat to nie ma sensu, ale stosuje się konstrukcje,
>> gdzie używa się wynik porównania w obliczeniach zamiast if po to aby:
>
> Goedelizacja.
Nie znam się.

> Czasem z lekką nutą logiki rozmytej.
Wartości rozmyte to jest kompletnie inna kwestia. Tu mówimy o czymś co w
uproszczeniu można przedstawić jako zastąpienie
if(P)
wynik=wynik+k;
na
wynik+=(P)*k;

> Komputery kwantowe.
A widziałeś może funkcjonalny komputer kwantowy? Bo teoria piękna ale
implementacje (nie licząc pewnego oszustwa) mają po kilka kubitów.

--
Pozdrawiam
Michoo

do góry

slawek <s...@h...pl> napisał(a):

>
> Użytkownik " M.M." <m...@W...gazeta.pl> napisał w wiadomości grup
> dyskusyjnych:jlsfgo$6fo$...@i...gazeta.pl...
> > się że też pisałem coś o uniknięciu operatora porównywania.
>
> Jakieś przykre doświadczenia?
> > Chrzanienie, wiele razy taki zabieg się udaje.
> Jaki, komu? Obejrzyj co wyprodukuje kompilator...
Kiedyś gdy oglądałem to generował skoki warunkowe. Coś się zmieniło?
Pozdrawiam


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Dnia Sun, 08 Apr 2012 18:56:26 +0200, Michoo napisal:

> On 08.04.2012 15:04, slawek wrote:
>>
>>
>> Dziecko drogie, a jaka jest różnica pomiędzy jawnie napisanym if(a > b)
>> - a operacją porównywania a > b ?
> A ty nie wiesz?

Oj, dzieci, dzieci ;)

>
>>
>> Na poziomie kodu maszynowego - żadna. Musi być jakieś cmp, musi być
>> potem skutek tego cmp. Nie ma się co szamotać, że "uda się bez if" - bo
>> te if będzie dalej, tyle że zagrzebane w nieczytelnym kodzie.
> W tym przypadku akurat to nie ma sensu, ale stosuje się konstrukcje,
> gdzie używa się wynik porównania w obliczeniach zamiast if po to aby:
> - nie psuć pipeline

Yhy.

> - nie wykonywać niepotrzebnych skoków
> - nie powiększać kodu

Zacznij od przeczytania, co to jest SSA. Obie formy tego, co programista
napisze kompilują się prędzej czy później do właśnie SSA, zanim
staną się kodem maszynowym. Kompilator generując kod dba o to, co
napisałeś, ale jeżeli rzeczy typu rozmieszczenie danych w pamięci
nie przeszkadzają, forma zapisu programisty ma niewiele wspólnego
z tym, do czego to się parsuje, nie mówiąc o kodzie maszynowym.

>
> A w przypadku shaderów było to na początku niezbędne (brak instrukcji
> skoku).

Widać na tym polu kompilatory były bardzo prymitywne, albo język
był prymitywny. Zresztą, GPU ma inną architekturę i skok może
powodować "divergent warps", jeżeli efektem nie są predykaty.

Edek

do góry

Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości grup
dyskusyjnych:jlsisb$tvi$...@m...internetia.pl...
> Wartości rozmyte to jest kompletnie inna kwestia. Tu mówimy o czymś co w
> uproszczeniu można przedstawić jako zastąpienie
> if(P)
> wynik=wynik+k;
> na
> wynik+=(P)*k;

Ale dlaczego? Mamy po prostu P ułamkowe, tj. ani true, ani false - tylko np.
30% true i 70% false. Od tego miejsca robimy fork - czyli nie mamy wyboru
jako takiego, lecz rozwidlenie. Takie coś nie wymaga przerwania potoków
itd. - choć oczywiście zapotrzebowanie na moc obliczeniową wzrośnie 2x - bo
mamy dwa potoki - jeden dla true, drugi dla false. I nie musisz mi
tłumaczyć, że w każdym normalnym programie wzrost ten jest wykładniczy (np.
if wewnątrz pętli).

W konkretnym problemie "4ry" jest tylko 24 różnych możliwości, ciekawe
byłoby jak wyglądałby algorytm liczący wszystkie 24 równolegle - tak aby
było szybko - przy współczesnych procesorach itd. to zaczyna być osiągalne.

do góry

On 08.04.2012 20:31, Edek Pienkowski wrote:
> Dnia Sun, 08 Apr 2012 18:56:26 +0200, Michoo napisal:
>
>> On 08.04.2012 15:04, slawek wrote:
>>>
>>>
>>> Dziecko drogie, a jaka jest różnica pomiędzy jawnie napisanym if(a> b)
>>> - a operacją porównywania a> b ?
>> A ty nie wiesz?
>
> Oj, dzieci, dzieci ;)
Oj, lubię "dyskutować" ze slawkiem.
>
>>
>>>
>>> Na poziomie kodu maszynowego - żadna. Musi być jakieś cmp, musi być
>>> potem skutek tego cmp. Nie ma się co szamotać, że "uda się bez if" - bo
>>> te if będzie dalej, tyle że zagrzebane w nieczytelnym kodzie.
>> W tym przypadku akurat to nie ma sensu, ale stosuje się konstrukcje,
>> gdzie używa się wynik porównania w obliczeniach zamiast if po to aby:
>> - nie psuć pipeline
>
> Yhy.
>
>> - nie wykonywać niepotrzebnych skoków
>> - nie powiększać kodu
>
> Zacznij od przeczytania, co to jest SSA. Obie formy tego, co programista
> napisze kompilują się prędzej czy później do właśnie SSA, zanim
> staną się kodem maszynowym.
Pisałem, że w tym przypadku to nie ma sensu. Natomiast "w przypadku
ogólnym" zdarzało mi się spotkać takie optymalizacje.


> Kompilator generując kod dba o to, co
> napisałeś, ale jeżeli rzeczy typu rozmieszczenie danych w pamięci
> nie przeszkadzają, forma zapisu programisty ma niewiele wspólnego
> z tym, do czego to się parsuje, nie mówiąc o kodzie maszynowym.
Zgadza się. Tylko jak musisz rzeźbić optymalizacje na takim poziomie, to
zazwyczaj rzeźbisz w asm (np jakieś DSP).

>
>>
>> A w przypadku shaderów było to na początku niezbędne (brak instrukcji
>> skoku).
>
> Widać na tym polu kompilatory były bardzo prymitywne,
Tak z 10 lat temu to nie było jako takich kompilatorów a raczej
assemblery. Dopiero potem się pojawiło C for graphics, i inne języki
wysokopoziomowe (HLSL, GLSL).

> albo język
> był prymitywny. Zresztą, GPU ma inną architekturę i skok może
> powodować "divergent warps", jeżeli efektem nie są predykaty.
Sprzęt nie obsługiwał czegoś takiego jak skok. Oidp najpierw potem
pojawiła się możliwość warunkowego wykonania instrukcji, możliwość
przedwczesnego powrotu z programu, a na końcu dopiero "branching".

--
Pozdrawiam
Michoo

do góry