NVIDIA To Push Into Supercomputing

RedEaredSlider writes "NVIDIA outlined a plan to become 'the computing company,' moving well beyond its traditional focus on graphics and into high-profile areas such as supercomputing. NVIDIA is making heavy investments in several fields. Its Tegra product will be featured in several mobile devices, including a number of tablets that have either hit the market already or are planned for release this year. Its GeForce lineup is gaming-focused while Quadro is all about computer-aided design workstations. The Tesla product line is at the center of NVIDIA's supercomputing push."

Comments

more nukes :/

[magarity]

I just hope enough nuclear power plants come online before their first supercomputer customer turns on a new rig. The latest GPUs already use more power than the hungriest Intel or AMD x86 ever did.

Re:more nukes :/

[MightyYar]

The latest GPUs already use more power than the hungriest Intel or AMD x86 ever did.

And when used for the types tasks designed, pump out 10x the performance for maybe twice or three times the power.

Re:more nukes :/

[gupg]

5 of Top 10 most green supercomputers use GPUs:
Green 500 List

Each GPU is very high performance and so high power. Performance / watt is what counts and
here GPUs beat CPUs by 4 to 5 times. This is why so many of the new supercomputers are using
GPUs / heterogenous computing.

Re:more nukes :/

[Antisyzygy]

Actually, up to 40 times the performance. http://www.gp-you.org/index.php?option=com_content&view=article&id=46:art-gpumat&catid=40:cat-gpumat&Itemid=54

Re:more nukes :/

[TheRaven64]

If all you're measuring is pure FLOPS, then here are some numbers: Cray X1, 250MFLOPS. nVidia Fermi: 1GFLOPS. ARM Cortex A8: 10MFLOPS. Of course, that doesn't tell the whole story. Getting 250MFLOPS out of the Cray required writing everything using huge vectors. Getting 1GFLOPS from Fermi requires using vectors within independent concurrent processing tasks which access memory in a predictable pattern and rarely branch.

GPUs are not magic, they are just optimised for different workloads. CPUs are designed to work well with algorithms that branch frequently (every 7 instructions or so - so they devote a lot of die area to branch prediction), have good locality of reference (cache speeds up memory in these cases), and have an integer-heavy workload. GPUs generally lack branch prediction, so a branch causes a pipeline stall (and, on something like Fermi, if two kernels take different branches then you drop to 50% throughput immediately). Their memory architecture is designed to stream large blocks of data in a few different orders (e.g. a texture cube, pixels in order along any axis). So, depending on your workload, either one may be faster than the other.

SGI

[0racle]

version 2

Re:Fuck you moderators

[moderators]

Look, I apologize if I offended you in any way, ok? There's no need for such languages.

Re:Fuck you moderators

[drinkypoo]

I can NOT fucking believe there was not already a troll account called moderators long, long, LONG before UID 2M.

Re:Yet another reason to begrudge nVidia

[0racle]

nVidia shuns linux users? They may 'shun' those that can not have any non-GPL code, but they do make a higher performing and far more feature rich driver for their cards for Linux, FreeBSD and Solaris and keep it (for the most part) up to date. If you don't like it, there are alternatives.

Gotta love the rabid GPL fans. The GPL doesn't mean freedom for everyone to do things the way you think they should be done.

eh..

[Anonymous Coward]

I've been working with their GPGPU push for a couple of years now. What I notice is they are very good at data parallelism with highly regular data access patterns and very few branches. While they are technically general purpose, they don't perform well on a large portion of high performance tasks that are critical even in scientific computing which are generally compute-bound. This creates some really annoying bottlenecks that simply cannot be resolved. They can give tremendous speedup to a very limited subset of HPC tasks, but others are left in the water, and since these things usually are all coupled into a single code your only choice is to move back and forth between GPU and CPU frequently which initiates a data throughput bottleneck (data transfer from RAM to GPU is very slow).

On real tasks it is not uncommon to only receive say 2X speedup, where the programmer time involved was increase exponentially. For a lot of my work I'd rather to just do traditional MPI with multiple CPUs.

Re:NVIDIA? please AMD

[tyrione]

You're out of date. Even Nvidia knows OpenCL will replace CUDA. At least AMD is more open about it and pushing it hard with their OpenCL 1.1 release in their 2.x SDK.

short little span of attention

[epine]

If we all buy AMD's product on the virtue of their openness, it won't be long before AMD holds the upper hand on features and stability. I think they're heading in a good direction already.

How much entrenched advantage does inferior need before you lock in? Your personal FIR filter on "what have you done for me lately" seems to have unit delay of hours rather than years.