HPCwire: Revaluating FPGAs for 64-bit Floating-Point Calculations

The Leading Source for Global News and Information Covering the Ecosystem of High Productivity Computing

Leading HPC
Solution Providers

HPCwire >> Topic >> Processors

May 14, 2008

Revaluating FPGAs for 64-bit Floating-Point Calculations

by Dave Strenski of Cray, and Jim Simkins, Richard Walke and Ralph Wittig of Xilinx

A year ago the article "FPGA Floating Point Performance -- a pencil and paper evaluation" was published in HPCwire showing a method for comparing the peak 64-bit floating-point performance between FPGAs and Opteron processors. The article showed that the theoretical peak performance of the Virtex-4 LX200 was about 50 percent better than the then current dual-core Opteron. Since that article, a follow-up whitepaper from Altrea added refinements to the calculations to make them more realistic, which dropped the 64-bit floating-point performance of the LX200 to about equal to that of the 2.5 GHz dual-core Opteron for matrix multiply.

A year later, we now have generally available 2.5 GHz quad-core Opterons and Virtex-5 LX330, SX95T and recently announced SX240T FPGAs. In addition to this, Xilinx is releasing a new version of their floating-point cores that reduces the amount of logic and DSP slices needed for building floating-point function units. Taken together it is time to revisit Opteron floating-point performance versus FPGA performance.

Using the same assumptions as before, the peak performance of a microprocessor is given as the number of floating-point results per clock, times the number of cores, times the clock frequency. For the quad-core Opteron, this equates to a theoretical peak of (4 ops/clk * 4 cores * 2.5 GHz) 40 Gflop/s in 64-bit mode and 80 Gflop/s in 32-bit mode. For actual predicted performance, microprocessors use DGEMM (64-bit matrix multiply), which is typically 80 percent to 90 percent lower then the peak.

For FPGAs, the peak can be represented as the available logic on the device divided by the amount of logic needed to build a function unit, times the maximum clock frequency those function units will run at. Calculating this peak is more involved since there are several ways one can implement function units, using different ratios of logic and DSP resources. The microprocessors are also forced to yield an "add" and a "mult" every clock cycle, whereas the FPGA's ratio of "add" to "mult" can be varied, creating multiple peak performances.

To calculate the FPGA's actual performance level, first we need to remove a section of logic to be used for the interface to the microprocessor and the logic needed for memory controllers. Using the data from the DRC's data sheet, we see that an interface can use as much at 20,000 LUTs. For the calculations in the table below, 20,000 LUTs and 20,000 FFs have been subtracted from the devices for this interface. Next, as mentioned in the Altera whitepaper, the total amount of LUTs and FFs are further reduced by removing another 33 percent of the logic for routing. Finally, the clock frequency at which the device will run the function units is the minimum of the clock frequencies for all the floating-point cores placed on the device. This clock frequency is then further reduced by 15 percent for routing and timing considerations.

Since we're looking at multiple FPGAs and multiple ratios of "add" to "mult", a pencil and paper calculation quickly gets tedious. Looking at three FPGA devices (LX330, SX95T, SX240T), two floating-point precisions (64-bit and 32-bit), and six implementations of a function unit, "add" (full and logic) and "mult" (max, full, medium, logic), a program was written to exhaustively try every combination of function units for the two precisions and found the maximum number of function units that would fit on each device. The program then calculates the frequency at which those function units would run and the Gflop/s performance for each configuration, saving the best configuration for different ratios of "add" to "mult". The table shows the outcome of these calculations along with speedup values over the reference quad-core Opteron.

Predicted Performance

                    GFLOPS (64-bits)           Speedup over Opteron
             Opteron LX330   SX95T SX240T    LX330 SX95T SX240T
all add       17.00   32.96    8.99   29.97     1.94   0.53   1.76
8-add:1-mult 19.13   33.77    8.99   29.97     1.77   0.47   1.57
4-add:1-mult 21.25   28.14    8.32   32.10     1.32   0.39   1.51
2-add:1-mult 25.50   21.71    9.99   34.97     0.85   0.39   1.37
1-add:1-mult 34.00   18.89   11.32   39.29     0.56   0.33   1.16
1-add:2-mult 25.50   16.28   12.99   42.37     0.64   0.51   1.66
1-add:4-mult 21.25   15.07   13.32   43.33     0.71   0.63   2.04
1-add:8-mult 19.13   14.47   14.98   40.45     0.76   0.78   2.12
all mult      17.00   13.47   17.75   37.56     0.79   1.04   2.21
best                  34.30   17.75   44.94

                    GFLOPS (32-bits)           Speedup over Opteron
             Opteron LX330   SX95T SX240T    LX330 SX95T SX240T
