On Sun, 17 May 2009 14:46:25 +0200, Maciej Pilichowski
<b...@S...FM> wrote:

>Jacek Czerwinski wrote:
>
>> W konkluzji:
>> I) nie optymalizować.
>
>Nie zgodze sie.

A ja sie z Kolega nei zgodze

>Czesc optymalizacji mozna zrobic w zasadzie nie myslac, jak
>np. przyzwyczajenie sie, aby zawsze pisac ++var zamiast var++ (o ile
>merytorycznie nie zachodzi koniecznosc tego drugiego),

Ze co?...

>
>trzy, ze czesc programow bez optymalizacji po prostu nie skonczy dzialac,

Ze co?,... bedzie petlic sie?...

>a
>cztery ze w tej dzialce, ktora ja sie zajmuje musze dokonac brutalnej
>optymalizacji,

Co to jest "brutalna oprtymailziacja"?...

>aby uzyskac wyniki i zobaczyc, czy to co robie ma sens i
>wtedy podjac decyzje o merytorycznej optymalizacji.

Co to jest "merytoryczna optymalizacja"?...

>
>milego dnia, hej

Hej. Nie wymienialem z Kolega mysli od dowyc dlugiego czasu, ale z
przykroscia zauwazam ze Kolega posunal sie....

A.L.

do góry

On Sun, 17 May 2009 02:31:27 -0700 (PDT), Marteno Rodia
<m...@o...pl> wrote:

>Góglałem, ale nie udało mi się znaleźć syntetycznej odpowiedzi na
>pytanie. Interesuje mnie, jak należy pisać program, żeby wykonywał się
>on szybko. Z reguły pisuję w Javie, teraz mam napisać program (a
>właściwie część do większego programu) w C++, który wykonuje pewne
>obliczenia potrzebne do kompresji wideo. Będzie dużo danych i dużo
>liczenia.
>
>Ogólnie wiem, że:
>
>1) dużo czasu zjadają np. operacje wejścia/wyjścia
>2) w miarę możliwości warto przydzielać pamięć statycznie, a nie
>dynamicznie
>3) unikać nadmiaru rzeczy wykonywanych w pętli (np. sprawdzanie
>jakichś warunków) - innymi słowy:
>4) tak przebudować algorytm, żeby zrobić to samo wykonując mniejszą
>ilość operacji.
>
>Pytania:
>1) Czy mam rację?
>2) Co jeszcze o czym nie wiem?

Nei wiesz o Zadadach Kernighana:

1. "Make it working frst, make it nice later". Najpierw program musi
dzialac, a POTEM musi dzialac szybko. Optymalizacja w trakcie pisania
programu da architektoniczny potworek, na ogol i tak daleki od
optymalnosci. Oczywiscie, nie nalezy uzywac rozwiazan o ktorych od
razu wiadomo ze sa neidobre, na przykald liczenei w kolko tego samego
wyrazenia w petli, czy stosowanei niewlasciwych struktur danych

2. "20% kodu pochlamie 80% casu wykonywania programu". Tzreba te 20%
znalezc i zoptymalizowac. Oczywiscie, po zoptymalizowaniu, INNE 20%
czasu bedzie pochlanialo 80%, wiec procedura musi byc stosowana
iteracyjnie

3. Stosowac nalezy odpowiednei struktury danych zapewniajace
odpowienia zlozonosc obliczeniowa stosowna do skali problemu. Lista
jest bardzo pomocna struktura, ale wyszukwianei w liscie jest liniowe
i kosztowne. Wiec jak lisyta jest dluga a wyszukwianie czeste, to
uzywanei listy bedzie powodowalo starte czasu.

Lista to tylko przyklad. Ilu programistow w Javie uzywajacych HashMap
wie co to jest "loading factor" i dlaczego HasnMap ma konstruktor
pozwalajacy zdefiniowac ow "loading factor"?...

Dla programistow w Jave polecam ksiazke "Java Performance Tuning",
Jack Shirazi, O'Reilly, 2000

A.L.

do góry

Marteno Rodia wrote:
> Góglałem, ale nie udało mi się znaleźć syntetycznej odpowiedzi na
> pytanie. Interesuje mnie, jak należy pisać program, żeby wykonywał się
> on szybko. Z reguły pisuję w Javie, teraz mam napisać program (a
> właściwie część do większego programu) w C++, który wykonuje pewne
> obliczenia potrzebne do kompresji wideo. Będzie dużo danych i dużo

zasady są podobne: ograniczać coupling, maksymalizować cohesion

Albo po kolei
1. dbać o projekt, bo źle zaprojektowany kod ciężko się optymalizuje
2. mało zachować dynamicznych, dużo invariants
3. bardzo ostrożnie podchodzić do pracy wielwątkowej, tak żeby korzyści
nie zostały skonsumowane przez narzut synchronizacji (trzeba balansować)
4. nie trzymać zasobów dłużej niż są potrzebne jeżeli, unikać
dynamicznej alokacji zasobów(znowu trzeba balansować)
5. jasne reguły kto jest właścicielem czego i jak długo

i specyficzne dla C++:
stosować RAII, nie bać się wyjątków (jeżeli koszt CPU błędu przekracza
koszt wyjątku.), nie bać się szablonów itp., nie przesadzać z OOP (dobry
projekt w C++ może się obejść bez "wszystko jest obiektem dziedziczącym
z interfejsu"), .


B.


--
Remove -trap- when replying. Usun -trap- gdy odpisujesz.

do góry

On Sun, 17 May 2009 17:21:00 +0100, Bronek Kozicki <b...@s...net>
wrote:

>2. ...., dużo invariants

Moge prosic o komentarz?...

A.L.

do góry

Dziękuję za odpowiedzi, ale Pana Bronka nie rozumiem. Nie mówię, że
nie gada do rzeczy, ale nie czuję się informatykiem z krwi i kości, a
onże używa nieco typowego informatycznego slangu ;)

