slow access to consecutive matrix elements
Francesco Potorti`
Potorti at isti.cnr.it
Sat Oct 11 03:22:20 CDT 2008
This is a real life example that demonstrates how access to matrix
elements is not optimised for the case of complete ranges in the first
dimensions. I am sending it here and not to the bug list because this
example may be useful to others, at least until this cases is optimised
in the sources.
# This is a big 5-dim matrix, about 100MB size
octave> kk=rand(156,222,1,44,8);
# I access a slice of it, which is sequential in memory
octave> t=cputime; for ii=1:44, for jj=1:8
mm=kk(:,:,:,ii,jj); endfor, endfor, cputime-t
ans = 5.9124
# Using a linear index is much faster
octave> span=(1:156*222);
t=cputime; for ii=1:44, for jj=1:8
mm=kk(sub2ind(size(kk),1,1,1,ii,jj)+span-1); endfor, endfor, cputime-t
ans = 2.6642
# Removing the call to sub2ind reaches top speed
octave> cp=[1,cumprod(size(kk)(1:end-1))]; span=(1:156*222);
t=cputime; for ii=1:44, for jj=1:8
mm=kk(sum(([1,1,1,ii,jj]-1).*cp)+span); endfor, endfor, cputime-t
ans = 1.4001
Still, I wish access were faster yet. Is there a reason why copying
consecutive memory is so slow? I wish I could help with optimising
this, even if I am certainly not the most qualified person to do it.
--
Francesco Potortì (ricercatore) Voice: +39 050 315 3058 (op.2111)
ISTI - Area della ricerca CNR Fax: +39 050 315 2040
via G. Moruzzi 1, I-56124 Pisa Email: Potorti at isti.cnr.it
(entrance 20, 1st floor, room C71) Web: http://fly.isti.cnr.it/
More information about the Bug-octave
mailing list