Shouldn't parallellization measure how fast the sieve is made by the parallellism?

[PEZ]

I note that some solutions achieve massive amounts of passes, especially on Dave's 32 core machine, by simply running the sieve function in many threads. This does not strike me as measuring the right thing. Let me contrast it like so:

1. Make the sieve function faster by utilizing parallellism/threads
2. Run the sieve functions more times by giving it to several threads at once

Here I find 1 being super interesting, and 2... well not so interesting.

What's the intention with having the multithreaded category in the benchmark?

[rbergen]

To start with answering your question:

What's the intention with having the multithreaded category in the benchmark?

In actual fact, it was primarily created to allow for a clean comparison of the single-threaded implementations, which is the core set.

Concerning your discussion of 1 and 2 I understand your perspective, but I don't fully agree. I think 2 can in fact be quite interesting when comparing the number of iterations per second per thread with that of a single-threaded implementation. That does say something about a languages's/runtime's overhead when using and managing multiple threads.

[PEZ]

Thanks for clarifying. And for highlighting the value of 2. That makes sense.

But I still would like to see how fast a sieve can be made in the different languages. Like Dave reasoned in one of the videos, the algorithm can't be easily parallelized, but certain steps in it can.

[Mooshua]

You can’t really “multithread” prime sieving all that well, what’s most effective is running the prime sieve independently on multiple threads.

Rewarding sieve developers for running the same sieve on as many threads as possible seems like a poor decision, especially when the benchmarks are about what’s capable in the language & compiler.

[enki42]

I partially agree but also feel like different languages handle threading in more and less efficient ways. Seems like there should be a single threaded and multithreaded comparison though to compare like to like

[rbergen]

I think that if you look at the benchmark runs in PrimeView, you'll find that there are filter presets defined that allow you to select only the single-threaded solutions on the one hand, and only the multi-threaded solutions on the other.

As the filters are completely configurable (and new named filters can be saved), one can effectively choose their individual pair of glasses they want to look through to compare the benchmark results that are available.

[enki42]

That works. So guess my thoughts are more about how someone should interpret the results. (A solution that is a single thread could still be thought of as fast if you want to see how fast a language can be)

[rbergen]

The single-threaded implementations are the actual main benchmark for comparing languages in the context of this repo. For one, there are far more single-threaded implementations (heaps of languages don't even offer built-in support for multithreading). Also, there are many discussions that can be had about solutions using multiple threads, like the validity of comparisons between different multithreading approaches, including if the approach must "multithreaded" solutions take isn't really more a form of multiprocessing.

As maintainers we decided to flatten the whole discussion by ranking solutions by the number of iterations executed per second per CPU (core) used, and leaving it up to the solution developers to get the most out of their language of choice within the boundaries of the rules. Not very surprisingly, when all is said and done the single-threaded implementations tend to be ranked higher than their multithreaded counterparts because the former don't suffer from the overhead that is basically inevitably introduced with the management of multiple threads.

[Ultimusprime]

i have write code for sieving using parallellism (1.0 e + 10) sieving in 0.90 sec and generate in a list in 30 sec. is that good?