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.
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.