The skeptics were right to question the huge improvements seen when using GPGPUs in a system for heavy parallel computing tasks. The cards do help a lot but the 100x improvements that have been reported by some companies and universities had more to do with poorly optimized CPU code than with the processing power of GPGPUs. This news comes from someone who you might not expect to burst this particular bubble, Sumit Gupta is the GM of NVIDIA's Tesla team and he might be trying to mitigate any possible disappointment from future customers which have optimized CPU coding and won't see the huge improvements seen by academics and other current customers. The Inquirer does point out a balancing benefit, it is obviously much easier to optimize code in CUDA, OpenCL and other GPGPU languages than it is to code for multicored CPUs.

"Both AMD and Nvidia have been using real-world code examples and projects to promote the performance of their respective GPGPU accelerators for years, but now it seems some of the eye popping figures including speed ups of 100x or 200x were not down to just the computing power of GPGPUs. Sumit Gupta, GM of Nvidia's Tesla business told The INQUIRER that such figures were generally down to starting with unoptimised CPU."

On Monday, AMD launched its latest graphics card aimed at the server and workstation market. Called the AMD FirePro S10000 (for clarity, that’s FirePro S10,000), it is a dual GPU Tahiti graphics card that offers up some impressive performance numbers.

No, unfortunately, this is not the (at this point) mythical dual-7970 AMD HD 7990 graphics card. Rather, the FirePro S10,000 is essentially two Radeon 7950 GPUs on a single PCB along with 6 GB of GDDR5 memory. Specifications on the card include 3,584 stream processors, a GPU clock speed of 825 MHz, and 6 GB GDDR5 with a total of 480 GB/s of memory bandwidth. That is 1,792 stream processors and 3 GB of memory per GPU. Interestingly, this is a dual slot card with an active cooler. At 375W, a passive cooler is just not possible in a form factor necessary to fit into a server rack. Therefore, AMD has equipped the FirePro S10,000 GPGPU card with a triple fan cooler reminiscant of the setup PowerColor uses on its custom (2x7970) Devil 13, but not as large. The FirePro card has three red fans (shrouded by a black cover) over a heatpipe and aluminum fin heatsink. The card does include display outputs for workstation uses including one DVI and four mini DisplayPort ports.

AMD is claiming 1.48 TFLOPS in double precision work and 5.91 TFLOPS in single precision workloads. Those are impressive numbers, and the card even manages to beat NVIDIA’s new Tesla K20X with big Kepler GK110 and the company’s dual GPU GK104 Tesla K10 by notable margins. Additionally, the new FirePro S10000 manages to beat its FirePro 9000 predecessor handily. The S9000 in comparison is rated at 0.806 TFLOPS for double precision calculations and 3.23 TFLOPS on single precision work. The S9000 is a single GPU card equivalent to the Radeon 7950 on the consumer side of things with 1,792 shader cores. AMD has essentially taken two S9000 cards and put them on a single PCB, and managed to get almost twice the potential performance without needing twice the power.

Efficiency and calculations per watt were numbers that AMD did not dive too much into, but the company did share that the new FirePro S10000 achieves 3.94 GLOPS/W. AMD compares this to NVIDIA’s dual GPU (Fermi-based) Tesla M2090 at 2.96 GFLOPS/W. Unfortunately, NVIDIA has not shared a single GPU GFLOPS/W rating on its new K20X cards.

AMD S10000

AMD S9000

NVIDIA K20X

NVIDIA K10

Double Precision

1.48 TF

0.806 TF

1.31 TF

0.19 TF

Single Precision

5.91 TF

3.23 TF

3.95 TF

4.58 TF

Architecture

Tahiti (x2)

Tahiti (x1)

GK110

GK104 (x2)

TDP

375W

225W

235W

225W

Memory Bandwidth

480 GB/s

264 GB/s

250 GB/s

320 GB/s

Memory Capacity

6 GB

6 GB

6 GB

8 GB

Stream Processors

3,584

1,792

2,688

3,070

Core clock speed

825 MHz

900 MHz

732 MHz

745 M

MSRP

$3,599

$2,499

$3,199

~$2500

Other features of the AMD FirePro S10000 include support for OpenCL, Microsoft RemoteFX, Direct GPU pass-through, and (shared) virtualized graphics. AMD envisions businesses using these FirePro cards to provide GPU hardware acceleration for virtualized desktops and thin clients. With Xen Server, multiple users are able to tap into the hardware acceleration offered by the FirePro S10000 to speed up desktop and speed up programs that support it.

