Re: dalsza optymalizacja - Grupy dyskusyjne w eGospodarka.pl

eGospodarka.pl › Grupy › pl.comp.programming › dalsza optymalizacja › Re: dalsza optymalizacja

Path: news-archive.icm.edu.pl!news.icm.edu.pl!wsisiz.edu.pl!newsfeed2.atman.pl!newsfe
ed.atman.pl!.POSTED!not-for-mail
From: bartekltg <b...@g...com>
Newsgroups: pl.comp.programming
Subject: Re: dalsza optymalizacja
Date: Sun, 01 Apr 2012 16:05:54 +0200
Organization: ATMAN - ATM S.A.
Lines: 70
Message-ID: <jl9nc4$oha$1@node2.news.atman.pl>
References: <jl73ie$b6f$1@inews.gazeta.pl> <jl9aaf$326$1@inews.gazeta.pl>
<jl9al3$ee7$1@inews.gazeta.pl> <jl9dfl$a80$1@inews.gazeta.pl>
<jl9e7f$epj$1@node2.news.atman.pl> <jl9ftm$j00$1@inews.gazeta.pl>
<jl9h5r$i0o$1@node2.news.atman.pl> <jl9ju9$o28$1@inews.gazeta.pl>
NNTP-Posting-Host: 144-mi3-6.acn.waw.pl
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: node2.news.atman.pl 1333289156 25130 85.222.69.144 (1 Apr 2012 14:05:56 GMT)
X-Complaints-To: u...@a...pl
NNTP-Posting-Date: Sun, 1 Apr 2012 14:05:56 +0000 (UTC)
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327
Thunderbird/11.0.1
In-Reply-To: <jl9ju9$o28$1@inews.gazeta.pl>
Xref: news-archive.icm.edu.pl pl.comp.programming:196508
[ ukryj nagłówki ]
W dniu 2012-04-01 15:07, M.M. pisze:
> bartekltg<b...@g...com> napisał(a):
>
>> W dniu 2012-04-01 13:58, M.M. pisze:
>>
>>>
>>> Raczej tak:
>>> double x[1000];
>>> for( i=0 ; i<1000000 ; i++ )
>>> x[rand()%size] ++;
>>>
>>> Na:
>>
>> tutaj jeszcze konwersja w drugÄ stronÄ.
>>
>>> int tmp[1000];
>>> for( i=0 ; i<1000000 ; i++ )
>>> tmp[rand()%size] ++;
>>>
>>> double x[1000];
>>> for( i=0 ; i<1000 ; i++ )
>>> x[i] = (double)tmp[i];
>>>
>>> DĹuĹźsze obliczenia na intach i potem jedna konwersja na doubla.
>>> Problem w tym Ĺźe obliczenia na intach sÄ trywialne, tylko inkrementacja.
>>
>> I co CiÄ powstrzymuje przed odpaleniem tego z pomiarem czasu;)
>>
>> BTW, http://www.youtube.com/watch?v=gENVB6tjq_M
>>
>> Chcesz rozdaÄ milion kulek w tysiÄc otworkĂłw.
>> To tego wystarczy ~1000 losowaĹ i tyle dodawaĹ
>> (+ coĹ tego rzÄdu obliczeĹ zwiÄzanych z rozkĹadem
>> Poissona), a pewnie da siÄ i lepiej.
>>
>> PodpowiadaÄ dalej?
>
> Chyba zakręciłem totalnie jaka jest istota problemu i nikt
> nie zrozumiał, sorry :D
>
> Chyba mogłem zapytać prościej: czy inkrementacja intów jest
> szybsza od inkrementacji doubli? Dane są wybierane w przybliżeniu
> z losowych adresow w pamięci, czyli nie chodzi o inkrementację jednej
> zmiennej ktora jest ciagle w rejestrze procesora. Tablice z danymi

Ależ rozumiem. Za to nie zrozumiałeś odpowiedzi:(

> mieszcza sie w L2, ale nie mieszcza sie w L1.

@pytanie o szybkość: Mówiłem, sprawdź.

int:1.682000 i2f:0.000000 double:1.766000 f2i:0.000000
int:1.688000 i2f:0.000000 double:1.794000 f2i:0.000000
int:1.696000 i2f:0.000000 double:1.773000 f2i:0.000000
int:1.691000 i2f:0.000000 double:1.765000 f2i:0.000000

W praktyce nie ma znaczenia. Przypadek sferyczniesymetryczny
sugeruj, że mozesz tak zyskać kilka %, ale w prawdziwym
programie niekoniecznie wyjdzie to na zdrowie.

A co do meritum, chcesz rozdać milion "+1" dla 1000 obiektów.
Dokładnie to robi Twój kod. Możesz to zrobić rząd lub dwa szybciej
używając 'matematyki' zamiast brutalnie siły. Teraz jasne?

pzdr
bartekltg