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.
