On Sat, 23 May 2009 14:59:51 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:

>On 20 Maj, 14:32, A.L. <a...@a...com> wrote:
>
>> >Czyli cały czas mówimy o użyciu współbieżności w celu lepszego
>> >wykorzystania zasobów sprzętowych. Powtórzę: to nie jest wyłączna
>> >cecha AIO. Współbieżność jest narzędziem bardziej ogólnym.
>>
>> .. i uzycie jej nie gwarantuje automatycznie poprawienia sprawnosci...
>>
>> http://www.ddj.com/go-parallel/article/showArticle.j
html?articleID=21...
>
>Co to ma do obliczeń wykonywanych równolegle z I/O?

Zalezy od Panskiej interpretacji tekstu

A.L.

do góry

> >>Dana jest zmienna
> >>
> >>int var = 0;
> >>
> >>dalej użyta jako licznik w pętli.
> >>W celu ziększenia wartości var o 1 mamy kilka możliwości,
> >>rozpatrzmy dwie z nich: ++var lub var++.
> >>
> >>Którą wersję Kolega by wybrał i jak uzasadniłby wybór?
> >>
> >
> > Nie da sie uzasadznic wyboru nie znajac kontekstu w ktorym ta operacja
> > jest uzyta.
>
> Ano właśnie. Ja nie podałem szczegółów kontekstów a mimo to Kolega
> potrafił wyrazić krytykę, rozumiem że uzasadnioną i o to uzasadnienie
> prosiłem.
> Przyjmuję, że "nawyki eliminuja myslenie" jest tym uzasadnieniem. Zgadzam
> sie z nim.

Dla mnie też było oczywiste, że chodzi o inkrementację zmiennej typu
podstawowego. Szczegóły były podane niejawnie, gdyż optymalizowanie
zapisu kompletnie nie idzie w parze z żadnymi wysokopoziomowymi
konstrukcjami, np. z przeciążeniem operatorów :)

Jak uzasadnić użycie ++var zamiast var++ w kontekście optymalizowania
zapisu? Taka operacja dla typu podstawowego to niuans i można by
pominąć jej wpływ na wydajność kodu wynikowego. Jednak czasami użycie
var++ zamiast ++var umożliwia inną konstrukcję pozostałych instrukcji,
więc chodzi o coś więcej niż var++ vs ++var. Jak uzasadnić użycie
jednego zapisu wraz z var++ a nie drugiego z ++var? Otóż skompilować i
zrobić test szybkości. Następnie wybieramy ten który jest "szybszy".
W cudzysłowie dlatego, że po przeniesieniu na inny procesor, albo po
skompilowaniu innym kompilatorem wynik może być inny :) No ale taki
bardzo ograniczony sens ma optymalizowanie zapisu zamiast
optymalizowania algorytmów :)

Pozdrawiam


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

do góry

A.L. <a...@a...com> napisał(a):
> Podsumowujac: mniej koku i wielokrotne uzycie kodu spowalnei program a
> nei przyspiesza"

Nie zawsze to przyspieszy, gdyż wykonując w pętli ten sam kod zwiększa
się szansę na to, że kod jest w pamięci podręcznej i dlatego wykona się
szybciej pomimo dodatkowych instrukcji na pętle i warunek pętli.

Pozdrawiam



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

do góry

Użytkownik "gosmo" napisał:

> to się okazało, że mój kod był wolniejszy niż ten napisany w języku
> wysokiego poziomu.

Co w tym dziwnego, skoro sam piszesz, że nie masz pojęcia o assemblerze?
Dziwne jest raczej to, że w ogóle działało. Natomiast twierdzenie, że jakiś
optymalizator zrobi coś lepiej niż wprawny programista w asm jest delikatnie
mówiąc bajaniem laika. Zresztą co tu miałby do roboty optymalizator.
Optymalizować trzeba sam algorytm, a nie program.

Remek

do góry

On Sun, 7 Jun 2009 07:20:32 +0200, "Remek" <w...@n...pl>
wrote:

>U?ytkownik "gosmo" napisa?:
>
>> to si? okaza?o, ?e mój kod by? wolniejszy ni? ten napisany w j?zyku
>> wysokiego poziomu.
>
>Co w tym dziwnego, skoro sam piszesz, ?e nie masz poj?cia o assemblerze?
>Dziwne jest raczej to, ?e w ogóle dzia?a?o. Natomiast twierdzenie, ?e jaki?
>optymalizator zrobi co? lepiej ni? wprawny programista w asm jest delikatnie
>mówi?c bajaniem laika. Zreszt? co tu mia?by do roboty optymalizator.
>Optymalizowa? trzeba sam algorytm, a nie program.
>
>Remek
>

Pieprzysz, jak, przepraszam za wyrazenie, potluczony

A.L.

do góry

Remek pisze:
> Użytkownik "gosmo" napisał:
>
>> to się okazało, że mój kod był wolniejszy niż ten napisany w języku
>> wysokiego poziomu.
>
> Co w tym dziwnego, skoro sam piszesz, że nie masz pojęcia o assemblerze?
> Dziwne jest raczej to, że w ogóle działało. Natomiast twierdzenie, że jakiś
> optymalizator zrobi coś lepiej niż wprawny programista w asm jest delikatnie
> mówiąc bajaniem laika. Zresztą co tu miałby do roboty optymalizator.
> Optymalizować trzeba sam algorytm, a nie program.
>
> Remek
>
Wydaje mi się, że aby napisać szybki program w asm nie wystarczy dobrze znać asm-a.
Trzeba przede wszystkim znać procesor na który się pisze. A obecne procesory są
"dość" skomplikowane. To nie jest chyba tak, że mamy pamięć i kilka rejestrów, choć
z pewnego punktu widzenia tak to może wyglądać. Nie wszystkie instrukcje wykonują się
równie szybko, a część operacji można chyba zrównoleglać (mówię o pracy na tym samym
rdzeniu). Kideyś miałem taką książeczkę "procesry x486" czy jakoś tak. Tam były
opisane wszystkie instrukcje i ile taktów procesora potrzeba na ich wykonanie.
To jest chyba kluczowa sprawa. Ale pewnie dla każdej następnej generacji procesorów
te dane się zmieniają. W Pentium4 były już jakieś potoki wykonawcze
(hyper-threading),
i być może niektóre operacje można było zrównoleglać, ale pod pewnymi warunkami,
itp..
A... bym zapomniał - jeszcze cache - ile to tam tych poziomów było ?

Zadanie napisania optymalnego programu w asm dla konkretnego procesora to chyba
jest pewien problem optymalizacyjny, z ogromną ilością zmiennych. Szansa, że człowiek
potrafi to lepiej rozwiązać, niż wyspecjalizowany program jest chyba niewielka.

Oczywiście, to są moje gdybania, jeśli czyta to ktoś znający się na rzeczy, to niech
się do tego odniesie.


M.H.

do góry