nie znam sie na tym temacie i ew ciezko mi sie
doszukac,

chodzi mi o dowiedzenie sie czy taki sposob zapisku
linijek z kodu

jak przepisanie np

ren=re*re-im*im+cRe; imn=2*re*im+cIm;

re =ren; im =imn;

na

ren=re*re-im*im+cRe, imn=2*re*im+cIm;

re =ren, im =imn;

gdzie przecinek w odroznieniu do srednika informuje ze
dwa (lub wiecej) polaczone nim statementy mozna wykonywac
rownolegle (na odzielnyc potokach)

jaki jest obecnie najnowszy procek intela? sandy bridge?
(ten ktorego pamietam bo jako pierwszy ma avx )
Czy taki sposob zapisu (tylko ogolniej nawet dla wielu
wiecej linijek bo np przypisywanie 20 pol struktury
mozna zrownoleglic na 20 elementow itp) pozwala
kompilatorowi i prockowi pomoc produkowac i przetwarzac
znacznie lepszy 'superskalarny' 'wielopotokowy' kod
maszynowy?

(kenobi)








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

do góry

w wiki nie umiem sie doszukac tego info
(ciekawe skad inad ze o ile sndy bridge wydaje sie
obecnym jest duzo info o przyszlorocznym ivy bridge
to jest ponadto juz tez duzo info o nastepcy ivy
bridge, haswellu a nawet jakies wzmianki o nastepcy
haswella, skylake (czyli trzy generacje do przodu)



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

do góry

<f...@W...gazeta.pl> napisał(a):
> Czy taki sposob zapisu [] pozwala
> kompilatorowi i prockowi pomoc produkowac i przetwarzac
> znacznie lepszy 'superskalarny' 'wielopotokowy' kod
> maszynowy?
Temat stary jak swiat. Czesto podczas programowania, gdy chce
sie uzyskac super wydajna implementacje, programista zdaje
sobie sprawe ze ciag instrukcji w jezyku wysokopoziomowym
bedzie zbyt trudny dla kompilatora aby wygenerowal z tego
optymalny kod maszynowy. Co wiecej, kompilator bez informacji o
statystycznym rozkladzie danych, nie moze wygenerowac optymalnego
kodu - dla kazego rozkladu inny kod bedzie optymalny. Kwestia jest
chyba nadal otwarta: czy np. wprowadzic jakas pragme, typu

#pragma a = {0..0=>60%,1..3=>20%,3..inf=>20%}
instrukcje( a );

Kompilator wiedzac ze a nigdy nie przyjmuje wartosci ujemnych i
jest az 60% szans na to ze a jest rowne zero, moze wygenerowac
lepszy kod.

Pozdrawiam




>
> (kenobi)
>
>
>
>
>
>
>
>


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

do góry

W dniu 2011-12-31 06:50, M.M. pisze:
> #pragma a = {0..0=>60%,1..3=>20%,3..inf=>20%}
> instrukcje( a );
>
> Kompilator wiedzac ze a nigdy nie przyjmuje wartosci ujemnych i
> jest az 60% szans na to ze a jest rowne zero, moze wygenerowac
> lepszy kod.

W jakim celu? Chodzi ci o optymalizację skoków i pętli? Tylko, że to
jest rozwiązywane na poziomie sprzętowym (branch prediction).
Optymalizacja wykorzystania potoków polega na odpowiednim korzystaniu z
rejestrów i unikaniu nieszczęśliwych sekwencji instrukcji (chociaż i tym
zajmie się sprzęt - out-of-order execution). Jak dla mnie to jest
zadanie w sam raz dla komplilatora, zwykle nie trzeba mu niczego
podpowiadać.
PS: Może o czymś nie wiem, to mnie popraw, ale Intel od czasu do czasu
organizował szkolenia na ten temat, nie pamiętam niczego na temat jakiś
dziwnych pragm.

artur

do góry

Artur Muszyński <a...@u...wytnijto.com.pl> napisał(a):

> W dniu 2011-12-31 06:50, M.M. pisze:
> > #pragma a = {0..0=>60%,1..3=>20%,3..inf=>20%}
> > instrukcje( a );
> >
> > Kompilator wiedzac ze a nigdy nie przyjmuje wartosci ujemnych i
> > jest az 60% szans na to ze a jest rowne zero, moze wygenerowac
> > lepszy kod.
>
> W jakim celu? Chodzi ci o optymalizację skoków i pętli? Tylko, że to
> jest rozwiązywane na poziomie sprzętowym (branch prediction).
Zawsze algorytm ogolny dziala wolniej niz algorytm dostosowany do
specyficznych danych. Widac to najlepiej gdy uzywa sie PGO - gdy
kompilator ma jakies info o statystycznym rozkladzie danych to z
reguly moze wygenerowac kod o 5-10% szybszy, z rzadka zdarza sie
wieksze przyspieszenie, rzedu 20-30%. Niestety PGO nie moze
usunac calkowicie kodu odpowiedzialnego za obsluge przypadkow ktore
nigdy sie nie zdarza, np. ze zmienna typu int nie przyjmie nigdy
innej wartosci niz {1,2,4}. W takiej "dziwnej pragmie" programisci
by mogil podpowiadac kompilatorom.
Pozdrawiam


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

do góry

W dniu 2011-12-31 17:33, M.M. pisze:
>> W jakim celu? Chodzi ci o optymalizację skoków i pętli? Tylko, że to
>> jest rozwiązywane na poziomie sprzętowym (branch prediction).
> Zawsze algorytm ogolny dziala wolniej niz algorytm dostosowany do
> specyficznych danych. Widac to najlepiej gdy uzywa sie PGO - gdy
> kompilator ma jakies info o statystycznym rozkladzie danych to z
> reguly moze wygenerowac kod o 5-10% szybszy, z rzadka zdarza sie
> wieksze przyspieszenie, rzedu 20-30%. Niestety PGO nie moze
> usunac calkowicie kodu odpowiedzialnego za obsluge przypadkow ktore
> nigdy sie nie zdarza, np. ze zmienna typu int nie przyjmie nigdy
> innej wartosci niz {1,2,4}. W takiej "dziwnej pragmie" programisci
> by mogil podpowiadac kompilatorom.
> Pozdrawiam

Musiałem doczytać, co to ten PGO - dawno opuściłem C :-)
Nadal nie łapię, co ma dać konkretnie wskazanie zakresu wartości. Nie
prościej założyć, że szybciej wykona się to, co po if a nie else i
pierwszy case ze switcha?
Na marginesie, środowiska oparte o JIT mogłyby optymalizacje tego typu
robić dynamicznie, bez zawracania głowy programiście.

