Prime sieve language race
SealabJaster
sealabjaster at gmail.com
Tue Jul 13 21:02:55 UTC 2021
On Tuesday, 13 July 2021 at 19:06:12 UTC, Bastiaan Veelo wrote:
> 1. The output in the readme shows `Valid: false`, which worries
> me. I didn't try your solution myself yet.
Oop. So what happened there is, I updated the README while
`validateResults` was broken, and completely forgot to fix the
README after fixing `validateResults`.
I can assure you it shows `Valid: true` now!
> 2. Not sure if this was clearly stated in the rules, but he
> [says that the sieve size must be a run time
> value](https://youtu.be/Yl9OegOorYM?t=532). I hope this doesn't
> disqualify your solution.
oooh. It's easy to read over but it does seem to say that:
> The sieve size and corresponding prime candidate memory buffer
> (or language equivalent) are set/allocated dynamically at
> runtime. The size of the memory buffer must correspond to the
> size of the sieve.
It'll mean that the solution can't be marked as `faithful: yes`
anymore, I'll open a PR soon to make sure that's fixed.
Or maybe I'll update the code slightly to allow both a runtime
and compile-time set sieve size >:3
While the Sieve does do the computations at runtime, the sieve
size is a compile-time constant, and the buffer is static
(technically one could argue that it *is* dynamically allocated
due to being in a class >:D ).
> 3. Line 23 `// it also allows D to write more "file-portable"
> code.` Not sure what you mean by this. Worth noting however is
> that the import only happens iff the template is instantiated,
> which is nice.
Basically, if you use scoped imports it tends to be a lot easier
to move a piece of code between different files. A lot of the
time you can get away with a simple cut+paste and it can just
work.
Hence, portable across files.
> 4. Line 38: Did you mean to leave `(citation needed)` in there?
Perhaps ;)
> 5. `printResults` can be made `@safe` by means of a nested
> `@trusted` wrapper
> ([ref](https://forum.dlang.org/post/pvadtwqblgclttzesxeg@forum.dlang.org)):
> ```d
> // If not called from multiple threads, this can be trusted.
> static File trustedStderr() @trusted
> {
> return stderr;
> }
> ```
It really doesn't feel right to do that. I didn't use the
`@trusted lambda` hack for a reason.
> Out of curiosity, do you know how your solution compares with
> the first one performance wise, roughly?
[1] is for the first solution, and [2] is for the second one.
Because the second solution has some compile-time things going
on, it's doing a fair amount less work: not needing to allocate
the list of sieve sizes; `validateResults` not needing to do a
lookup; one less level of indirection because it uses a static
array; etc.
I also set some compiler flags in dub.sdl, which doesn't actually
seem to change solution_1 all that much if I apply the same flags
to it.
As I mentioned in the PR as well, LDC is capable of inlining
ranges, so even though this code is more idiomatic, it compiles
like it was written in a more traditional C style.
[1] https://pastebin.com/Q0UxibTi
[2] https://pastebin.com/tmXDwejS
More information about the Digitalmars-d
mailing list