do góry

On Sun, 17 May 2009 11:53:44 -0700 (PDT), Marteno Rodia
<m...@o...pl> wrote:

>Dziękuję za odpowiedzi, ale Pana Bronka nie rozumiem. Nie mówię, że
>nie gada do rzeczy, ale nie czuję się informatykiem z krwi i kości, a
>onże używa nieco typowego informatycznego slangu ;)

Ja tez nei rozumiem, mimo ze moj pierwszy komputer byl na lampach
elektronowych :) A moze wlasnie dlatego.... nie rozumiem
informatycznej "nowo mowy"?...

A.L.

do góry

Użytkownik "A.L." <a...@a...com> napisał w wiadomości
news:rco015tccqrhchf7hum675s339u53j0j13@4ax.com...
> On Sun, 17 May 2009 11:53:44 -0700 (PDT), Marteno Rodia
> <m...@o...pl> wrote:
>
>>Dziękuję za odpowiedzi, ale Pana Bronka nie rozumiem. Nie mówię, że
>>nie gada do rzeczy, ale nie czuję się informatykiem z krwi i kości, a
>>onże używa nieco typowego informatycznego slangu ;)
>
> Ja tez nei rozumiem, mimo ze moj pierwszy komputer byl na lampach
> elektronowych :) A moze wlasnie dlatego.... nie rozumiem
> informatycznej "nowo mowy"?...

A co google już nie działają ?

My tu nie rozwiązujemy zadań domych. Najpierw pokaż , że uczyniłeś
trochę własnego wysiłku - np. zacznij byc miły :-) ....

do góry

On Sun, 17 May 2009 21:21:56 +0200, "jelen" <j...@n...rykowisku>
wrote:

>
>U?ytkownik "A.L." <a...@a...com> napisa? w wiadomo?ci
>news:rco015tccqrhchf7hum675s339u53j0j13@4ax.com...
>> On Sun, 17 May 2009 11:53:44 -0700 (PDT), Marteno Rodia
>> <m...@o...pl> wrote:
>>
>>>Dzi?kuj? za odpowiedzi, ale Pana Bronka nie rozumiem. Nie mówi?, ?e
>>>nie gada do rzeczy, ale nie czuj? si? informatykiem z krwi i ko?ci, a
>>>on?e u?ywa nieco typowego informatycznego slangu ;)
>>
>> Ja tez nei rozumiem, mimo ze moj pierwszy komputer byl na lampach
>> elektronowych :) A moze wlasnie dlatego.... nie rozumiem
>> informatycznej "nowo mowy"?...
>
>A co google ju? nie dzia?aj? ?
>
>My tu nie rozwi?zujemy zada? domych. Najpierw poka? , ?e uczyni?e?
> troch? w?asnego wysi?ku - np. zacznij byc mi?y :-) ....
>

Ja mam tak izayczaj ze jak widze belkot to nei pisze "doceniajac
starania autora odnosze jednakze wrazenie ze nie urazajac nikogo..."
tylko pisze "to jest belkot"

Taki mam zwyczaj

A.L.

do góry

On Sun, 17 May 2009 17:21:00 +0100, Bronek Kozicki <b...@s...net>
wrote:

>Marteno Rodia wrote:
>> Góglałem, ale nie udało mi się znaleźć syntetycznej odpowiedzi na
>> pytanie. Interesuje mnie, jak należy pisać program, żeby wykonywał się
>> on szybko. Z reguły pisuję w Javie, teraz mam napisać program (a
>> właściwie część do większego programu) w C++, który wykonuje pewne
>> obliczenia potrzebne do kompresji wideo. Będzie dużo danych i dużo
>
>zasady są podobne: ograniczać coupling, maksymalizować cohesion
>

A co to ma wspolnego z szybkoscia programu?...

A.L.

do góry

Maciej Pilichowski pisze:
> Jacek Czerwinski wrote:
>
>> W konkluzji:
>> I) nie optymalizować.
>
> Nie zgodze sie. Czesc optymalizacji mozna zrobic w zasadzie nie myslac, jak
> np. przyzwyczajenie sie, aby zawsze pisac ++var zamiast var++ (o ile
> merytorycznie nie zachodzi koniecznosc tego drugiego), dwa ze czesc
> optymalizacji jest trywialnych, jak np.
>
> int x;
> vs
> static int x;
>
> (tu mocno przejaskrawiam oczywiscie)

Bardzo

POchwal się źródłem takich zaleceń? Może (na gruncie nowej unijnej
ustawy) trzeba zamknąć jakieś głupawe forum które to rozpowszechnia.
Skoro ogórki z niewłaściwą krzywizną są zakazane ...

Widziałeś choć raz rozwinięcie ++var i var++ ? Co więcej, nawet
var = var+1 oraz var = var+2
widziałem w postaci jednej instrukcji maszynowej.

Z tym static nie rozumiem co przeciwstawiasz, czy auto vs static
wewnątrz bloku (bzdura a po drugie psucie hermetyzacji itd - chyba że na
jakiś wiodących power CPU typu 8051), czy static vs publiczne co nie ma
nic wspólnego z optymalizacją (z dobry stylem zwykle tak).

Ale w sumie dzięki za wypowiedź, pokazuje jak wiele cudacznych porad
'optymalizacyjnych' pokutuje w obszarze 'dobrych rad'.

Synu, za pokutę medytacja starego dowcipu:
"socjalizm dzielnie rozwiązuje problemy nie występujące w innych ustrojach"

do góry