Operating systems in particular have begun tapping into GPU acceleration to speed up the user interface and run things like the Aero desktop in Windows 7. High end software for workstations also have a high GPU acceleration adoption rate, so there are benefits to be had, and AMD is continuing to offer it with its latest FirePro card.

AMD is offering up a card that can be used for a mix of compute or graphics output, making them an interesting choice for workstations. The FirePro S10000’s major fault lies with a 375W TDP, and while the peak performance is respectable it is going to use more power while provided that compute muscle.

The cards are available now with an MSRP of $3,599. It is neat to finally see AMD come out with a dual GPU card with Tahiti chips, and it will be interesting to see what kind of design wins the company is able to get for its beastly FirePro S10000.

Paul Thurrott of Windows Supersite reports that Windows 8 is finally taking hardware acceleration seriously and will utilize the GPU across all applications. This hardware acceleration should make Windows 8 perform better and consume less power than if the setup were running Windows 7. With Microsoft finally willing to adopt modern hardware for performance and battery life I wonder when they will start using the GPU to accelerate tasks like file encryption.

It is painful when you have the right tool for the job but must use the wrong one.

Windows has, in fact, used graphics acceleration for quite some time albeit in fairly mundane and obvious ways. Windows Vista and Windows 7 brought forth the Windows Aero Glass look and feel. Aero was heavily reliant on Shader Model 2.0 GPU computing to the point that much of it would not run on anything less.

Washington State is not that far away from Oregon.

Microsoft is focusing their hardware acceleration efforts for Windows 8 on what they call mainstream graphics. 2D graphics and animation were traditionally CPU-based with a couple of applications such as Internet Explorer 9, Firefox, and eventually Chrome allowing the otherwise idle GPU to lend a helping hand. As such, Microsoft is talking up Direct2D and DirectWrite usage all throughout Windows 8 on a wide variety of hardware.

The driving force that neither Microsoft nor Paul Thurrott seems to directly acknowledge is battery life. Graphics Processors are considered power-hogs until just recently for almost anyone who assembles a higher-end gaming computer. Despite this, the GPU is actually more efficient at certain tasks than a CPU -- this is especially true when you consider the GPUs which will go into WinRT devices. The GPU will help the experience be more responsive and smooth but also consume less battery power. I guess Microsoft is finally believes that the time is right to bother using what you already have.

There are many more tasks which can be GPU accelerated than just graphics -- be it 3D or the new emphasis on 2D acceleration. Hopefully after Microsoft dips in their toe they will take the GPU more seriously as an all-around parallel task processor. Maybe now that they are implementing the GPU for all applications they can consider using it for all applications -- in all applications.

Intel does not respond well when asked about Larabee. Though Intel has received a lot of bad press from the gaming community about what they were trying to do, that does not necessarily mean that Intel was wrong about how they set up the architecture. The problem with Larrabee was that it was being considered as a consumer level product with an eye for breaking into the HPC/GPGPU market. For the consumer level, Larrabee would have been a disaster. Intel simply would not have been able to compete with AMD and NVIDIA for gamers’ hearts.

The problem with Larrabee and the consumer space was a matter of focus, process decisions, and die size. Larrabee is unique in that it is almost fully programmable and features really only one fixed function unit. In this case, that fixed function unit was all about texturing. Everything else relied upon the large array of x86 processors and their attached vector units. This turns out to be very inefficient when it comes to rendering games, which is the majority of work for the consumer market in graphics cards. While no outlet was able to get a hold of a Larrabee sample and run benchmarks on it, the general feeling was that Intel would easily be a generation behind in performance. When considering how large the die size would have to be to even get to that point, it was simply not economical for Intel to produce these cards.

Xeon Phi is essentially an advanced part based on the original Larrabee architecture.

This is not to say that Larrabee does not have a place in the industry. The actual design lends itself very nicely towards HPC applications. With each chip hosting many x86 processors with powerful vector units attached, these products can provide tremendous performance in HPC applications which can leverage these particular units. Because Intel utilized x86 processors instead of the more homogenous designs that AMD and NVIDIA use (lots of stream units doing vector and scalar, but no x86 units or a more traditional networking fabric to connect them). This does give Intel a leg up on the competition when it comes to programming. While GPGPU applications are working with products like OpenCL, C++ AMP, and NVIDIA’s CUDA, Intel is able to rely on many current programming languages which can utilize x86. With the addition of wide vector units on each x86 core, it is relatively simple to make adjustments to utilize these new features as compared to porting something over to OpenCL.

