A Friendly Challenge for D

[Jabari Zakiya]

On Saturday, 13 October 2018 at 18:31:57 UTC, Vijay Nayar wrote:
> 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.
>
> It's not just DMD either.
>
> $ ldc2 twinprimes_ssoz.d
> ...
> generating parameters for P17
> Killed
>
> $ gdc twinprimes_ssoz.d
> ...
> generating parameters for P17
> gdc: internal compiler error: Killed (program cc1d)
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.
>
> $ dmd twinprimes_ssoz.d
> ...
> generating parameters for P17
> Killed

In the Nim code, starting line 91 is when the PG constants are 
being generate at compile time.

---------------------------------------------------------
# Generate at compile time the parameters for PGs P5-P17.
const parametersp5  = genPGparameters(5)
const parametersp7  = genPGparameters(7)
const parametersp11 = genPGparameters(11)
const parametersp13 = genPGparameters(13)
const parametersp17 = genPGparameters(17)
---------------------------------------------------------

Can it compile just using P5 (the first line, others commented 
out), and then P7, etc?

I'm not understanding your comments now.

If you can get a working version up and running (with correct 
output) we can solve the P17 compiler issues later (or in a 
parallel forum thread), especially if you have to delve into the 
weeds of the compiler chain.

In my mind (same with Nim process) getting working code using any 
PG is first order priority (because you'll need getting 
multi-threading working too). Once you can do that, by default, 
you can then use any generator you want if you create the correct 
parameters for it. That's one of the advantages of the algorithm, 
it's PG agnostic (as long as your hardware will accommodate it).

So don't prioritize getting P17 to compile right now (in this 
thread). Create the working generic structure that can work with 
any PG first.