all add       34.00   85.09   24.01   80.39     2.50   0.71   2.36
8-add:1-mult 38.25   87.43   25.06   84.56     2.29   0.66   2.21
4-add:1-mult 42.50   90.45   27.84   92.22     2.13   0.66   2.17
2-add:1-mult 51.00   94.47   31.32 104.40     1.85   0.61   2.05
1-add:1-mult 68.00   89.04   36.19 122.50     1.31   0.53   1.80
1-add:2-mult 51.00   88.72   43.85 141.98     1.74   0.86   2.78
1-add:4-mult 42.50   81.81   53.94 149.64     1.92   1.27   3.52
1-add:8-mult 38.25   79.08   62.64 153.47     2.07   1.64   4.01
all mult      34.00   79.69   75.17 162.52     2.34   2.21   4.78
best                  94.47   75.17 162.52

As an example of one of these data points, the 64-bit performance for an equal ratio of "add" to "mult" is calculated by placing 59 full "add"s and 59 max "mult"s. This design uses (59*730 + 59*327) 62,363 LUTs, (59*957 + 59*504) 86,199 FFs, and (59*3 + 59*11) 826 DSP slices and runs at a the discounted clock frequency of 333 MHz. These resources are all less than what is available on the SX240T device, LUTs (149,760-20,000)*(2/3) 86,506, FFs (149,760-20,000)*(2/3) 86,506, and DSP 1056, with the FFs being the limiting factor.

Even though the Opteron has increased its performance 4x from the dual-core (2x ops/clk and 2x in cores), the current FPGAs are still able to keep pace with Opterons. Even at the Opteron's optimal design point of an "add" and "mult" per clock, the SX240T is still 1.16 better at 64-bits and 1.80x at 32-bit results. More notable is how the FPGA's speedup over Opteron gets better as the ratio of "add" to "mult" moves away from this optimal design point. In the best cases the SX240T running an algorithm using only 64-bit floating-point "add" is 1.76x faster and an algorithm using only "mult" would be 2.21x faster. With 32-bit floating-point numbers in the all "mult" situation, the SX240T is 4.78x faster.

The current amount of work needed to make efficient FPGA designs might discourage a user from exploring FPGA acceleration. However we must realize that the DGEMM performance on a microprocessor is the best actual performance and typically hand coded in assembler by the microprocessor vendor. Typical user code that has been run through a compiler normally achieves maybe 25 percent of the peak, and even less as the number of cores increases. Advanced users will spend a great deal of time coaching the compiler to generate better performance, but there are a limited number of options. While FPGA programming may be more challenging, the programmer has complete control over the device and is able to create a design that achieves results much closer to the predicted performance numbers. This work can also be contracted to an FPGA expert to ensure optimal performance.

These tables considered the device itself and not the interconnect bandwidth. The speed gained on any accelerator device is moot if the time required to export the data from the microprocessor's memory to the accelerator and back exceeds the time the microprocessor could have calculate the result in place. As an example, the DRC system uses a 16-bit wide, 400 MHz, DDR HyperTransport connection to their Virtex-4 device, giving it a peak bandwidth of 1.6 GB/s in and 1.6 GB/s out. This speed is limited by the clock frequency of the Virtex-4, and the Virtex-5 should be able to clock this connection at 600 MHz, giving a bandwidth in and out of 2.4 GB/s. Still, the algorithm being accelerated will need to have a fairly high computational intensity to take advantages of the FPGA.

Once the data is on the FPGA accelerator, the other factor that controls performance is the local memory bandwidth. Referencing the DRC RPU datasheet, that FPGA implementation has an aggregate peak memory bandwidth of 14.4 GB/s using a Virtex-4 device, with the Virtex-5 improving this bandwidth. Lastly, once the data is on the FPGA, the SX240T has 516 dual-ported 36-bit wide Block RAMs, which means the design can pull and/or push (32/8 * 2 * 516) 4128 bytes every clock. At a conservative clock frequency of 250 MHz, that's 1032 GB/s of internal memory bandwidth. These higher bandwidths are what give the FPGA a true advantage over the microprocessor. Not only are the bandwidths higher but they are more flexible and can be used to make a custom cache for the algorithm being solved.

Looking at the resource needs between 32-bit and 64-bit function units, the Xilinx cores show that floating-point 64-bit adds take twice as much logic as 32-bit adds, but 64-bit multiplies take four times as much logic as 32-bit multiplies. This can make a significant difference in the number of function units that can fit on a device. To use this as an advantage, recall what developers did on the Cell processor in "Exploiting Single Precision Arithmetic and Achieving Full Precision Accuracy." The FPGA could get even better results then above by calculating 32 or 24-bit floating point results and iterating those results up to a higher precision.

