50g Mini-Challenge: Number of positive divisors of x!

[Joe Horn]

(09-30-2017 09:31 PM)Gerald H Wrote:  The User programme below took 14.9141s to process 320.

Code:

« 1 SWAP 0
  WHILE NEXTPRIME
DUP2 ≥
  REPEAT DUP2 0
OVER 4 ROLL 4 ROLL
    WHILE DUP2
IQUOT DUP 0 >
    REPEAT 5 ROLL +
4 ROLLD PICK3 *
    END 4 DROPN 1 +
4 ROLL * UNROT
  END DROP2
»

Exactly the same program* on my 50g takes 18.6 seconds for an input of 320, so your 50g must be faster than mine. *"Exactly the same" ... well almost; I always use reals for the arguments to stack commands (e.g. 4. ROLL instead of 4 ROLL) because it's a tad faster that way. With integers in their place, it takes 0.3 seconds longer for an input of 320.

(09-30-2017 10:52 PM)DavidM Wrote:  In addition to the inherent loop structure speedup that SysRPL gives, I think if you look at what's inside those loops you'll see another reason for the speed advantage that Gerald's SysRPL version has: lots of "combo" commands that directly manipulate the stack without having to validate the arguments given. 5ROLL, 4UNROLL, 2DROP, etc. go about their business without bothering to check that the stack can accommodate their action or that the numeric constant applies. So in many of the "equivalent" UserRPL steps, you've not only got the usual overhead for argument count/type checking (and LASTARG/cached stack saving), you've also got additional RPL stream maintenance and stack validation occurring that aren't present when executing the SysRPL code.

Those combo commands for manipulating the stack can be a pain to remember in SysRPL but they really pay off sometimes in inner loops.

Good point. In his System RPL book, Jim Donnelly wrote, "The System-RPL example will run faster than the User-RPL program, because all the argument checking code has been bypassed." Nice to know that the speed increase can be this dramatic!