help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: trying to optimize my octave program


From: Jaroslav Hajek
Subject: Re: trying to optimize my octave program
Date: Fri, 19 Mar 2010 21:50:39 +0100

2010/3/19 Tim Rueth <address@hidden>:
>> I modified your example code so that it runs and made a
>> stupid analyze.m that does nothing--anyway I don't think I
>> broke it. I ran it to see how much overhead this structure is
>> causing on my system.
>>
>> octave:1> testfor
>> Elapsed time is 2.75838 seconds.
>>
>> If analyze.m only takes 0.01sec then 6*21*8*3*3*3*3
>> iterations should be about 18 min? I would say the for loop
>> structure overhead is negligible compared to whatever is
>> happening inside analyze.m. Does
>> analyze() slow down eventually (are the vectors growing)?
>> Maybe it starts at 0.01sec at the beginning and gets slower?
>> Is this example code much slower on your machine (I don't
>> have much experience with the Windows port)?
>
> Your testfor script took 5.5 sec on my computer (Vista, 2.17GHz, 4GB).  May
> be time for an upgrade.
>
> My function analyze() takes about 4.5 sec because it runs yet another
> for-loop inside with 4288 iterations.  The code within this for-loop takes
> about 0.001 sec for each iteration (4288*0.001 = 4.3 sec).  There are only a
> couple of very small vectors that grow and wouldn't contribute any
> noticeable slow-down.
>
>> Just speculating again, but I suspect that these four loops
>> are prime candidates for replacement by vectorization.
>> Perhaps analyze() can be modified to handle c_thd, r_thd,
>> t_thd, b_thd as matrix/vector forms of these variables.
>> ndgrid may help with this:
>>
>> [c_thd, r_thd, t_thd, b_thd ] = ndgrid(
>> [c_thd_min:c_thd_st:c_thd_max] ,
>> [r_thd_min:r_thd_st:r_thd_max] , [
>> t_thd_min:t_thd_st:t_thd_max] , [ b_thd_min:b_thd_st:b_thd_max] )
>
> I see what you're suggesting here...basically "parallel-process" these 4
> for-loops right inside analyze() by creating a 4-D matrix, and pass this 4-D
> matrix right through analyze()'s for-loop once.  Brilliant, as long as this
> matrix and the matrices that I'm operating on (now in parallel) don't cause
> memory problems.  If ndgrid makes a 4-D matrix which has, say, 256 elements
> (4 in each dim), then I'll be creating 256 copies of several vectors inside
> analyze(), each which has a length of 4288.  I started implementing this but
> hit two snags:
>
> 1) How can I initialize a multidimensional array with, say "foo" in each
> element, without a for loop?  Exactly like zeros(...) but filling each
> element with "foo" instead of 0.
>
> 2) How do I do element-wise comparisons and conditional string assignments
> on matrices without stepping through them?  For example, let's say I have
> two 4-D matrices, a_mat and b_mat with numeric values.  I'd like to create a
> new 4-D string matrix, c_mat, where
>
> for each i in a_mat
>  if a_mat(i) < b_mat(i)
>    c_mat(i) = "foo";
>    cntr++;
>  endif
> endfor
>
> Would be awesome to be able to do this at the matrix level (no for-loops).

mask = a_mat < b_mat;
c_mat(mask) = {"foo"};
cntr = sum (mask(:));


-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz



reply via email to

[Prev in Thread] Current Thread [Next in Thread]