LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How can I restructure an unfavourable 2D array format to 1D?

Solved!
Go to solution

A minor correction on the timing charts -- I was a little careless in ignoring "overhead".  I tried doing the tests in the reverse order, doing my version first, then Altenbach's.  I still win, but the ratios are a little smaller (3:1 for the small array, 10:1 for the larger).

 

BS

0 Kudos
Message 11 of 18
(840 Views)

Must be some architectural or age-dependant factor. The attached VI shows at best half speed of concatenation on an AMD 8350. (Loop parellallization on concatenation sped it up some)

 

Reshape-speed.png

 

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 12 of 18
(824 Views)

I also get about 2x the speed using reshape.

0 Kudos
Message 13 of 18
(820 Views)

Very interesting (and instructive).  Our codes are almost identical, except I wasn't using the "parallelization" trick, and was using a slightly different "clock" for timing.  I like your clock -- where does it come from?  I'm using code I found several years ago on an NI site that uses the CPU's System Clock -- maybe that is showing its age?

 

Anyway, on my machine, with your code and your clock, but with parallelism turned off (which, on my dual-core machine, sped things up), the Reshape version runs about twice as fast as Concatenate.  Time to get out my watchmaker's loupe and figure out why my clock is doing so poorly.

 

Thanks to both of you for your comments.

 

BS 

0 Kudos
Message 14 of 18
(796 Views)

@Bob_Schor wrote:

I like your clock -- where does it come from?


...\Vi.lib\Utilitiy\High Resolution Relative Seconds.vi (note that the times are in seconds, not us as indicatoed on the fp above. I usually use a display format of "%.2ps", try it. :D).


Bob_Schor wrote:

Anyway, on my machine, with your code and your clock, but with parallelism turned off (which, on my dual-core machine, sped things up), the Reshape version runs about twice as fast as Concatenate.  Time to get out my watchmaker's loupe and figure out why my clock is doing so poorly.


I don't think the clock used really makes a difference. The reshape shows an additional buffer allocation dot, but things could change as you rearrange the code.

0 Kudos
Message 15 of 18
(792 Views)

P.S. -- and maybe it really is my crummy PC -- I couldn't get the code, as submitted, to run without shortening the list of test arrays (I used 3, 30, 300, and 3000 as my first dimension, which ran without LabVIEW giving me an "out of memory" error).  Hmm, now I don't remember if these errors came with Parallelism on or if I'd already turned it off ...

0 Kudos
Message 16 of 18
(791 Views)

I am running out of memory on the 6000x9000 too. You probably need LabVIEW 64bit for that, or maybe test right after a reboot.

 

0 Kudos
Message 17 of 18
(787 Views)

The High resolution clock is an undocumented feature Old Creek above has used before, it's quite nifty in situations like this. I haven't used it much (thus the unit error).

I'm running LV2012x64 and mainly tried bigger arrays to get some good reference points. The last array should fit in memory, but i guess the buffer allocations and possibly the 2 indicators might mess things up a little.

 

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 18 of 18
(783 Views)