A Friendly Challenge for D

[Vijay Nayar]

On Saturday, 13 October 2018 at 19:04:48 UTC, Jabari Zakiya wrote:
> 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.

Updated:  
https://gist.github.com/vnayar/79e2d0a9850833b8859dd9f08997b4d7

I still get a few runtime errors likely from mistakes in my 
conversion for certain primes.  I'll resolve those after I get 
back from the gym.

But as previous posters have said, the code is not really very 
different between Nim and D.  Most of it is array manipulation 
and arithmetic operations, and not many of the features of either 
D or Nim are very different.  Both turn into fast code, both have 
garbage collection, and both have generally similar operators and 
libraries for this kind of problem.

The biggest differences I observed revolved not around the 
languages themselves, but around code style.  For example, can 
you put a loop and 3 additional statements on a single line in D? 
  Yes.  But it is considered to be not very readable code from a 
style perspective.

Once I get the bugs out, I'm curious to see if any performance 
differences crop up.  There's the theory that says they should be 
the same, and then there's the practice.