On Sun, 17 May 2009 22:40:07 +0100, Bronek Kozicki <b...@s...net>
wrote:

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

JEzeli ten sam kawalek kodu napisze 20 razy zamiast raz, to nei
spwolni to WYKONTWANIA programu. Co wiecej, mzoe przyspeiszyc
wykonywanei programu. Slszal Kolega "generative orpgramming"? To jest
programwoanei przy pomocy "templates" w C++, miedzy innymi
umozliwiajace "rozwineicie" petli na szeregowu kod zawierajacj kolejne
"wnetrza" petli. Likwiduje sie w ten sposob narzut zwiazany z
wykonywaniem petli.

Podsumowujac: mniej koku i wielokrotne uzycie kodu spowalnei program a
nei przyspiesza"

A.L.

do góry

On Sun, 17 May 2009 22:40:50 +0100, Bronek Kozicki <b...@s...net>
wrote:

>A.L. wrote:
>> SZYBKI program". Otoz, cogezje, inwarianty itede nic w spolnego z
>> szybkoscia wykonyania programu nie maja
>
>ależ mają - mniej kodu.
>

mniej kodu =/= szybciej dzialajacy program. Na ogol wrecz przeciwnie

A.L.

do góry

On Sun, 17 May 2009 23:40:11 +0200, Wojciech Muła
<w...@p...null.onet.pl.invalid> wrote:

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

Co prawda o tym w tym watku nie pisalem, ale potwierdzam - lokalnosc
danych ma znaczenie kapitalne dla wydajnosi

A.L.

do góry

Wojciech Muła napisał:
Witam,

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

Mała uwaga na boku wątku, fajnie to zagadnienie opisane jest w:
"What Every Programmer Should Know About Memory" Ulricha Dreppera
http://people.redhat.com/drepper/cpumemory.pdf

Pozdrawiam,
Kupson
--
Great software without the knowledge to run it is pretty useless.
(Linux Gazette #1)

do góry

Użytkownik "Wojtek Pietruszewski" <gotohell@once.> napisał w wiadomości
news:gup173$356$1@nemesis.news.neostrada.pl...
> "Jacek Czerwinski" <...@...z.pl> wrote in message
> news:guoofk$u1t$2@news.onet.pl...
>> Wojtek Pietruszewski pisze:
>>>> "Marteno Rodia" <m...@o...pl> wrote in message
>>>> news:94fc50cb-2939-4dfe-80ad-3afd6a8f5b26@r34g2000vb
i.googlegroups.com.
>>>> .. 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.
>>> Jeżeli będą wykonywane operacje arytmetyczne możesz spróbować wstawek
>>> asemblerowych.
>> Are You sure?
> No jeżeli program ma działąć pod windowsem, to oczywiście


Niekoniecznie, prawdą to było za czasów Turbo Pascala. Teraz trzeba na
prawdę dobrze znać się na prockach, aby w asmie napisać coś lepiej niż zrobi
to optymalizator współczesnego kompilatora. Sam się w to parę lat temu
wpakowałem jak pisałem na koprocesorze symulację fizyczną. Nie dosyć, że
asma znałem raczej kiepsko i poświęciłem kilka tygodni na wyedukowanie się,
to się okazało, że mój kod był wolniejszy niż ten napisany w języku
wysokiego poziomu.

do góry

On 17 Maj, 23:40, Wojciech Muła
<w...@p...null.onet.pl.invalid> wrote:

> > 1) dużo czasu zjadają np. operacje wejścia/wyjścia
>
> Wówczas można spróbować asynchroniczne I/O.

I wtedy się szybciej dysk kręci?

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

do góry

On 18 Maj, 09:02, Maciej Sobczak <s...@g...com> wrote:
> On 17 Maj, 23:40, Wojciech Muła
>
> <w...@p...null.onet.pl.invalid> wrote:
> > > 1) dużo czasu zjadają np. operacje wejścia/wyjścia
>
> > Wówczas można spróbować asynchroniczne I/O.
>
> I wtedy się szybciej dysk kręci?

Bez sensu się czepiasz. W kontekście problemu Kolegi (duża ilość
danych),
asynchroniczne I/O może pomóc. No chyba, że wszystko mu się zmieści
w pamięci wewnętrznej.

w.

do góry

On 18 Maj, 09:35, Wojciech Muła <w...@p...onet.pl> wrote:

> > > Wówczas można spróbować asynchroniczne I/O.
>
> > I wtedy się szybciej dysk kręci?
>
> Bez sensu się czepiasz. W kontekście problemu Kolegi (duża ilość
> danych),
> asynchroniczne I/O może pomóc.

Nadal chciałbym wiedzieć dlaczego.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

do góry

Maciej Sobczak wrote:
> On 18 Maj, 09:35, Wojciech Muła <w...@p...onet.pl> wrote:
>
>>>> Wówczas można spróbować asynchroniczne I/O.
>>> I wtedy się szybciej dysk kręci?
>> Bez sensu się czepiasz. W kontekście problemu Kolegi (duża ilość
>> danych),
>> asynchroniczne I/O może pomóc.
>
> Nadal chciałbym wiedzieć dlaczego.

Ponieważ dane są pobierane równolegle z wykonaniem programu. Nie wierzę,
żebyś nie wiedział o co chodzi, więc rozumiem, że przeczytałeś coś
świetnego w mądrej książce i tylko czekasz, żeby zaprezentować :)
Dajesz, dajesz :)

JD

do góry

Maciej Pilichowski wrote:
> aby zawsze pisac ++var zamiast
> var++ (o ile merytorycznie nie zachodzi koniecznosc tego drugiego),

Im dluzej o tym mysle, tym bardziej nie rozumiem, o co Ci mogło chodzic;-)

pozdrawiam
--
bartekltg
...aby UseNet rósł w siłę a trolle siedziały cicho

do góry