gmpbench -- how to utilize all CPU cores?

[.]

Thanks for infos.

I'm aware too of the amount of work and well-written code that you give
away for free because you want to, and I appreciate it. If you devs
think that parallelizing GMP-code using pthreads, ... is a proper way of
programming in GMP, then this is good and you don't need to re-write
anything in GMP.
Now at least some simple tutorials on gmplib.org would be good. gmpbench
is good for testing only one core, so sadly I'll have to use my own
simple pthreads benchmark for multi-core benchmarking then (and I can
tell you it doesn't scale linearly, but quite good) :-D

I use GMP but it's not fast enough if un-parallalized on certain
projects (waiting 12 days instead of 1 makes a difference), that is a
given. This has nothing to do with "serious" or "un-serious". Sometimes
just more speed is needed and "time is money" they say sometimes. If GMP
doesn't scale very well then people can't use is on certain projects.

Again, if it can and should be done with pthreads then I'm happy and
I'll shut up :)

Only parallelization will make GMP much faster now. I'll try pthreads
later.

On 29.09.2013 15:31, Torbjorn Granlund wrote:
> Among several similar statements, somebody wrote:
>
>   I agree with you. Someone skilled shall parallelize the code and at the
>   same time teach the people through the open source code how to properly
>   parallelize the code in GMP.
>   
> Requests for parallelisation of GMP are done again and again over the
> years.  It is not due to lack of unwillingness of us VOLUNTEERS which
> keeps GMP non-parallel.  Note that GMP is re-entrant, as described in
> the manual.
>
> Thanks to the latest flurry of messages, we know that "serious users"
> will never use GMP due to GMP's lack of internal parallelism.  Oh my,
> there are lot of un-serious users out there!
>
> I suggest that someone who expects a parallel GMP to be feasible start
> with some simple case of bignum arithmetic and parallelise it on (say) a
> 4-core x86-64 processor.  Please let me know when your parallel
> functions get less than 100x SLOWDOWN compared to GMP for operands which
> are of common sizes.
>
> Before you start, make sure you understand about caches, and cache
> concepts like false sharing, replacement, inter-cache bandwidth.  And
> please read up on parallelising and the significance of granularity.
> Without that knowledge, reaching a mere 100x slowdown might be too hard
> for you.
>
> If you want a deeper reasoning on the subject of parallelising GMP, I
> suggest that you search the gmp mailing list archives.
>
> PS. Please remember that GMP is a gift from us to you.  Complaining
> about it in an quite ignorant way, adding a degree of rudeness, might not
> trigger us to give you a better gift.
>
> Torbjörn
> _______________________________________________
> gmp-discuss mailing list
> gmp-discuss at gmplib.org
> https://gmplib.org/mailman/listinfo/gmp-discuss


-- 
OpenPGP key: https://keyserver2.pgp.com/vkd/DownloadKey.event?keyid=0xCDDFDD67A48E0139