[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
3D versus 2D Indexing and the Speed Thereof
From: |
John W. Eaton |
Subject: |
3D versus 2D Indexing and the Speed Thereof |
Date: |
Tue, 21 Nov 2006 03:16:13 -0500 |
On 20-Nov-2006, Luis Ortiz wrote:
| Folks:
|
| One of my engineers reported an odd performance problem in Octave,
| which I am afraid to tackle without a little bit of guidance.
| The first snippet of code he gave me to consider was:
| x=zeros(100,50,100);
| tic;
| for i = 1:100
| z = x(:,:,i);
| end
| toc
|
| The second snippet of code he gave me to consider was:
| x=zeros(5000,100);
| tic;
| for i = 1:100
| z = x(:,i);
| end
| toc
|
| Now the 2D form is about 22 times faster than the 3D form, even though
| the amount of data being slung about is the same.
BTW, on my system, I see the following results. Not great, but not a
factor of 22 either.
octave:4> for i = 1:3
> x = zeros (n, 50, 100);
> t = cputime ();
> for i = 1:100
> z = x(:,:,i);
> end
> t1 = cputime () - t;
> x = zeros (50*n, 100);
> t = cputime ();
> for i = 1:100
> z = x(:,i);
> end
> t2 = cputime () - t;
> fprintf ("%6d %f %f %f\n", n, t1, t2, t1/t2);
> n = n * 10;
> end
10 0.068005 0.012000 5.667083
100 0.604037 0.100006 6.040008
1000 5.996376 1.036065 5.787645
OTOH, if Octave's Array class knew how to do slices and if we
recognized these operations as slices, then the time should be
constant here, not proportional to the number of elements copied.
jwe