artur

do góry

> prościej założyć, że szybciej wykona się to, co po if a nie else i
> pierwszy case ze switcha?

A switch działa jak szereg if-ów?

--
Mateusz Bogusz

do góry

Karol Y <k...@o...pl> napisał(a):

> > prościej założyć, że szybciej wykona się to, co po if a nie else i
> > pierwszy case ze switcha?
Jakos mi wywialo z glowy wszystkie przyklady. Na pewno wielokrotnie
gdy zalezalo mi na wydajnej implementacji w C/C++ to bylem swiadomy
ze kompilator czegos nie wie, a jakby byla taka dziwna pragma to
bym mogl mu podpowiedziec.

> A switch działa jak szereg if-ów?
W ksiazce kasperskiego pisalo ze kompilatory z duzego switcha potrafia
zrobic nawet drzewo wyszukiwan binarnych, ale nie wiem, rzadko zagladalem
do kodu asemblerowego. Gdy mierzylem czasy wykonania, to nie znalazlem
prawidlowosci co jest szybsze, czy if czy swich case (w c++). Wyniki
mocno zmienialy sie wraz ze zmiana wersji kompilatora i procesora.
Kazdy przypadek trzeba zmierzyc osobno - niestety.

Pozdrawiam




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

do góry

On 12/31/2011 6:50 AM, M.M. wrote:
> Temat stary jak swiat. Czesto podczas programowania, gdy chce
> sie uzyskac super wydajna implementacje, programista zdaje
> sobie sprawe ze ciag instrukcji w jezyku wysokopoziomowym
> bedzie zbyt trudny dla kompilatora aby wygenerowal z tego
> optymalny kod maszynowy. Co wiecej, kompilator bez informacji o
> statystycznym rozkladzie danych, nie moze wygenerowac optymalnego
> kodu - dla kazego rozkladu inny kod bedzie optymalny. Kwestia jest
> chyba nadal otwarta: czy np. wprowadzic jakas pragme, typu
>
> #pragma a = {0..0=>60%,1..3=>20%,3..inf=>20%}
> instrukcje( a );
>
> Kompilator wiedzac ze a nigdy nie przyjmuje wartosci ujemnych i
> jest az 60% szans na to ze a jest rowne zero, moze wygenerowac
> lepszy kod.

W GCC jest cos w tym stylu, __builtin_expect
http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.htm
l

Dosc czesto uzywane w kernelu Linuxa, takze przydatne sa (oparte na
powyzszym) makra "likely" i "unlikely":
#define likely(x) __builtin_expect(!!(x), 1)
#define unlikely(x) __builtin_expect((x), 0)
http://kerneltrap.org/node/4705
http://www.ginac.de/pipermail/ginac-devel/2001-Septe
mber/000329.html

Patrz tez:
http://stackoverflow.com/questions/3702903/portable-
branch-prediction-hints
http://stackoverflow.com/questions/1851299/is-it-pos
sible-to-tell-the-branch-predictor-how-likely-it-is-
to-follow-the-branc

Pozdrawiam,

Matt

do góry

M.M. <m...@N...gazeta.pl> napisał(a):
> Co wiecej, kompilator bez informacji o
> statystycznym rozkladzie danych, nie moze wygenerowac optymalnego
> kodu - dla kazego rozkladu inny kod bedzie optymalny. Kwestia jest
> chyba nadal otwarta: czy np. wprowadzic jakas pragme, typu
> #pragma a = {0..0=>60%,1..3=>20%,3..inf=>20%}
> instrukcje( a );
> Kompilator wiedzac ze a nigdy nie przyjmuje wartosci ujemnych i
> jest az 60% szans na to ze a jest rowne zero, moze wygenerowac
> lepszy kod.

Dlatego np. VS posiada coś takiego jak Profile-Guided Optimizations, czyli
optymalizację na podstawie wyników testowych uruchomień pliku wykonywalnego.
http://msdn.microsoft.com/en-us/library/e7k32f4k(v=v
s.80).aspx

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 22 days, 3 hours, 39 minutes and 59 seconds

do góry