rbergen
commented
1 year ago @GordonBGood Thank you for contributing this. On a personal note I'd like to say that it's nice to see another PR from you after such an extended period of time.
LGTM!
Closed GordonBGood closed 1 year ago
rbergen
commented
1 year ago @GordonBGood Thank you for contributing this. On a personal note I'd like to say that it's nice to see another PR from you after such an extended period of time.
LGTM!
GordonBGood
commented
1 year ago @rbergen, thanks for your welcome back.
There will be a few more PR's from me in response to Dave's review of "the five fastest languages" using the multi-threaded leaderboard in spite of that adding parallelism breaks the Parallelism "green badge" and therefore was assumed by most, including me, to not be the main leaderboard.
He also seems to have missed that for intense CPU-bound benchmarks such as this, that the "per thread" metric is flawed when using Hyper Threading/Simultaneous Multi Threading threads in that using them does increase the total amount of work done but reduces the amount done per thread by almost half, leaving room to play games with the number of threads run; the multi-threading rules should likely have specified a particular number of threads to run such as four or that multi-threading should be run on either all logical or physical threads of a given test CPU if this was to be the basis of selection of the fastest language.
Unfortunately, not all languages (such as currently Crystal) have a Parallelism model; of the ones that do, I think you'll find that the language implementation rankings for multi-threading will be identical to as run single-threaded when run on the same number of threads for each test CPU. Thus, comparing multi-threading results just adds some effort and variables without really adding anything to the benchmark while eliminating some languages that don't have a Parallelism Model or for which multi-threading was not implemented as it didn't appear to be a requirement.
Best regards, Gordon
On Mon, May 8, 2023, 06:59 Rutger van Bergen @.***> wrote:
@GordonBGood https://github.com/GordonBGood Thank you for contributing this. On a personal note I'd like to say that it's nice to see another PR from you after such an extended period of time.
LGTM!
— Reply to this email directly, view it on GitHub https://github.com/PlummersSoftwareLLC/Primes/pull/919#issuecomment-1537573327, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACRTMTPUEWDKX3QFVR4MRWTXFAZNJANCNFSM6AAAAAAXXARIJU . You are receiving this because you were mentioned.Message ID: @.***>
rbergen
commented
1 year ago @GordonBGood I don't think Dave's recent episode with the comparison of the top 5 "multi-threaded" languages/solutions should be considered the be all and end all when it comes to what is the "main" leaderboard. Within the boundaries of this project, the main leaderboard actually still is the single-threaded one; specifically the faithful implementations of the base algorithm using one bit per prime, as we have discussed to some extent in the past.
Dave's YouTube channel started this project and he occasionally makes episodes about it, but at a project level he also did "hand over the keys" shortly after it started; he literally mentioned this in one of the (earlier) episodes on Primes.
I think that in this specific case, the episode('s focus) should also be viewed in the context of the episode that followed it. That being the one comparing the performance of the CPU to a GPU - which is a game of massive parallelization by definition.
All that said, it will certainly be nice to add some new implementations of your making!
Best regards, Rutger
GordonBGood
commented
1 year ago @rbergen:
I'm glad you enjoy my contributions to this primes project but there won't be anything amazing in these latest changes: adding multi-threading outputs to a few of the fastest implementations only requiring some quite minor refactoring. My main aim here is to be sure that at least the top five fastest languages retain their ranking for the multi-threaded leaderboard as for the single-threaded leaderboard as they should.
I could tweak the build processes and implementations to slightly improve the performance which might end up slightly changing the rankings such as putting the fastest Nim slightly ahead or at the same level as Mike Barber's fastest Rust implementation by using Clang and LLVM as a back-end target but don't regard a gain of a few percent significant enough to expend the effort. Similarly, the minor difference in performance between Rust and Zig in their top implementations doesn't mean much. Even the few percent slowness of Haskell as compared to these three is only due to it not auto optimizing vectorization of SIMD AVX vectors and Chapel and Vlang are only limited due to lack of macros and that the current template facilities implemented only do dense vector culling up to 63 rather than 129 for the top languages. These slight differences in performance would be even less in a real prime sieving application that sieved to more meaningful limits of billions or ten or hundreds of billions instead of the trivial limit of a million.
Any of the five to seven top fastest languages are fast; in real work the reasons for chosing any of these fastest over the other wouldn't be speed but rather other reasons such as stability, support, infrastructure, etc.
My personal preference is for functional programming, but while I enjoy programming in F# and Haskell, I don't regard either as my ultimate language, which functional language hasn't been introduced yet. Syntax-wise it would be somewhere between Haskell and F# like Elm, which is easy enough for 12-year-olds to learn as their first language, but would be strict with optional laziness like F#; its standard library would have a built in Actor-type parallelism model, it would use C as a back-end so could output JavaScript and WebAssembly as well as native code, and it's runtime would automatically support MUV interfaces to handle effects so a multitude of GUI's through WebView could be supported (as is the aim of DotNet MAUI for mobile); it would also likely support monadic chain (even if not named as such in the language documentation) mutation of at least array contents for "safe" control of mutation side effects and would have a form of non-GC "automatic" memory management based at least partly on compiler data flow graph analysis. In short, this would be a functional language that is disconnected from many of the things associated with "traditional" functional languages such a as GC memory management, etc.
Still looking for it/working on it ;-)
Best regards, Gordon
On Mon, May 8, 2023, 14:31 Rutger van Bergen @.***> wrote:
@GordonBGood https://github.com/GordonBGood I don't think Dave's recent episode with the comparison of the top 5 "multi-threaded" languages/solutions should be considered the be all and end all when it comes to what is the "main" leaderboard. Within the boundaries of this project, the main leaderboard actually still is the single-threaded one; specifically the faithful implementations of the base algorithm using one bit per prime, as we have discussed to some extent in the past.
Dave's YouTube channel started this project and he occasionally makes episodes about it, but at a project level he also did "hand over the keys" shortly after it started; he literally mentioned this in one of the (earlier) episodes on Primes.
I think that in this specific case, the episode('s focus) should also be viewed in the context of the episode that followed it. That being the one comparing the performance of the CPU to a GPU - which is a game of massive parallelization by definition.
All that said, it will certainly be nice to add some new implementations of your making!
Best regards, Rutger
— Reply to this email directly, view it on GitHub https://github.com/PlummersSoftwareLLC/Primes/pull/919#issuecomment-1537891329, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACRTMTLVP7LAN6IGJUIF4SLXFCON7ANCNFSM6AAAAAAXXARIJU . You are receiving this because you were mentioned.Message ID: @.***>
Description
Add Multi-Threading to the Haskell Solution 2 techniques...
Contributing requirements
drag-raceas the target branch.