🚀 go-pugleaf

On 2016-10-04 20:06, Borneq wrote:
> Potrzebuję dokładniejszego, który profilował by na poziomie pojedynczej
> instrukcji

http://developer.amd.com/tools-and-sdks/archive/compute/amd-codeanalyst-performance-analyzer/

Nie działa lub działa bardzo źle z procesorami Intela. Czy coś się 
poprawiło ostatnio - nie wiem, nie używam dłuższą chwilę.

W dniu 04.10.2016 o 20:31, Sebastian Biały pisze:
> Nie działa lub działa bardzo źle z procesorami Intela. Czy coś się
> poprawiło ostatnio - nie wiem, nie używam dłuższą chwilę.

Mam procesor Intela i3; na początku trochę problemów bo instalacja 
została na pasku na dole, ale zabiłem przez wylogowanie.
Jest niesamowity, nie tylko każda linia kodu ale każda instrukcja!
i nawet specjalnie nie zwolnił na testowym programie.
Testuję dla VC++, nie wiem czy działa na GCC pod Windows (MinGW)

W dniu 04.10.2016 o 23:22, Borneq pisze:
> i nawet specjalnie nie zwolnił na testowym programie.

A może jednak zwolnił, tylko wcześniej zabiłem

W dniu 04.10.2016 o 23:25, Borneq pisze:
> W dniu 04.10.2016 o 23:22, Borneq pisze:
>> i nawet specjalnie nie zwolnił na testowym programie.
>
> A może jednak zwolnił, tylko wcześniej zabiłem

To co się okazało: w działaniach na bitach, gdzie adres wyliczam przez 
bit/8, VC++ nawet w release nie potrafi zamienić /8 na >>3, ale może 
dlatego że przy optymalizacjach musi być dokładnie ten sam wynik a 
liczba bitów była tu całkowita a nie naturalna więc wywołuje procedurę. 
Zmiana ta przyśpieszyła znacznie działanie testowego programu sita 
Erastotenesa na bitach.
Trzeba pamiętać że kompilatory często nie optymalizują dzielenia przez 
stała 2^n

W dniu 04.10.2016 o 23:25, Borneq pisze:
> W dniu 04.10.2016 o 23:22, Borneq pisze:
>> i nawet specjalnie nie zwolnił na testowym programie.
>
> A może jednak zwolnił, tylko wcześniej zabiłem

CodeXL ma inny sposób profilowania - błyskawicznie działa, nie trzeba 
długo czekać na zakończenie procesu

On Wed, 5 Oct 2016 02:19:23 +0200, Borneq <borneq@antyspam.hidden.pl> 
wrote:
> To co się okazało: w działaniach na bitach, gdzie adres wyliczam 
przez 
> bit/8, VC++ nawet w release nie potrafi zamienić /8 na >>3, ale może

Bo najnowsze procesory mogą szybko dzielić. Zobacz ile taktów co robi 
np. nowy I7.

On 2016-10-04 23:22, Borneq wrote:
>> Nie działa lub działa bardzo źle z procesorami Intela. Czy coś się
>> poprawiło ostatnio - nie wiem, nie używam dłuższą chwilę.
> Mam procesor Intela i3; na początku trochę problemów bo instalacja
> została na pasku na dole, ale zabiłem przez wylogowanie.
> Jest niesamowity, nie tylko każda linia kodu ale każda instrukcja!

W tym problem. Procesory AMD mają bardzo dokładnie okreslony profil 
instrukcji we współdziałaniu z cache. Ten profiler pokazuje (pokazywał?) 
głupoty na Intelach. Należy więc podchodzić z rezerwą.

> i nawet specjalnie nie zwolnił na testowym programie.

Bo to profiler ktory nie instrumentuje tylko przerywa. To jest zaleta 
(mierzy razem z wywołaniami obcych biblitek) ale i wada (uszkadza cache 
procesora i program zachowuje się inaczej jesli chodzi o prędkosc na 
poziomie instrukcji).

