"A.L." <a...@a...com> wrote in message
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 :)

to Ty pracowałeś na ENIACu?

A moze wlasnie dlatego.... nie rozumiem
> informatycznej "nowo mowy"?...
>
> A.L.
>

Rozumiem że w Twoich czasach to pisać nie uczono??
Z tego co widze tylko narzekasz i krytykujesz nie wnosząc nic do dyskusji.
Jeżeli chcesz wykazać się wiedzą informatyczną albo ogólnie pojętą inteligencją
to odpowiedz na pytanie, albo popraw kogoś kto jest w błędzie.

do góry

On Sun, 17 May 2009 12:19:56 +0200, Jacek Czerwinski <...@...z.pl> wrote:

>I) nie optymalizować.

Nieprawda. Optymalizowac:

a. Gdy program dziala za wolno

b. Posluzyc sie regula "20% kodu konsumuje 80% czasu wykonania".
Znalezc te 20% i zoptymalizowac.

c. Go to a.

A.L.

do góry

A.L. wrote:
> On Sun, 17 May 2009 17:21:00 +0100, Bronek Kozicki <b...@s...net>
> wrote:
>
>> 2. ...., dużo invariants
>
> Moge prosic o komentarz?...

invariant , czyli niezmienny elemnt zachowania klasy. Rzecz na której
można polegasć, bo jest zakodowana w projekcie. Np. pole klasy dla
oznaczenia rozmiaru czegoś-tam

int size;

problem: jest kilka innych pól, np.

int size_with_wings;
int size_unfold;

itd. Wartości początkowe są podane przez użytkownika albo pochodzą z
innego źródła, i w kodzie jest wymóg że size jest zawsze z najmniejszy z
tych pól. Można po prostu założyć że tak jest i pisać jakby warunek nie
musiał być sprawdzony (to jest klasyczny invariant). Ale, po uważnym
przyjrzeniu się działaniu programu, okazuje się że raz wprowadzony
rozmiar się nigdy nie zmienia (to jest okazja którą trzeba zobaczyć,
albo czasami stworzyć). A jeżeli się zmienia, to ze względu na pełnioną
funkcję, koszt utworzenia nowego obiektu jest zdecydowanie mniejszy od
kosztu sprawdzania rozmiaru za każdym razem, albo kosztu błędu. Co
robimy? Dopisujemy jedno (albo więcej, do innych pól) const.

const int size;

... i inicjalizujemy w liście inicjalizacyjnej konstruktora (jeżeli
wartość trzeba obliczyć to dobrze sprawdzają się statyczne funkcje
prywatne, albo współdzielone przez klasę i jej użytkowników "utility
functions"; jeżeli trzeba sprawdzić, to oczywiście wyjątki wyrzuca się w
konstruktorze).

W ten sposób mamy invariant zapisany w projekcie

