FP64 trial run, anyone?

[Napoleon]

I'm wondering if it might be worthwhile to start two trial projects side-by-side, FP32 vs FP64 once again?

[Joe_H]

What exactly are you proposing? The tests of extended precision calculations done years ago showed that the extra precision was not needed, and caused much longer run times. This might be better asked of the PG on the reddit.

[toTOW]

And with the current orientation of GPU manufacturers, DP performance is being left behind to save power ... so it wouldn't be wise move to start using DP again.

[Napoleon]

Definitely not for GPUs. However, previous FP64 core was 0x79 - that was a long time ago. I was actually wondering if AVX could boost FP64 performance so much that it would be about as fast as current SSE2 implementations with FP32? PG is cooking AVX versions of cores, thus increasing the number of core versions they need to support and test anyway. Maybe AVX with FP64 wouldn't be an entirely unreasonable addition.

Anyway, Joe_H reminded me that this isn't the best place for such discussion... presuming there's any need to continue the discussion.

[bruce]

FP64 always involves moving more data and using other resources than FP32. The key, here is that additional resolution that FP64 might provide does not add useful scientific information, so why consider using it? If I want to predict the tides, knowing the distance to the moon within 1 km is good enough and knowing it within a fraction of a mm adds no useful information ... especially if it takes the computer longer to determine that number but even if it just generates more heat.

[boristsybin]

Hi everyone!
two months ago i own couple of FirePro W8100 (Tonga-chip). Tested one with f@h and get ~150k points at 800 GHz chip and 1250 Ghz memory. Are that point numbers ok? Are there any fp64 projects in f@h? couse w8100 is ~1,9 GFlops in fp64 and should be good for that kind of projects

[bruce]

At the time that Core 0x79 was cloned from 0x78 and recompiled using FP64, it was an either/or proposition. By setting a simple compiler option, FP32 could be compiled using FP64 instructions. The conclusion were as stated above: Costly to (heat/speed) / performance with no improvement in science. That same choice can easily be made available today and I have little doubt the conclusion would be the same, whether we're talking x86 hardware, AVX hardware, or GPU hardware -- though that has not been tested publicly. The only real hardware requirement is that the FP64 operations be supported, whether by semi-dedicated hardware or by some kind of emulation. (And it should be obvious that emulation will be more costly that discrete circuitry.)

What's different, though, is that there have been improvements to the GROMACS/OpenMM code since the proposition was tested. FAHCores now use what's called MIXED precision. The bulk of operations are carried out using FP32 operations while designated portions of the code use FH64 instructions. This allows the code to provide FP64 precision when it's needed while avoiding wasting resources where the added precision is unnecessary. (This does limit project assignments for some of the oldest of GPUs.)

The basic assumptions underlying the original question that FAH has to make a choice between FP32 and FP64 make the question no longer applicable.