On Friday, December 22, 2017 at 12:19:36 PM UTC+1, AK wrote:
> Użytkownik "Szyk Cech" <s...@o...pl> napisał:
> >> co do asma to nie widzialem w zyciu jeszcze dobrego programisty ktory by nie
znal asma
> >
> > Z tym się zgodzę. Obecnie po studiach jest masa takich łajz co nie znają
Asemblera ani nawet
> > C++...
>
> Heh. _Po cholere_ dzis komus asm w normalnej praktyce ?
> Wlasnie dobry programosta powinien dzis uciekac od asm-a najdalej jak sie da.
> Uczenie prakktyczne/inzynierskie asm-a na studiach to tez idotyzm zupelny i strata
czasu.
>
> PS: Hm.. Moze nie znam/slabo znam asm-a i stad w/w?

Zgadzam się, że jak najdalej się da. Idzie właśnie o to,
co znaczy to najdalej.


Pozdrawiam

do góry

Użytkownik "M.M." <m...@g...com> napisał:

> Zgadzam się, że jak najdalej się da. Idzie właśnie o to,
> co znaczy to najdalej.

Sedno! ..ale gdy "wszystko inne zawiedzie" czyli nie ma innej opcji/inne opcje okaza
sie po probach
znaczaco gorsze, nalezy ASM-a z lubosci i atencja po prostu uzyc ;)
No bo wlasnie do takich celow onze wciaz jest.

AK

do góry

On Friday, December 22, 2017 at 12:19:36 PM UTC+1, AK wrote:
> Heh. _Po cholere_ dzis komus asm w normalnej praktyce ?

Bo np. kompilatory są za słabe i nie zrobią wymyślnej wektoryzacji.
Albo błąd programie okazuje się błędem w optymalizatorze i bez
znajomości asemblera nie potrafiłbyś tego powiedzieć.

> Wlasnie dobry programosta powinien dzis uciekac od asm-a najdalej jak sie da.

A bardzo dobry powinien wiedzieć, kiedy nie uciekać. :)

> Uczenie prakktyczne/inzynierskie asm-a na studiach to tez idotyzm zupelny i strata
czasu.

Sposób uczenia jest pewnie głupi. Dużo sensowniej uczyć jak działają
procesory, bo niektóre problemy wydajnościowe są wynikiem przeciekania
niskopoziomowych abstrakcji wyżej. W szczególności te związane z dostępem
do pamięci (cache, wyrównanie danych, atomiki, false sharing).
Dobrze też wiedzieć dlaczego i kiedy hyper-threading się nie przyda.

w.

do góry

Użytkownik "Wojciech Muła" <w...@g...com> napisał:
On Friday, December 22, 2017 at 12:19:36 PM UTC+1, AK wrote:

> Heh. _Po cholere_ dzis komus asm w normalnej praktyce ?

> Bo np. kompilatory są za słabe i nie zrobią wymyślnej wektoryzacji.

Nooo powiedzmy.

>Albo błąd programie okazuje się błędem w optymalizatorze i bez
> znajomości asemblera nie potrafiłbyś tego powiedzieć.

Racja. Polecam np. analize jakze "niestandardowej" fukcji strlen() w Turbo C++ 3.0.

>> Wlasnie dobry programosta powinien dzis uciekac od asm-a najdalej jak sie da.
> A bardzo dobry powinien wiedzieć, kiedy nie uciekać. :)

No zgoda w 100%.
Tyle ze bardzo dobrych wystarczy max 10% (a moze i batrdzie prawdopodobne ze 1%)
i zwyczajnie szkoda czasu aby wszytskich czynic bardzo dobrymi w czasach tak duzego
braku "resources".

>> Uczenie prakktyczne/inzynierskie asm-a na studiach to tez idotyzm zupelny i strata
czasu.
>
> Sposób uczenia jest pewnie głupi. Dużo sensowniej uczyć jak działają
> procesory, bo niektóre problemy wydajnościowe są wynikiem przeciekania
> niskopoziomowych abstrakcji wyżej. W szczególności te związane z dostępem
> do pamięci (cache, wyrównanie danych, atomiki, false sharing).
> Dobrze też wiedzieć dlaczego i kiedy hyper-threading się nie przyda.

...i jak zarzadzac (algorytmy) optymalnie pamiecia cache, jak przydzielac
optymalmnie
rejestry procesora (kolorowanie grafu) jak optymalnie "priotrytetowac"
pipeline instrukcji itp itd, ale nie spraw stricte inzynierskich/rzemieslniczych
czyli
zestawu instrukcji itp.

AK

do góry

On Friday, December 22, 2017 at 8:10:31 PM UTC+1, Wojciech Muła wrote:
> On Friday, December 22, 2017 at 12:19:36 PM UTC+1, AK wrote:
> > Heh. _Po cholere_ dzis komus asm w normalnej praktyce ?
>
> Bo np. kompilatory są za słabe i nie zrobią wymyślnej wektoryzacji.
> Albo błąd programie okazuje się błędem w optymalizatorze i bez
> znajomości asemblera nie potrafiłbyś tego powiedzieć.

