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