I have a program that operates on vectors of data. In each iteration one set of four vectors is processed. I store these vectors as four matrices, each row being a separate vector. I've been refactoring my code recently (the program is in fact quite huge) and I figured that the code would be much cleaner and more correct from the design point of view if I replaced these four arrays with one array of structures, each structure containing four vectors processed in one iteration. I wonder if - and how - such refactoring would impact performance of my program. I know that I can measure it afterwards, but I would like to know is it worth the effort, before spending hours on reworking the code.

I'm also planning to upgrade to R2010b (as soon as our company license server gets updated) and port some of the code to GPU. Would structures be a problem with porting code to the GPU?

"Jan" wrote in message <ihov8n$jfp$1@fred.mathworks.com>...
> I have a program that operates on vectors of data. In each iteration one set of four vectors is processed. I store these vectors as four matrices, each row being a separate vector. I've been refactoring my code recently (the program is in fact quite huge) and I figured that the code would be much cleaner and more correct from the design point of view if I replaced these four arrays with one array of structures, each structure containing four vectors processed in one iteration. I wonder if - and how - such refactoring would impact performance of my program. I know that I can measure it afterwards, but I would like to know is it worth the effort, before spending hours on reworking the code.
> 
> I'm also planning to upgrade to R2010b (as soon as our company license server gets updated) and port some of the code to GPU. Would structures be a problem with porting code to the GPU?

With Jacket (http://www.accelereyes.com) you can store GPU variables inside of structures.  I suggest you look at using Jacket's GFOR functions for running many loop iterations simultaneously on the GPU:  http://wiki.accelereyes.com/wiki/index.php/GFOR_Usage

Good luck!

On Jan 27, 12:07=A0am, "Jan " <fremenz...@poczta.onet.pl> wrote:
> I have a program that operates on vectors of data. In each iteration one =
set of four vectors is processed. I store these vectors as four matrices, e=
ach row being a separate vector. I've been refactoring my code recently (th=
e program is in fact quite huge) and I figured that the code would be much =
cleaner and more correct from the design point of view if I replaced these =
four arrays with one array of structures, each structure containing four ve=
ctors processed in one iteration. I wonder if - and how - such refactoring =
would impact performance of my program. I know that I can measure it afterw=
ards, but I would like to know is it worth the effort, before spending hour=
s on reworking the code.
>
> I'm also planning to upgrade to R2010b (as soon as our company license se=
rver gets updated) and port some of the code to GPU. Would structures be a =
problem with porting code to the GPU?

You don't actually need structures for this.
You can simply add another dimension in your array:
ResultsAll(4,ColNo,IterNo)
That would reduce the re-coding you must do, because you can simply
insert the results into your big 3D array at the end of each
iteration.
ResultsAll(:,:,IterNo)=3DResults;

John > Thanks for pointing me to Jacket, but I'm afraid my company won't go for a license :(

TideMan > The idea seems neat, although I would have to think about ordering of dimensions to maximize performance. Are you sure that the one you proposed (4,ColNo,IterNo) is the most optimal (I think ColNo should be RowNo in your example)? Wouldn't (ColNo,4,IterNo) be faster? At the moment the code runs in a PARFOR loop, so each worker gets it's chunk depending on IterNo.

TideMan <mulgor@gmail.com> wrote in message <906e1cd0-ea0f-4873-8059-617e94692bb9@u18g2000prh.googlegroups.com>
> insert the results into your big 3D array at the end of each
> iteration.
> ResultsAll(:,:,IterNo)=Results;
In fact that array stores only data for calculations, so once it's generated it's read only.

Oh, wait. The array approach won't work - the four arrays have different sizes (the same number of columns, but different number of rows).

> Oh, wait. The array approach won't work - the four arrays have different sizes (the same number of columns, but different number of rows).

Perhaps zero-padding (with small indexing) will overcome that problem.

I have some other information on Jacket I can email you.  Shoot me a note to connect.  My email address is john.melonakos@accelereyes.com