So this leads us to the Intel Xeon Phi. This is the first commercially available product based on an updated version of the Larrabee technology. The exact code name is Knights Corner. This is a new MIC (many integrated cores) product based on Intel’s latest 22 nm Tri-Gate process technology. The details are scarce on how many cores this product actually contains, but it looks to be more than 50 of a very basic “Pentium” style core; essentially low die space, in-order, and all connected by a robust networking fabric that allows fast data transfer between the memory interface, PCI-E interface, and the cores.

Each Xeon Phi promises more than 1 TFLOP of performance (as measured by Linpack). When combined with the new Xeon E5 series of processors, these products can provide a huge amount of computing power. Furthermore, with the addition of the Cray interconnect technology that Intel acquired this year, clusters of these systems could provide for some of the fastest supercomputers on the market. While it will take until the end of this year at least to integrate these products into a massive cluster, it will happen and Intel expects these products to be at the forefront of driving performance from the Petascale to the Exascale.

These are the building blocks that Intel hopes to utilize to corner the HPC market. Providing powerful CPUs and dozens if not hundreds of MIC units per cluster, the potential computer power should bring us to the Exascale that much sooner.

Time will of course tell if Intel will be successful with Xeon Phi and Knights Corner. The idea behind this product seems sound, and the addition of powerful vector units being attached to simple x86 cores should make the software migration to massively parallel computing just a wee bit easier than what we are seeing now with GPU based products from AMD and NVIDIA. The areas that those other manufacturers have advantages over Intel are that of many years of work with educational institutions (research), software developers (gaming, GPGPU, and HPC), and industry standards groups (Khronos). Xeon Phi has a ways to go before being fully embraced by these other organizations, and its future is certainly not set in stone. We have yet to see 3rd party groups get a hold of these products and put them to the test. While Intel CPUs are certainly class leading, we still do not know of the full potential of these MIC products as compared to what is currently available in the market.

The one positive thing for Intel’s competitors is that it seems their enthusiasm for massively parallel computing is justified. Intel just entered that ring with a unique architecture that will certainly help push high performance computing more towards true heterogeneous computing.

Last month, SemiAccurate reported that Adobe Creative Suite 6 would be programmed around OpenCL which would allow any GPU to accelerate your work. Adobe now claims that OpenCL would only accelerate the HD6750M and the HD6770M running on OSX Lion with 1GB of vRAM on a MacBook Pro at least for the time being at least for Adobe Premiere Pro.

Does it aggravate you when something takes a while or stutters when you know a part of your PC is just idle?

Adobe has been increasingly moving to take advantage of the graphics processor available in your computer to benefit the professional behind the keyboard, mouse, or tablet. CS 5.5 pushed several of their applications on to the CUDA platform. End-users claim that Adobe sold them out for NVIDIA but that just seems unlikely and unlike either company. My prediction is and always was more that NVIDIA parachuted in some engineers to Adobe and their help was limited to CUDA.

Creative Suite 6 further suggests that I was correct as Adobe has gone back and re-authored much of those features in OpenCL.

Isn't it somewhat ironic that insanity is a symptom of mercury poisoning?

AMD as a hatter!

CS6 will not execute on just any old GPU now despite the wider availability of OpenCL relative to the somewhat NVIDIA proprietary CUDA. While the CUDA whitelist currently extends to 22 Windows NVIDIA GPUs and 3 Mac OSX NVIDIA GPUs current OpenCL support is limited to a pair of AMD-based OSX Lion mobile GPUs: the 6750M and the 6770M.

It would not surprise me if other GPUs would accelerate CS6 if manually added to a whitelist. Adobe probably is very conservative with what components they add to the whitelist in an effort to reduce support costs. That does not mean that you will see benefits even if you trick Adobe into accepting hardware acceleration though.

It appears as if Adobe is working towards using the most open and broad standards -- they just are doing it at their own pace this time. This release was obviously paced for Apple support.

NVIDIA steals Intel’s lunch… analogy. In the process they claim that optimizing your application for Intel’s upcoming many-core hardware is not free of effort, and that effort is similar to what is required to develop on what NVIDIA already has available.