Another consideration is what does 64-bit accuracy mean and do we really need it? A recently published paper in International Symposium on FPGA "When FPGAs are better at floating-point than microprocessors," goes into this topic in detail. The paper explains that most interfaces to computing systems are inherently fixed-point. "No sensors nor analog-to-digital converter provides floating-point output, let alone 64-bit floating-point precision." Programmers should take advantage of this inherent fixed-point input and use it as an advantage and build algorithms that use the minimal amount of precision to achieve the accuracy needed, and pack more performance on the computing device.

To understand the raw computing performance of the FPGA, consider the SX240T with 149,760 LUT6 with 2 outputs per LUT (149,760 LUTs * 2 bit operators per LUT * 250 Mhz * 1/64) is 1.17 trillion 64-bit op/s. Compare to the quad-core Opteron's 40 billion 64-bit op/s. Add to this the flexibility of wiring those operations any way the programmer wishes.

Clearly microprocessors are hitting their limits in serial processing, and programmers are forced to make their codes more parallel. There are many options; multi-processor, multi-core, Cell, GPUs, FPGAs and others. While FPGAs can keep pace with the microprocessor at their optimal design point, their are many codes for which the FPGA are the best choice for acceleration.

Article Tools

Share & Save Options

Discussion

There are 0 discussion items posted.

Join the Discussion

You must be a registered user in order to comment on HPCWire stories.

Members enjoy:

	Access to Special Content, including Podcasts, Webcasts, and Whitepapers and more!
	Ability to take an active role in the discussions that are shaping the HPC technology discipline!
	Special offers available only to HPCWire members!

Become a Registered User Today!

Registered Users Log in Here to Comment

Email Address:	Password (case sensitive)

Remember me	Forgot Password?

RSS Feeds

Feeds by Topic

Feeds by Industry

Feeds by Content Type

Feature Articles

Nexsan Looks to Scare Up HPC Customers With Storage Beast

Even though the cost of servers still dominates the datacenter budget, storage is actually on a steeper growth curve. HPC storage, in particular, is being singled out as high-growth opportunity. Vendors are scrambling to keep up.
Read More...

The Week in Review

Google datacenters most energy efficient; Cluster Resources to demo Moab Hybrid Cluster; Red Hat Linux releases HPC distro. John West recaps those stories and more in our weekly wrap-up.
Read More...

Saudi Arabia Buys Some Big Iron

Last week, IBM and King Abdullah University of Science and Technology announced a collaboration to build "Shaheen," a 222 teraflop Blue Gene/P supercomputer. When deployed in 2009, it will represent the most powerful computer in the Middle East and one of the top systems in the world.
Read More...

Read more HPCwire features...

Top Headlines

Oracle and HP's Database Machine Predicated on Voltaire

Oct 06 | The Register | Does the HP Oracle Database Machine represent InfiniBand's big chance to break out its HPC niche? Read more...

3D Imaging Spreads to Fashion and Beyond

Oct 06 | BusinessWeek | A body scan can save a lot of time in the fitting room, and fields from medicine to architecture are adopting 3D computing applications. Read more...

Structural Engineers and Computer Scientists Hope to Integrate Disciplines to 'Revolutionize Building Construction'

Oct 03 | UCSD News | Despite the evolution of computer science over the past 30 years, structural engineering -- hindered by a reluctance to adapt to digital innovations -- has remained relatively unchanged as a discipline. Read more...

Credit Crisis Spreads a Pall Over Silicon Valley

Oct 02 | New York Times | Silcon Valley is starting to feel the effects of the credit crunch. Read more...

Google: 'The World's Most Efficient Data Centers'

Oct 01 | Data Center Knowledge | Google today disclosed details of its data center energy usage, confirming that it operates some of the most efficient facilities in the world. Read more...

Read more headlines...

Featured Whitepapers

Panasas® Tiered Parity™ Architecture

Sep 04 | | Disk drives are approximately 250 times denser today than a decade ago. This is good news for users who are creating, manipulating and storing more data than ever before. It gives them an opportunity to derive more value from their stored data and lowers the capital acquisition and operating expense associated with that data.

View the White Paper Library

Multimedia

Video White Paper: Architecting a Better Network Storage Solution

BlueArc's Titan architecture represents an evolutionary step in file servers by creating a hardware-based file system that can scale bandwidth, IOPS, and overall data capacity well beyond conventional software-based devices. With its ability to virtualize a massive storage pool of up to four usable petabytes of tiered storage, Titan can scale with growing data requirements, offering a competitive advantage for businesses, researchers, or other enterprises seeking to better manage data growth while still ensuring optimal performance.