On Sunday, August 20, 2017 at 1:01:20 PM UTC+2, fir wrote:
> dlatego ze ktos kto tak dyskutuje kompletnie nie rozumie problemu

Niekoniecznie oznacza to, że ktoś kompletnie nie rozumie problemu.
Może to oznaczać, że ktoś w pośpiechu, sformułował ciekawy problem
właśnie przy pomocy takich słów.

Zawsze szukamy jakiś idealnych odnośników. Programista ręcznie
implementujący dany algorytm w języku assemblera jest odnośnikiem
do najlepszej implementacji, bo dobry programista jak ma bardzo
dużo czasu, to wykona najlepszą implementację. Potem do tej
najlepszej porównujemy możliwości obecnych kompilatorów.

Dla mnie to oznacza kolokwialne sformułowanie problemu, a nie
totalne niezrozumienie.

> [...]
> wiecej chyba nie che mi sie o tym gadac bo albo to rozumiesz albo
> nie (a ja powtarzajac w kolko to samo tylko tracilbym swoj czas
> czego wolalbym uniknac)
Generalnie zrozumiałem od początku. Problem jak zwykle siedzi w
szczegółach. Zobacz jak nieprecyzyjne jest określenie "przyspieszenie
CPU 100 razy". Co to jest CPU? Przyspieszamy tylko arytmetykę, czy
także odczyty z rejestrów (rejestry to zdecydowanie część CPU, ale
pamięć też), czy może także przyspieszamy cache L1, bo to chyba też
integralna część CPU? Przyspieszony 100 razy CPU wraz z rejestrami i
pamięcią cache, wykona dużo programów 30 razy szybciej.

Pytanie, wnosi do naszej rozmowy przytoczenie 100 razy szybszego
CPU, jeśli może być przyspieszony na N sposobów? Myślę że nic, tylko
komplikuje sprawę. Dlatego w porównaniach często powołujemy się na
teoretycznego programistę który napisał kod idealny - niestety z
tym też jest problem, bo zazwyczaj nie mam kodu idealnego pod
ręką. Hmmm my nie mamy, ale twórcy kompilatorów mogą mieć i to
wiele prawie doskonałych kodów.

Powiem w ten sposób. Gdy bez zastanowienia pisałem fragment kodu w
asemblerze na nowsze procesory w czasach gdy kompilatory już
powszechnie uchodziły za dopracowane, to mój kod działał np. o 20%-50%
wolniej niż skompilowany z opcją -O1. Gdy był kompilowany z
opcją -O3, w dodatku z informacjami z profilera, to mój był wolniejsz
jeszcze może o 40%-80%. Przepustowość pamięci się nie zmieniała.
Sposób korzystania z pamięci był taki sam, bo algorytmy za każdym
razem te same. Wniosek dla mnie jest taki, że pisząc nawet
przyzwoity kod w asemblerze można spowolnić wykonanie. Co by było
gdyby kompilator porównać z kodem optymalnym - nie wiem, o to
właściwie ja czasami dopytuję i nie uważam żeby moje pytania
oznaczały totalnie niezrozumienie, co powyżej uzasadniłem.


> samo to przepisywanie kodow by unikaly przetwazania pamieci jest raczej
> co nieco nieprzyjemna i 'nadbudowana' optymalizacyjna algorytmiką i
> moim zdaniem niekoniecznie to trzeba robic bo kody robia sie od tego
> dluzsze i brzydsze a nie maja dodatkowej funkcjonalnosci wrecz
> nabieraja węższej ak ze jest to mocno specjalistyczna dzialka)
Tu się zgadzam, przykładem jest ATLAS. Koszmarek implementacyjny i
zarazem dzieło sztuki implementacyjnej.

Pozdrawiam