A few months ago, Intel published an article on their software blog to urge developers to look to the future without relying on the future when they design their applications. The crux of Intel’s argument states that regardless of how efficient Intel makes their processors, there is still responsibility on your part to create efficient code.

There’s always that one, in the back of the class…

NVIDIA, never a company to be afraid to make a statement, used Intel’s analogy to alert developers to optimize for many-core architectures.

The hope that unmodified HPC applications will work well on MIC with just a recompile is not really credible, nor is talking about ease of programming without consideration of performance.

There is no free lunch. Programmers will need to put in some effort to structure their applications for hybrid architectures. But that work will pay off handsomely for today’s, and especially tomorrow’s, HPC systems.

It remains to be seen how Intel MIC will perform when it eventually arrives. But why wait? Better to get ahead of the game by starting down the hybrid multicore path now.

NVIDIA thinks that Intel was correct: there would be no free lunch for developers, why not purchase a plate at NVIDIA’s table? Who knows, after the appetizer you might want to stay around.

You cannot simply allow your program to execute on Many Integrated Core (MIC) hardware and expect it to do so well. The goal is not to simply implement on new hardware -- it is to perform efficiently while utilizing the advantages of everything that is available. It will always be up to the developer to set up their application in the appropriate way.

Your advantage will be to understand the pros and cons of massive parallelism. NVIDIA, AMD, and now Intel have labored to create a variety of architectures to suit this aspiration; software developers must labor in a similar way on their end.

Over at North Carolina State University, students Yi Yang, Ping Xiang and Dr. Huiyang Zhou, along with Mike Mantor of Advanced Micro Devices have been working on a way to improve how efficiently the GPU and CPU work together. Our current generations of APU/GPGPUs, Llano and Sandy Bridge, have united the two processing units on a single substrate but as of yet they cannot efficiently pass operations back and forth. This project works to leverage the L3 cache of the CPU to give a high speed bridge between the two processors, allowing the CPU to pass highly parallel tasks to the GPU for more efficient processing and letting the CPU deal with the complex operations it was designed for.

Along with that bridge comes a change in the way the L2 prefetch is utilized; increasing memory access at that level frees up more for the L3 to pass data between CPU and GPU thanks to a specially designed preexecution unit triggered by the GPU and running on the CPU which will enable synchronized memory fetch instructions. The result has been impressive, in their tests they saw an average improvement of 21.4% in performance.

"Researchers from North Carolina State University have developed a new technique that allows graphics processing units (GPUs) and central processing units (CPUs) on a single chip to collaborate – boosting processor performance by an average of more than 20 percent.

"Chip manufacturers are now creating processors that have a 'fused architecture,' meaning that they include CPUs and GPUs on a single chip,” says Dr. Huiyang Zhou, an associate professor of electrical and computer engineering who co-authored a paper on the research. "This approach decreases manufacturing costs and makes computers more energy efficient. However, the CPU cores and GPU cores still work almost exclusively on separate functions. They rarely collaborate to execute any given program, so they aren’t as efficient as they could be. That's the issue we’re trying to resolve."

NVIDIA has traditionally been very interested in acquiring room in the high-performance computing for scientific research market. For a lot of functions, having a fast and highly parallel processor saves time and money compared to having a traditional computer crunch away or having to book time with one of the world’s relatively few supercomputers. Despite the raw performance of a GPU, adequate development tools are required to bring the simulation or calculation into a functional program to execute on said GPU. NVIDIA is said to have had a strong lead with their CUDA platform for quite some time; that lead will likely continue with releases the size of this one.

A visual profiler to point out common mistakes and optimizations and to provide instructions which detail how to alter your code to increase your performance

A new compiler which is based on the LLVM infrastructure, making good on their promise to open the CUDA platform to other architectures -- both software and hardware

New image and signal processing functions for their NVIDIA Performance Primitives (NPP) library, relieving developers the need to create their own versions or license a proprietary library

The three features, as NVIDIA describes them in their press release, are listed below.

New Visual Profiler - Easiest path to performance optimization
The new Visual Profiler makes it easy for developers at all experience levels to optimize their code for maximum performance. Featuring automated performance analysis and an expert guidance system that delivers step-by-step optimization suggestions, the Visual Profiler identifies application performance bottlenecks and recommends actions, with links to the optimization guides. Using the new Visual Profiler, performance bottlenecks are easily identified and actionable.