On Wednesday, October 5, 2016 at 7:06:18 PM UTC+2, Sebastian Biały wrote:
> On 2016-10-04 23:22, Borneq wrote:
> >> Nie działa lub działa bardzo źle z procesorami Intela. Czy coś się
> >> poprawiło ostatnio - nie wiem, nie używam dłuższą chwilę.
> > Mam procesor Intela i3; na początku trochę problemów bo instalacja
> > została na pasku na dole, ale zabiłem przez wylogowanie.
> > Jest niesamowity, nie tylko każda linia kodu ale każda instrukcja!
> 
> W tym problem. Procesory AMD mają bardzo dokładnie okreslony profil 
> instrukcji we współdziałaniu z cache. Ten profiler pokazuje (pokazywał?) 
> głupoty na Intelach. Należy więc podchodzić z rezerwą.
> 
> > i nawet specjalnie nie zwolnił na testowym programie.
> 
> Bo to profiler ktory nie instrumentuje tylko przerywa. To jest zaleta 
> (mierzy razem z wywołaniami obcych biblitek) ale i wada (uszkadza cache 
> procesora i program zachowuje się inaczej jesli chodzi o prędkosc na 
> poziomie instrukcji).

By musiał w pełni symulować daną konfigurację sprzętową, aby nie uszkadzać.

Pozdrawiam

W dniu 05.10.2016 o 19:06, Sebastian Biały pisze:
> Bo to profiler ktory nie instrumentuje tylko przerywa. To jest zaleta
> (mierzy razem z wywołaniami obcych biblitek) ale i wada (uszkadza cache
> procesora i program zachowuje się inaczej jesli chodzi o prędkosc na
> poziomie instrukcji).

W każdym razie nie udał się mój sposób profilowania: rdtsc pomiędzy 
każdą instrukcją maszynową, wraz ze wzrostem ilości pętli zmienia się 
odczyt na coraz mniejsze ilości i wychodzi że pomiędzy instrukcjami jest 
tak samo mało. Ten sposób może by zadziałał na 386 ale tutaj mamy potok 
instrukcji.

On Wednesday, October 5, 2016 at 9:19:32 AM UTC+2, slawek wrote:
> On Wed, 5 Oct 2016 02:19:23 +0200, Borneq <borneq@antyspam.hidden.pl> 
> wrote:
> > To co się okazało: w działaniach na bitach, gdzie adres wyliczam 
> przez 
> > bit/8, VC++ nawet w release nie potrafi zamienić /8 na >>3, ale może
> 
> Bo najnowsze procesory mogą szybko dzielić. Zobacz ile taktów co robi 
> np. nowy I7.

Dzielenie to kilkanaście-kilkadziesiąt cykli opóźnienia
versus 1 cykl dla przesunięcia bitowego. Więc to nie
jest "szybko", lecz "dramatycznie wolno, unikaj jeśli
możesz".

w.

On 2016-10-06 00:57, M.M. wrote:
>> Bo to profiler ktory nie instrumentuje tylko przerywa. To jest zaleta
>> (mierzy razem z wywołaniami obcych biblitek) ale i wada (uszkadza cache
>> procesora i program zachowuje się inaczej jesli chodzi o prędkosc na
>> poziomie instrukcji).
> By musiał w pełni symulować daną konfigurację sprzętową, aby nie uszkadzać.

Z grubsza to nie jest możliwe. Wywołania biblitek systemowych i kernela 
nie da się instrumentować ani "naprawiać" cache po przerwaniu. Rozlatują 
się subtelne zależnosci miedzywątkowe itd.

On Thursday, October 6, 2016 at 7:17:38 PM UTC+2, Sebastian Biały wrote:
> On 2016-10-06 00:57, M.M. wrote:
> >> Bo to profiler ktory nie instrumentuje tylko przerywa. To jest zaleta
> >> (mierzy razem z wywołaniami obcych biblitek) ale i wada (uszkadza cache
> >> procesora i program zachowuje się inaczej jesli chodzi o prędkosc na
> >> poziomie instrukcji).
> > By musiał w pełni symulować daną konfigurację sprzętową, aby nie uszkadzać.
> 
> Z grubsza to nie jest możliwe. Wywołania biblitek systemowych i kernela 
> nie da się instrumentować ani "naprawiać" cache po przerwaniu. Rozlatują 
> się subtelne zależnosci miedzywątkowe itd.

Zgadzam się, to są utrudnienia praktycznie nie do przezwyciężenia. Niemniej jeśli optymalizujemy własny kod, to symulator powinien dać lepsze wyniki niż
profiler który ciągle oddziałuje na cache.

Pozdrawiam