Boost.SIMD library looks very promising!
I would expect that within a few years, SIMD instruction sets continue to
become
more regular and useful, and that tools like Boost.SIMD will become more
widely
available and useful...and who knows, maybe even a part of C++...
So I'd rather wait until that
On 5 October 2015 at 13:13, Victor Shoup wrote:
>
> I hesitate somewhat to get involved in SIMD game, as all the assembly code
> / intrinsics stuff is a huge time sink that
> will yield code that will probably be obsolete in 10 years. Multicore, on
> the other hand, seems like a better
> investme
I think I see how the fake bouncing works. Someone has either subscribed to
sage-devel so they can send fake bounces to everyone, or they are scraping
the information from one of the many locations on the web where sage-devel
is reproduced and using that to generate a fake bounce. To what end I
I think I see how the fake bouncing works. Someone has either subscribed to
sage-devel so they can send fake bounces to everyone, or they are scraping
the information from one of the many locations on the web where sage-devel
is reproduced and using that to generate a fake bounce. To what end I
Actually, I'll correct myself: SIMD can also be used to speed up the CRT
operations in the
multi-modular algorithm as well, at least up to a few thousand bits. So
even in the grand and glorious
SIMD future, there will probably be room to explore a variety of
algorithmic approaches.
On Monday,
Yes, I saw a paper by the mathemagix people recently...I believe they use
the floating point SIMD, and some
tricks with "fused multiply and add" to very nice effect.
They are basically implementing integer mod p arithmetic using floating
point.
I may want to play around with those ideas at som
Every time I post to this thread I get a fake bounce from anjeri2010.jobbo
AT blogger DOT com .
Does anyone know why this happens?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it,
I haven't looked recently, but Prime95 always used to suffer from
theoretical roundoff error. They go along later with a slower FFT to verify
everything.
It's been a long time since I looked though. Things might have changed.
Bill.
On Monday, 5 October 2015 11:26:14 UTC+2, Jean-Pierre Flori wr
On Monday, 5 October 2015 04:18:27 UTC+2, Victor Shoup wrote:
>
> Thanks for the feedback, Bill! A bit of friendly competition is always a
> good thing :-)
>
I agree. Software development is more interesting when there are people
working on similar things.
>
> I've been looking into SIMD f
Hi all,
On Monday, October 5, 2015 at 4:18:27 AM UTC+2, Victor Shoup wrote:
>
> Thanks for the feedback, Bill! A bit of friendly competition is always a
> good thing :-)
>
> I've been looking into SIMD for small prime FFT's...unfortunately, there
> is currently
> no CPU out there that supports
Thanks for the feedback, Bill! A bit of friendly competition is always a
good thing :-)
I've been looking into SIMD for small prime FFT's...unfortunately, there is
currently
no CPU out there that supports SIMD 64x64 -> high order 64 bits of product.
So, it does not look very promising.
In a cou
In particular it really looks like we should study the factorisation
algorithms in NTL, since the performance you have there seems unlikely to
be explained by mere arithmetic performance. We are likely missing a number
of tricks.
Bill.
On Monday, 5 October 2015 02:06:26 UTC+2, Bill Hart wrote:
This is really nice Victor. Thanks for sharing these benchmarks!
There are two things we really need to do in Flint fairly soon: 1) make
better use of SIMD (e.g. small primes FFT is now probably competitive with
our Schoenhage-Strassen FFT) and 2) make use of threading.
Flint is actually starti
13 matches
Mail list logo