LLVM Compiler - Instant 10 percent increase in application performance
LLVM is a widely-used open-source compiler infrastructure featuring a modular design that makes it easy to add support for new programming languages and processor architectures. Using the new LLVM-based CUDA compiler, developers can achieve up to 10 percent additional performance gains on existing GPU-accelerated applications with a simple recompile. In addition, LLVM's modular design allows third-party software tool developers to provide a custom LLVM solution for non-NVIDIA processor architectures, enabling CUDA applications to run across NVIDIA GPUs, as well as those from other vendors.

New Image, Signal Processing Library Functions - "Drop-in" Acceleration with NPP Library
NVIDIA has doubled the size of its NPP library, with the addition of hundreds of new image and signal processing functions. This enables virtually any developer using image or signal processing algorithms to easily gain the benefit of GPU acceleration, with the simple addition of library calls into their application. The updated NPP library can be used for a wide variety of image and signal processing algorithms, ranging from basic filtering to advanced workflows.

A new piece of malware was recently uncovered by anti-virus provider Symantec that seeks to profit from your spare computing cycles. Dubbed Trojan.Badminer, this insidious piece of code is a trojan that (so far) is capable of affecting Windows operating systems from Windows 98 to Windows 7. Once this trojan has been downloaded and executed (usually through an online attack vector via an unpatched bug in flash or java), it proceeds to create a number of files and registry entries.

It's a trojan infected bitcoin, oh the audacity of malware authors!

After it has propagated throughout the system, it is then able to run one of two mining programs. It will first search for a compatible graphics card, and run Phoenix Miner. However, if a graphics card is not found, it will fall back to RPC miner and instead steal your CPU cycles. The miners then start hashing in search of bitcoin blocks, and if found, will then send the reward money to the attacker’s account.

It should be noted that bitcoin mining itself is not inherently bad, and many people run it legitimately. In fact, if you are interested in learning more about bitcoins, we ran an article on them recently. This trojan on the other hand is malicious because it is infecting the user’s computer with unwanted code that steals processing cycles from the GPU and CPU to make the attacker money. All these GPU and CPU cycles come at the cost of reduced system responsiveness and electricity, which can add up to a rather large bill, depending on where you live and what hardware the trojan is able to get its hands on.

Right now, Symantec is offering up general tips on keeping users’ computers free from the infection, including enabling a software firewall (or at least being behind a router with its own firewall that blocks unsolicited incoming connections), running the computer as the lowest level user possible with UAC turned on, and not clicking on unsolicited email attachments or links.

If you are also a bitcoin miner, you may want to further protect yourself by securing your bitcoin wallet in the event that you also accidentally become infected by a trojan that seeks to steal the wallet.dat file (the file that essentially holds all your bitcoin currency).

Stay vigilant folks, and keep an eye out on your system GPU and CPU utilization in addion to using safer computing habits to keep nastly malware like this off of your system. On a more opinionated note, is it just me or have malware authors really hit a new low with this one?

Code that can be easily parallelized into many threads have been streaming over to the GPU with many applications and helper libraries taking advantage of CUDA and OpenCL primarily. Thus for developers who wish to utilize the GPU more but are unsure where to start there are more and more options for libraries of functions to call and at least partially embrace their video cards. OpenCV is a library of functions for image manipulation and, while GPU support is ongoing through CUDA, primarily runs on the CPU. CUVIlib, which has just launched their 0.5 release, is a competitor to OpenCV with a strong focus on GPU utilization, performance, and ease of implementation. While OpenCV is licensed as BSD which is about as permissive a license as can be offered, CUVI is not and is based on a proprietary EULA.

Despite the proprietary and non-free for commercial use nature of CUVI they advertise large speedups for certain algorithms. For their Kanade-Lucas-Tomasi Feature Tracker algorithm when compared with OpenCV’s implementation they report a three-fold increase in performance with just a GeForce 9800GT installed and 8-13x faster when using a high end computing card such as the Tesla C2050. Their feature page includes footage of two 720p high definition videos undergoing the KLT algorithm with the OpenCV CPU method chugging at 2.5 fps contrasted with CUVI’s GPU-accelerated 33fps. Whether you would prefer to side with OpenCV’s GPU advancements or pay CUVIlib to augment what OpenCV is not good enough for your needs at is up to you, but either future will likely involve the GPU.