Stafan_Salewski, yes, thanks for reminding about that again.
The twinprimes code is old (almost a year, using 0.17.x), when I was just
getting seriously into converting C++ code into Nim. Using the original
construct for that loop worked, because I always compiled with `gc` on. Then I
started p
jzakiya, you may wonder why your program eats that much memory.
I had just looked at you code, and tried this:
#for byt in seg[0..Kn-1]: # count the twin primes in the segment
# primecnt += uint(pbits[byt]) # count the '0' bit pairs as twin
primes
for jj i
Hello,
I tested your code on a similar configuration (Linux 64-bit i7-2675QM 2.20GHz).
With an input of 500 billions, the system had to make use of the swap and then
crashed.
Moreover for 50 billions, with `--gc:none`:
$ /usr/bin/time ./twinprimes_ssozp5a2a
Enter integer numb
@jzakiya what do you mean exactly with the word "process"? I do not see usage
of osproc module in your code...
Also, what is an input value for which you get that error?
> Turn of your OS's memory overcommitment.
I have no idea what this means. Giving an example would be helpful next time.
Unfortunately, 0.18.0 has some bigtime regressions. I compiled the same code in
0.17.2, and not only does it compile and run correctly for all input values,
the compiled bina
Turn of your OS's memory overcommitment.
> This seems like a clear compiler error.
On the contrary, it looks like a clear programming bug / OOM.
> I have no idea why it's doing that, or how to fix it.
A full example we can compile&run would be helpful.
So I'm compiling some new code in 0.18.0.
This code code compiles and runs correctly as one process with no problems.
proc segsieve(Kn: int) = # for Kn resgroups|bytes in segment
...
for indx in 0..5: # for nextp row indexes,
var r = i