Podobnie : wartości całkowite o specjalnym znaczeniu zapisujemy w enum
(nie #define) bo w ten sposób typesystem możne nam podpowiedzieć czy
stosowane są w dobrym (czy złym) kontekście. Podobnie : stosujemy
referencje zamiast wskaźników (invariantem staje się wybór obiektu do
któego referencja się odnosi), itd. Czyli zmniejszamy ilość kodu
wykonywanego przez CPU (którym można dokonać zmiany wartości/trezba
sprawdzać zgodność wartości z regułami) a zwiększamy ilość kodu
"wykonywanego" tylko przez kompilator - jednocześnie zwiększając
wierność projektu do konretnego zastosowania. Dodatkowa zaleta - taki
kod się łatwo refaktoruje. Jeszcze jedna zaleta - upublicznienie
invariants zapisanych w projekcie powoduje znacznie mniejsze coupling
niż klasyczne pary accesorów get/set , nawet mniejszy niż pojedyncze get
(bez set). Z tego prostego powodu, że łatwiej sprawdzić w jednym
miejscu, tj deklaracje pola klasy (ponieważ jest "const"), że raz
zainicjowane nigdy się nie zmieni, niż szukać w całym kodzie kto,
pośrednio lub bezpośrednio, może modyfikować jego wartość.

OCZYWIŚCIE BEZ PRZESADY. To jest narzędzie, i powinno być stosowane jak
każde inne - jedno z wielu, a nie jedyny młotek w pudle.


B.



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

do góry

A.L. wrote:
> 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"

mam nadzieję, że po moich wyjaśnieniach nie ma takiego wrażenia. Trochę
rzadko tu ostatnio zaglądam, więc odpisuję późno - dzieci itd.


B.


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

do góry

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

>A.L. wrote:
>> On Sun, 17 May 2009 17:21:00 +0100, Bronek Kozicki <b...@s...net>
>> wrote:
>>
>>> 2. ...., dużo invariants
>>
>> Moge prosic o komentarz?...
>
>invariant , czyli niezmienny elemnt zachowania klasy. Rzecz na której
>można polegasć, bo jest zakodowana w projekcie. Np. pole klasy dla
>oznaczenia rozmiaru czegoś-tam

Ja wiem co to jest inwariant. Nie wiem jednak co inwariant ma
wspolnego z szybkoscia wykonywania programu

A.L.

do góry

On Sun, 17 May 2009 22:31:45 +0200, "Wojtek Pietruszewski"
<gotohell@once.> wrote:

>
>"A.L." <a...@a...com> wrote in message
>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 :)
>
>to Ty pracowałeś na ENIACu?
>

Nie na UMC-1

>A moze wlasnie dlatego.... nie rozumiem
>> informatycznej "nowo mowy"?...
>>
>> A.L.
>>
>
>Rozumiem że w Twoich czasach to pisać nie uczono??
>Z tego co widze tylko narzekasz i krytykujesz nie wnosząc nic do dyskusji.
>Jeżeli chcesz wykazać się wiedzą informatyczną albo ogólnie pojętą inteligencją
>to odpowiedz na pytanie, albo popraw kogoś kto jest w błędzie.

Pierdacz sie.

A.L.

do góry

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

>A.L. wrote:
>> 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"
>
>mam nadzieję, że po moich wyjaśnieniach nie ma takiego wrażenia. Trochę
>rzadko tu ostatnio zaglądam, więc odpisuję późno - dzieci itd.
>

Neistety, nie napisal Kolega na temat. Pytanei bylo "jak napisac
SZYBKI program". Otoz, cogezje, inwarianty itede nic w spolnego z
szybkoscia wykonyania programu nie maja

A.L.

do góry

A.L. wrote:
> On Sun, 17 May 2009 21:52:05 +0100, Bronek Kozicki <b...@s...net>
> wrote:
>
>> A.L. wrote:
>>> On Sun, 17 May 2009 17:21:00 +0100, Bronek Kozicki <b...@s...net>
>>> wrote:
>>>
>>>> 2. ...., dużo invariants
>>> Moge prosic o komentarz?...
>> invariant , czyli niezmienny elemnt zachowania klasy. Rzecz na której
>> można polegasć, bo jest zakodowana w projekcie. Np. pole klasy dla
>> oznaczenia rozmiaru czegoś-tam
>
> Ja wiem co to jest inwariant. Nie wiem jednak co inwariant ma
> wspolnego z szybkoscia wykonywania programu

prosto - niezmienny, czyli kawałek kodu który można zapisać w jednym
miejscu - konstruktor - zamiast przed każdym użyciem. Szybciej, nie? I
do tego łatwiej optymalizować.


B.


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

do góry

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

> Ogólnie wiem, że:
>
> 1) dużo czasu zjadają np. operacje wejścia/wyjścia

Wówczas można spróbować asynchroniczne I/O.

> 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.

I jeszcze pamiętać o cache, dbać o lokalność danych w pamięci.
To może mieć naprawdę duże znaczenie na współczesnych procesorach;
tylko jak napisał A.L. - trzeba być pewnym, że w tym tkwi problem
wydajności.

w.

--
Kupię: http://wm.ite.pl/kupie.html

do góry

A.L. wrote:
> SZYBKI program". Otoz, cogezje, inwarianty itede nic w spolnego z
> szybkoscia wykonyania programu nie maja

ależ mają - mniej kodu.



B.


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

do góry