Maximum array size

Question

Hi,
I am using LabVIEW 8.2.1 (RT & DSC)
I need to process something while having all the prime numbers less than 1E9 available.
there are approximately 51 million.
is it ok with LabVIEW?  (array of the size 51 million) I will use 64bit array.
can LabVIEW deal with this size of array?
am I underestimating LabVIEW?
Thanks,
Amitai Abramson.

Answer 1

Alain S wrote:
altenbach wrote:
I just dug out my old prime code for up to 8 digit factors. It takes about 6 seconds to generate all 8 digit primes.
About 3.5 sec for primes up to 200000
and 41 sec for primes up to 999999
My code does 200000 is about 6ms (600x faster) and 999999 in about 32ms. (1200x faster)
(of course it also depends on hardware ) 
Alain S wrote:
So would you be so kind to point out where I could improve the code?
Initialize an array of x elements
Fill the array with numers 0 to x
Do the "Eratosthenes" trick to eliminate non primes. To avoid redim of the array I replace non primes by -100
Sort the array to get all -100 at the top of the array
Remove all equals (-100) with Open G vi
Remove first three elements (-100, 0 & 1) to keep only real primes.
A FOR loop knows the number of iterations, so generating the values in an autoindexing shift register is equally efficient and simpler. Steps (1&2) can be combined. It is also sufficient to only consider odd values (except "2"), reducing the array by 50%.
You are already touching the element so why not move it down to the next prime slot, reusing the operating array for the prime storage at once. This also eliminates sorting (O(NlogN)) and openG tools. Just truncate at the end after the last prime found. (4&5).
Looking at your code:
General:
Don't use a timeout case to poll the stop button 100x/sec while the program is idle. Use a latch action button to start the code, no need to reset via a value property (if you really want to reset the value, use a local variable instead). Use another event for the stop button.
While loop:
With every iteration of the while loop, you are converting to DBL and taking the square. Keep it blue! There should be no orange wires!
You can precalculate the number of iterations and use a FOR loop, eliminating the termination calculations.
Inner FOR loop:
You don't need to do trial divisions, this is way too much work. (The main reason for the slow performance!). Simply calculate the multiple indices directly. Once you are at half-size, there are no multiples left, don't keep looking for them. (My code runs the inner FOR loop 0 times for large values, eliminating a case structure).
After the loop:
Sorting is not needed if you correctly place the primes as they are calculated.
After sorting, all "-100" are at the beginning. All you need to do is search for the element with "2" and take the subset to the end. No need for fancy openg tools.
You shoud write to the indicator after the sequence. You don't want the timing to be biased by potential indicator updates.
Attached is a simple version of the code (LabVIEW 8.0. I have some others that might be more optimized in other terms (e.g. smaller memory footprint)). Of course there could be bugs.
See if it makes sense. I am sure there are inprovements possible. Of course you want to do this only once if it is part a bigger code, so use the "first run?" primitive and keep the primes in a shift register. No need to use an indicator for them at all.
Message Edited by altenbach on 11-29-2009 11:41 AM
LabVIEW Champion . Do more with less code and in less time .
Attachments:
FindPrimes.png ‏29 KB
FindPrimeFactors_only001.vi ‏20 KB