The prime-crunching on dedicated hardware FAQ

[xilman]

Originally Posted by jasong

As to the hardware crash, one of the problems with RAID arrays is that everything tends to be backed up in the same location. So things like ceiling leaks and fallen over shelves have the potential to destroy enough hard drives in a RAID array to make them unrecoverable.

With respect, anyone running a serious operation knows that putting data on a RAID array is not a good backup strategy.

Data loss can occur not only through damage to hardware which, as you describe, can take out an entire array. Data can also be corrupted by finger-trouble, by errant programs, by broken hardware elsewhere in the system and by enemy action. RAID will not protect your data from any of those.

I know of what I speak. 18 months ago we were unlucky enough to have one disk in an array fail hard and the buggy RAID controller then corrupted one of the remaining set. We were out of action for a couple of days while Dell ran diags and shipped us a new disk and RAID controller. Restoring the data from tapes took one of the two days. The backup tapes were brought in from an off-site store. This precaution guards against events that take out our entire facility. Replacing hardware is cheap and easy. Restoring data accumulated over 15 years of operation is hard and expensive in the absence of adequate backups.

Sadly, all too many people don't think about instigating a proper backup mechanism until they've learned the hard way.


Paul

[Jeff Gilchrist]

Originally Posted by xilman

Sadly, all too many people don't think about instigating a proper backup mechanism until they've learned the hard way.

And now there are even inexpensive ways to get off-site backups, especially for home users via services such as MozyBackup and many others that give you unlimited data, encryption, and even file versioning. So there really aren't any excuses left (except lazyiness I guess).

[jrk]

Originally Posted by jasonp

Almost all special purpose hardware does not implement double precision, and so there is no possibility to achieve the aforementioned enormous performance.

I really hate to ask this now, because I can already guess the answer, but I read this on the tech specs page about the NVidia 8800 family of GPUs:

Originally Posted by http://www.nvidia.com/page/8800_tech_specs.html

Full 128-bit floating point precision through the entire rendering pipeline

I don't suppose this actually means you could do double precision float computations, it is more likely a clever marketing lie, right?

Thanks.

[jasonp]

Originally Posted by jrk

I don't suppose this actually means you could do double precision float computations, it is more likely a clever marketing lie, right?

I looked around the page, and without reading actual technical documents on that card the most you can conclude is that the datapath to the execution units is 128 bits wide. Most likely this means 4 x 32-bit single-precision floating point, with a possibility of much slower 2 x 64-bit double precision.

When we start seeing graphics applications that demand 64-bit precision, then we'll start seeing cards that trumpet this as a feature. I can't imagine an app that needs that and is purely graphical and has mass appeal.

[retina]

If we take the quote "Full 128-bit floating point precision" at face value we would have to assume that the precision is the mantissa. Then when we add the exponent and sign bit, that would suggest ~ 18 byte data format. It doesn't seem very likely.

[fivemack]

Originally Posted by jrk

I really hate to ask this now, because I can already guess the answer, but I read this on the tech specs page about the NVidia 8800 family of GPUs:

I don't suppose this actually means you could do double precision float computations, it is more likely a clever marketing lie, right?

You can do double-precision FP with CUDA on the GT200 family; see http://www.mathematik.tu-dortmund.de...dprecision.pdf and http://www.mathematik.tu-dortmund.de...ION08-long.pdf

They're working on partial differential equations, and a year or so ago published a paper where they did some number of iterations in single-precision on the GPU then copied across to the CPU and 'polished' the result in double-precision. The current paper does the polishing on the GPU too.

http://www.theinquirer.net/gb/inquir...dra-2009-sizes has benchmark results from Sandra 2009, which includes basic Mandelbrot in SP and DP; I suspect that the 'float performance' and 'double performance' axes are the wrong way round in the graphs presented.

http://forums.nvidia.com/index.php?s...483&hl=fourier indicates that 32-bit integer performance is already quite interesting ... they're done some large searches for sets of bases with large smallest pseudoprime using a GPU implementation of a^b%p on 64-bit p.

[Tumo]

Hi,
First, thank you all for the great info... it's more than I can swallow. Perhaps some day.

I do have a question....

GPU's which use 16 bit pipes, say my nvidia 6600, do a great job in spite of its age. I have been told it's because of the depth and because of the number of parallel 16 bit internal registers. I know the 8800's and (I hear) soon 9xxx cards are going to be WILD! I do hope to upgrade and tag along.

Reading the '128 bit vs 2 x 64 vs 4 x 32' discussion portion made me wonder. I heard one of the cards has 9 x 16 internal (registers or paths). If so, can that be of any help...

Would someone please explain? I'm wondering because we all talk about the primality tests, but what about the sieve/factoring portion? Can that be put in the card as well and would it help ?

With thanks and thanks in advance,
Ty

[jrk]

Thank you for the insights, jasonp and retina & fivemack.

[RMAC9.5]

Ernst,
Here is an article which may interest you http://it.tmcnet.com/news/2008/11/18/3796116.htm.
I got it from a posting on aceshardware.freeforums.org.

[jasong]

must use fast Fourier transforms (FFTs) implemented in double precision (DP) floating point.

This is wrong. I don't say this because I'm an expert, I'm not. I say this because the person programming the GPU prime-finding algorithm told me this isn't true. He is programming the GPU to work with integers

Now, of course, you'll ask,"Jason, if you don't understand the math, then how the hell do you know he isn't BSing you?" Simple, he's done major things in the prime-finding community in the past, and I'm simply going by his reputation.

[cheesehead]

Originally Posted by jasonp

The problem is that in order to have a chance of achieving that incredible performance, code must not use any feature of the special purpose processor that is not implemented in dedicated hardware. There are projects that can abide by this restriction (distributed.net, folding@home), but any project that works by multiplying large numbers (LLR, GIMPS) must use fast Fourier transforms (FFTs) implemented in double precision (DP) floating point.

Originally Posted by jasong

This is wrong. I don't say this because I'm an expert, I'm not. I say this because the person programming the GPU prime-finding algorithm told me this isn't true. He is programming the GPU to work with integers

As you correctly point out, the claim in post #1 that "... any project that works by multiplying large numbers (LLR, GIMPS) must use fast Fourier transforms (FFTs) implemented in double precision (DP) floating point" needs to be amended. It is, of course, quite possible to use integers entirely in the Fourier transforms. The statement as it stands is especially misleading in a FAQ about computations performed by hardware other than general-purpose CPUs.

I suggest a more-correct replacement:

"Projects that involve multiplying large numbers (LLR, GIMPS) take into account that the fastest methods for doing that use a type of mathematical operation known as a Fast Fourier Transform (FFT).

On recent Intel systems, or any others with a similar floating-point-vs-integer arithmetic performance ratio, the fastest way of implementing FFTs uses double-precision (DP) floating point.

It is quite possible to use single-precision floating point, or to use all-integer arithmetic, to implement FFTs, but on the most common current CPUs those methods will be significantly slower than using DP floating-point. Furthermore, single-precision floating-point becomes impractical to use at all for FFTs on numbers above a certain range, and that range is routinely exceeded by current LLR and GIMPS work.

However, the superiority of DP over single-precision, or of floating-point over integer arithmetic, for Intel-like CPUs may not be so true, or at least may not be a limiting consideration, for special-purpose dedicated hardware such as graphics cards."

I welcome anyone's correction or improvement of that suggestion.