NVIDIA Quadro M6000 12GB Maxwell Workstation Graphics Tested Showing Solid Gains

MojoKid writes: NVIDIA's Maxwell GPU architecture has has been well-received in the gaming world, thanks to cards like the GeForce GTX Titan X and the GeForce GTX 980. NVIDIA recently took time to bring that same Maxwell goodness over the workstation market as well and the result is the new Quadro M6000, NVIDIA's new highest-end workstation platform. Like the Titan X, the M6000 is based on the full-fat version of the Maxwell GPU, the G200. Also, like the GeForce GTX Titan X, the Quadro M6000 has 12GB of GDDR5, 3072 GPU cores, 192 texture units (TMUs), and 96 render outputs (ROPs). NVIDIA has said that the M6000 will beat out their previous gen Quadro K6000 in a significant way in pro workstation applications as well as GPGPU or rendering and encoding applications that can be GPU-accelerated. One thing that's changed with the launch of the M6000 is that AMD no longer trades shots with NVIDIA for the top pro graphics performance spot. Last time around, there were some benchmarks that still favored team red. Now, the NVIDIA Quadro M6000 puts up pretty much a clean sweep.

Comments

No use

[maestroX]

Doesn't even have a D-sub connector!

Re:No use

[maestroX]

How did you manage a score of two?

I created an account over 10-15 years ago, treated it with utmost care and love, only now and then jesting, but very cautiously and carefully.
With the occasional post, my precious karma went silently up and up, and up and up.
Until today, I felt the longing for OMG frist post, succumbed and finally blew it all on an Nvidia topic.

Perhaps on topic, what useful task would this card capabilities be insufficient for? (useful in the sense with video output)

Too bad

[Anonymous Coward]

its too bad there is no double precision performance to speak of on these newer cards lately. good for games, not much else.

Re:Too bad

[sexconker]

nVidia doesn't care about double precision. The benchmark suites don't, either.

But researchers do, and that (and price/performance) makes them go AMD.

Re:Too bad

[Anonymous Coward]

If your algorithm is unstable at single precision floating point, it's going to be unstable at double precision as well.

Do you even know what you're talking about? error propagation, does that ring a bell? I'll give you a hint, if your computation requires a large number of operations then the absolute magnitude of machine rounding errors is critical. And, lest you think this is a 'very small niche', any matrix multiplication has O(n) operation per element. Chain a few those (say, in a Markov chain type of random walk) and it's an exponential growth. Using double instead of single is like being able to do periodic (expensive) full recomputations to control stability of a fast-updating chain instead of barely having enough precision when doing the full recomputations. Fast and stable versus extremely slow and perhaps (depending on today's $DEITY's mood) barely stable.

To put it differently, by the time error accumulation in double precision leaves you with a single-precision-worth of valid digits, single precision error accumulation has long ago made the computed value completely meaningless.

Re:Too bad

[Anonymous Coward]

Yea, they do go Nvidia is the unfortunate reality but it's somewhat understood if you look at all the extra capabilities Nvidia's architecture exposes - this becomes clear once you've really soaked in on AMD and OpenCL. Also AMD flubbed up on double precision after the 7990s. No one gives a crap about double precision for the foreseeable future except all the researchers and engineers programming the darn things. Haha. Wait, why is no one laughing?

Re:Too bad

[rgbatduke]

To paraphrase, you can't be too rich, too thin, or have too many bits of precision in a calculation. With single precision you have to be enormously careful not to drop digits even in comparatively modest loops; with double precision you can many digits before you run out. You can see it in almost any computations involving trig and pi -- single precision pi degrades in series much faster than double precision pi. It isn't just a matter of not using forward recursion to evaluate bessel functions, which is unstable in any precision (or for that matter, using book definitions of e.g. spherical bessel functions in terms of trig functions) or reordering series to avoid subtracting big numbers and running small to big instead of big to small -- there is simply a big difference between cumulating a random walk with a random digit at the 16th place and one at the 8th place.

A second problem is the exponent. 10^38 just isn't "big" in a modern large scale computation. It is easy to overflow or underflow a single precision computation. 10^308 is a whole lot closer to big, even expressed in decibels. One can concentrate a lot more on writing simple code, and a lot less on handling exponent problems as they emerge.

A final problem is random numbers. This is actually a rather big problem, as lots of code (all Monte Carlo, for example) relies on a stream of algorithmically random numbers that (for example) do not have a period less than the duration of the computation and that do not have significant bunching on low dimensional hyperplanes or other occult correlations. It is much more difficult to build a good random number generator on fewer bits, because the periods of the discretized iterated maps scale (badly) with reduced numbers of bits and it is more difficult to find acceptable moduli for various classes of generators from the significantly smaller discretized space. You can watch this problem emerge quite trivially by building a Mandelbrot set generator in float and rubberbanding in -- oops, you hit bottom rather quickly! Rebuild it in double and you at least have to work to rubberband in to where it all goes flat. You have to build it in a dynamically rescaleable precision to rubberband in "indefinitely" as the details you wish to resolve eventually become smaller than any given finite precision. This actually illustrates the overall problem with single precision quite nicely -- the emergent flat patches in an graphical representation of an iterated map are isomorphic to the establishment of unintended correlations in long runs of iterated maps in a random number generator and the clipping of the graphical representation of small numbers illustrates the problems with mere underflow in real computations of interest.

Personally, I dream of default quad precision and 128 bit processors. 34 decimal digits of precision means that a random walk with n unit steps (which accumulates like \sqrt{n}) require (10^30)^2 = 10^60 steps to get to where I don't still have 4 significant digits. Even a rather large cluster running a rather long time would have a hard time generating 10^60 add operations. In contrast, with only (say) 8 decimal digits a mere 10^16 operations leaves you with no digits at all, assuming you haven't overflowed already. I've run computations with a lot more than this number of operations. I also like the idea of having overflow around 10^5000. It takes quite a while adding numbers at the overflow of double precision to hit overflow, and one basically could add overflow scale single precision floats forever and never reach it. That gives me comfort. It would also make writing a Mandelbrot set explorer tool where one would be likely to give up before rubber banding all the way to the "bottom" -- there are a whole lot of halvings of scale in there to play with that still leave you with much more resolution than needed on the screen.

rgb

Re:Too bad

[mrchaotica]

With single precision you have to be enormously careful not to drop digits even in comparatively modest loops; with double precision you can many digits before you run out.

Ha! I see what you did there. Unfortunately, your verb wasn't double-precision.

Shouldn't Slashdot put up a

[wiredog]

"Sponsored Content" banner at the top of this post?

Re:12GB for?

[Smidge204]

High end 3D CAD packages can benefit greatly from accelerated graphics processing, and having gobs of memory on the video card can help store all that data.

Alternatively; imagine you work for Pixar.
=Smidge=