On Saturday, 13 October 2018 at 18:14:20 UTC, Vijay Nayar wrote:
On Saturday, 13 October 2018 at 18:05:45 UTC, Jabari Zakiya
wrote:
It may be also running into a hard time limit imposed on
compilation that Nim had/has that prevented my code from
initially compiling. I'm generating a lot of PG parameter
constants at compile time, and it's doing a lot of number
crunching and building larger and larger arrays of constants
as the PG's get larger.
Try compiling with successive PG's (just P5, then P5 and P7,
etc) to see where it fails. That will let you know the code is
working correctly, and that the compiler is choking either/and
because of a hard time limit and/or memory limit. That's why I
put in a compiler output statement in 'genPGparameters' to see
the progression of the PG parameters being built by the
compiler to initially find when the compiler started choking.
You may also need to patch whatever facility in the D compiler
chain that controls this too.
It's P17, the biggest one that takes the longest to build in
the Nim version. I actually don't know what memory limits exist
for the D compiler at compile-time, so I may need to do some
homework.
Yes, that's what I figured, because that's when the Nim compiler
initially balked. The variable that was patched in the Nim
configg file set a hard limit on number of operations the
compiler could do. It's used as a break switch on a runaway
process (infinite loop, etc). It's probably something like that
in the D compiler too, just guessing offhand. I hope it isn't a
memory limit. However, the program will run fine without using
P17. It's currently selected as the optimum PG for inputs greater
than 15 trillion (15,000,000,000,000), so the program will run
fine and produce correct output using P13 instead, but just not
as fast.
