Prime Factor Coding Challenge

[altenbach]

Well, I made a quick VI for the primes up to 2.4 millon and it takes about 200ms on my 1GHz PIII with debugging disabled. Except for the number "2", all primes are calculated from scratch.

I have attached a simplified version with heavily passworded diagram (LabVIEW 7.1.1) so you can run it on your machine. I trust you won't have your buddies at NI crack the password 😉 😮

(OTOH I'll probably have a much faster algoritm in the future anyway :D)

[Dynamik]

Hi Altenbach,

200ms? nice - is that running as a subroutine?

D.

[altenbach]

Yes, it is set to subroutine, but it does not matter much. If I set it to mormal priority, it is only a few ms slower.

However, turning off debugging is more important. If I enable debugging, it's about 20% slower. 🙂

[Dynamik]

Thanks for the tip!  (will look for this "Debugging" option/sw forthwith)

Have invested some time on this.  Thanks for the target (and hints.)

[altenbach]

I'm sure Bruce will test all entries with the same execution settings for a fair comparison. 😉

[BruceAmmons]

I keep the same execution settings on my test vi as what I posted.  I think it is just normal execution.

The execution mode on the vi you send me is not changed.  I would probably set mine to subroutine priority, but it probably doesn't make a big difference.

Bruce

[Dynamik]

Thanks for the info., Bruce.  Doubt I'll submit anything, though.  "Brute force" test to root of candidates (successive/odd) is way too slow.  Improvements have little - even detrimental effect.  I need a "Big O sub-n" (paradigm) epiphany.  That or a password cracker!  

[altenbach]

Bruce,

I think for fairness, you should change the toplevel to time-critical priority for testing. It will eliminate large variations in the results due to OS activity, FP updates, etc.

For each experiment, you should do at least 10 runs, then take the shortest time (NOT the average! All external influences tend to lenghten the time). 🙂

For time-critical, the results between repeated such experiments with the same test subject will show a very narrow distribution because all other activies are suppressed. If you do the same in normal priority, the time distribution will be significantly wider and it will be impossible to fairly rank entries with similar speeds.

[BruceAmmons]

Christian,

Yes, I plan on being fair when judging the final entries.  Each time I run the program, I get very similar results with minor variations.  The depth of comparison that will be needed really depends on how close the best entries are.  A quick test of each entry will be sufficient to determine which ones are the leaders.  If there is less than a second difference between the leaders, I will have to more extensive testing to evaluate them.  The steps you suggest sound pretty reasonable in this case.

Bruce

[BruceAmmons]

Okay folks, help me out.

Right now it looks like just two people are competing heavily in this competition.  How do I get more people involved?  I would like to have a few more entries submitted.

Thanks,

Bruce