A Friendly Challenge for D

[Jabari Zakiya]

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.