@mratsim Julia had some problems last time I check 2 years ago because I was
frustrated with R, but now the standard library is pretty stable and there are
some really cool Deep learning libraries (Knet for example, completely hackable
because everything is Julia code). Good interface with
@jzakiya
> (and Julia is written in Python)
No.
Actually, Julia's main advantage isn't pure performance. It's easy of usage.
Please notice Julia is NOT a true HPC language as the only type of parallelism
it provides is master-slave (as far as I know) which isn't even common in HPC.
However, it's handy to be able to use Python, C and Fortran
Hey SolitudeSF thanks for the tip.
Hey Miran, this is `Open Source Software` so you can modify it as much as you
want. I think all you have to do is comment out the line that puts out the
enter number message to get what you want.
But as I said in the initial post, people should feel free to
Thanks @SolitudeSF!
Here are my results for i7-970 hexa-core @ 3.2 GHz. Nim 0.18.1 (devel), GCC
7.3.1, Linux kernel 4.9
10_000_000_000 0.544 secs
50_000_000_000 2.954 secs
100_000_000_000 5.513 secs
500_000_000_000 73.863 secs
1_000_000_000_000
> I was hoping a few people would be curious enough to run the code and post
> (or send me via email) their results on their systems
Is there a way to easily automate this?
I have tried to call it with `./twinprimes_ssoz 100`, but I still have to
enter manually the wanted number in the
`UPDATE`, caught, and corrected, a subtle coding error that affected the total
twinprimes count being possibly off by 1 (and wrong last twinprime value) when
the Kmax residues groups for an input is (very rarely) an exact multiple of the
segment size. If anybody is running code please use
`UPDATE`, mostly more tweaking of `proc twins_sieve`. Tried different loop
structures|idioms to see what would be faster (`for` vs `while` loops mostly,
etc). Made some cosmetic, line order changes. Code `version 2108/04/05` more
compact, a little more cleaner, with little more clearer comments
Hey @miran, thanks. I'll look at your code when I get some time today.
It would be really helpful if people could run the code on different (Intel
cpus, AMD, ARM, etc) platforms with different number of threads, cache size,
etc, and if possible a|b it against `primesieve` on their systems, and
> But I encourage, implore, welcome, people to beat on the code to improve it
> and make it faster. What idioms are faster than the ones I used, etc.
Here is [my
gist](https://gist.github.com/narimiran/f9c1df45036cff34a725baad2e89af44) \- I
took your improved version, went quickly through it,
> show that Nim can be a player in the numerical analysis arena, particularly
> for parallel algorithms
IMO, it would be nice if you would convert this to a blog post, which could be
shared on Reddit/HN/etc.
Maybe something similar to this:
`New and Improved` (current) version, with significantly reduced memory
footprint as numbers get larger.
Now I create|initialize `nextp` arrays of 1st prime multiples in each thread,
which gets gc'd (garbage collected) at end of thread, thus using a much lower
constant runtime memory. (I could
Congrats, that's really an achievement !
OpenMP is easy, you can use it like this, the following defines a new -d:openmp
compilation flag:
when defined(openmp):
{.passC: "-fopenmp".}
{.passL: "-fopenmp".}
# Note: compile with stacktraces off or put
# when
It's been a long and interesting journey, but I've finally gotten this to a
point where I feel I can release it.
This is a `twinprimes` generator, that I did an initial version of back in
2014|5 in C++. Over time, I did a C++ parallel version using OpenMP. Then a few
months ago, at the
14 matches
Mail list logo