Kompilator też nie wygeneruje kodu samomodyfikującego - przynajmniej
nie słyszałem o takich możliwościach. Pytanie czy warto tworzyć
kod samomodyfikujący, albo kiedy warto?

>[...]

Pozdrawiam

do góry

Użytkownik "M.M." <m...@g...com> napisał :

On Friday, December 22, 2017 at 8:10:31 PM UTC+1, Wojciech Muła wrote:
>> On Friday, December 22, 2017 at 12:19:36 PM UTC+1, AK wrote:
>> > Heh. _Po cholere_ dzis komus asm w normalnej praktyce ?
>>
>> Bo np. kompilatory są za słabe i nie zrobią wymyślnej wektoryzacji.
>> Albo błąd programie okazuje się błędem w optymalizatorze i bez
>> znajomości asemblera nie potrafiłbyś tego powiedzieć.
>
>Kompilator też nie wygeneruje kodu samomodyfikującego - przynajmniej
>nie słyszałem o takich możliwościach. Pytanie czy warto tworzyć
>kod samomodyfikujący, albo kiedy warto?

Kiedys czasami tak (np grafika-drivery).
Dzis ciezko bo tryb chroniony przeszkadza.
IMHO dzis nie warto.

AK

do góry

W dniu 23.12.2017 o 10:25, M.M. pisze:
> Kompilator też nie wygeneruje kodu samomodyfikującego - przynajmniej
> nie słyszałem o takich możliwościach. Pytanie czy warto tworzyć
> kod samomodyfikujący, albo kiedy warto?

Oczywiście że nie warto kodu samomodyfikującego, taki kod to zgroza.
Czy warto robić w ogóle jakieś wstawki w assemblerze?
Kiedyś jeszcze pisałem częściowo w Pascalu (dziś to martwy język) i
trzeba było przepisać z 32 na 64 bity. Kod strukturalny przechodził bez
problemu, a wstawki całkiem należało zmienić. I te wstawki nic nie miały
z użytego algorytmu ale były mało zrozumiałym pingpongiem przerzucającym
z jednego rejestru do drugiego, jak to assembler.
Wniosek: dobry język programowania powinien zabraniać wstawek
assemblerowych.

do góry

Dnia Fri, 22 Dec 2017 20:54:22 +0100, AK napisał(a):


>>Albo błąd programie okazuje się błędem w optymalizatorze i bez
>> znajomości asemblera nie potrafiłbyś tego powiedzieć.
>
> Racja. Polecam np. analize jakze "niestandardowej" fukcji strlen() w Turbo C++ 3.0.

Jakieś szczegóły? Co oni tam wymyślili?

--
Yakhub

do góry

On Friday, December 22, 2017 at 8:55:10 PM UTC+1, AK wrote:
> > Bo np. kompilatory są za słabe i nie zrobią wymyślnej wektoryzacji.
>
> Nooo powiedzmy.

Nie robią, nie są jeszcze tak dobre jak białkowe maszyny. :)

> >Albo błąd programie okazuje się błędem w optymalizatorze i bez
> > znajomości asemblera nie potrafiłbyś tego powiedzieć.
>
> Racja. Polecam np. analize jakze "niestandardowej" fukcji strlen() w Turbo C++ 3.0.

Wątpię, żebym znalazł tam coś nowego. :)

> ...i jak zarzadzac (algorytmy) optymalnie pamiecia cache, jak przydzielac
optymalmnie
> rejestry procesora (kolorowanie grafu) jak optymalnie "priotrytetowac"
> pipeline instrukcji itp itd, ale nie spraw stricte inzynierskich/rzemieslniczych
czyli
> zestawu instrukcji itp.

Na pewnym etapie nie da się tego rozdzielić. Zresztą, przeciętny
procesor ma raczej przewidywalne instrukcje i są one zwykle proste.
Jedyny przypadek, gdzie musiałem przysiąść, to były instrukcje
łańcuchowe na intelach (STNI). Ale tylko z powodu wybitnie kiepskiej
dokumentacji.

w.

do góry

On Saturday, December 23, 2017 at 10:25:28 AM UTC+1, M.M. wrote:
> Kompilator też nie wygeneruje kodu samomodyfikującego - przynajmniej
> nie słyszałem o takich możliwościach. Pytanie czy warto tworzyć
> kod samomodyfikujący, albo kiedy warto?

Dużo lepiej generować kod natywny, są do tego biblioteki.
Kod samomodyfikujący się to zawsze kłopot, także z debugowaniem.
Trzeba znać adresy, zmodyfikować prawa dostępu do pamięci
(na co może nie pozwoli OS, tak BTW), itd.

w.

do góry