I wonder if there is a single precision version LL-test for Nvidia GPU computing

[ewmayer]

Originally Posted by kriesel

Hmm, how about some quad precision implementation in the hardware?

Funny you mention that - way back when, around 20 years ago during the project's "GIMP-fancy", the first time I ever e-mailed George was to let him know I'd coded up a simple FFT/IBDWT LL-test program (back then in Fortran-90, as my original interest was in finding some non-boring way to motivate my teaching of the basics of the FFT to my undergraduate engineering students) on my DEC Alpha and that I was pretty excited about coding up a quad-prec. version using the xfloat 128-bit floating data type supported by Alpha. Alas it turned out that said support was only via software emulation, IIRC the only hardware of the era that had actual QP hardware support was the pre-commodity-CPU-based line of Cray supercomputers.

And we still face the same issue, so things boil down to how one can most effectively get "more bang per datum" on existing hardware. The major candidates are the "doubled double" approach, an NTT-based one, and a hybrid float+NTT. But I suggest we not hijack this thread to discuss those, as there are existing threads for each.

Getting back on-topic, I have my SP Mlucas hack mostly working, the FFT stuff seems to all work fine, but need to track down and fix some bugs with the float-ization of the carry-propagation code. Hard to find decently-long blocks of code/debug time due to the holidays and the attendant family outings and dinners and such.

[preda]

Originally Posted by ewmayer

Getting back on-topic, I have my SP Mlucas hack mostly working, the FFT stuff seems to all work fine, but need to track down and fix some bugs with the float-ization of the carry-propagation code. Hard to find decently-long blocks of code/debug time due to the holidays and the attendant family outings and dinners and such.

What is the bits/word that you observe as feasible with SP, and at what FFT size?

[kriesel]

Originally Posted by ewmayer

simple FFT/IBDWT

I think you contradict yourself. ;)

[ewmayer]

Originally Posted by preda

What is the bits/word that you observe as feasible with SP, and at what FFT size?

Won't know until I finish getting the SP code hackage debugged.

[chalsall]

Originally Posted by ewmayer

Won't know until I finish getting the SP code hackage debugged.

Any update? Perspiring minds want to know....

[kriesel]

Originally Posted by ewmayer

Getting back on-topic, I have my SP Mlucas hack mostly working, the FFT stuff seems to all work fine, but need to track down and fix some bugs with the float-ization of the carry-propagation code. Hard to find decently-long blocks of code/debug time due to the holidays and the attendant family outings and dinners and such.

Any further news?

Has Mlucas V19 development taken higher priority than this?

[ewmayer]

Originally Posted by kriesel

Any further news?

Has Mlucas V19 development taken higher priority than this?

Forgot to add note on result of my above quick-look experiment a few months ago ... got the SP Mlucas version building and debug showed what appeared to be correct data for the first few iterations. But as soon as the residue spilled over into the 2 SP word (and I verified that the carry and DWT weighting were correct), got instant fatal ROEs in the subsequent iteration's carry step. At the time I couldn't determine whether this was due to the SP FFT having far worse error behavior than my heuristics predict, or a bug in the SP cut-down that only appears once the residue vector starts filling up. Then the need to get v18 wrapped up and released intruded, and currently v19 (main newness = PRP testing support) is #1 priority. Sorry to leave the loose end dangling!

[ET_]

Originally Posted by ewmayer

currently v19 (main newness = PRP testing support) is #1 priority. Sorry to leave the loose end dangling!