Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Use an FPGA Instead of a CPU or GPU?

blog.esciencecenter.nl

Post reply on HN
Print view View original

121–130 of 130 posts

Re: Why Use an FPGA Instead of a CPU or GPU?

#121

Post by FPGAhacker »

rwmj wrote: post #42
lightbyte wrote: post #41

Earlier quoted context omitted.

You can buy this dev board to play around with and learn FPGA for $75, and it has extensive documentation and resources to help you https://www.sparkfun.com/products/11953

But that's not a high performance FPGA. Believe me, I have a ton of FPGAs at home (starting even cheaper than that), and I write about them all the time: https://rwmj.wordpress.com/?s=fpga However if you're doing the sort of work which isn't just hobbyist stuff, you're going to spend 1000s on a board. This is the sort of thing commercial developers will be using: https://www.xilinx.com/products/boards-and-kits/ek-v7-…

You can get boards with a zynq 7020 on them for less than $200.

Re: Why Use an FPGA Instead of a CPU or GPU?

#122

Post by fulafel »

neuromantik8086 wrote: post #85

> The HPC community is already used to GPUs — getting people to switch from GPUs to FPGAs requires larger benefits. It's worth pointing out that some scientists haven't even made the leap to CPGPU computing yet and are still relying upon OpenMP / multithreading on general purpose CPUs, even when a GPU would be clearly superior. Anecdotally, I remember hearing that climate science simulations are particularly bad abou…

I think these scientists are the real winners. Computers just work for them, they don't need to jump through hoops - eg, rewrite their software for immature proprietary software architectures. Chasing that last 10x of performance at great cost is for the desperate!

Re: Why Use an FPGA Instead of a CPU or GPU?

#123

Post by esfandia »

mmirate wrote: post #118
exabrial wrote: post #116

Why does the compilation take hours, is this an NP Hard problem?

If my memory of a Processor Design course is correct, arranging the desired functionality onto the finite resources of an actual FPGA chip, let alone in such a way as to get good performance (i.e. have critical paths be as short as possible), reduces to bin-packing.

The answer might be obvious, but I'm not a hardware guy: couldn't they use a FPGA to do the compilation itself, or at least the bin-packing part? Is there a way to code a general SAT-solver in FPGA?

Re: Why Use an FPGA Instead of a CPU or GPU?

#124

Post by nl »

cjhanks wrote: post #91
neuromantik8086 wrote: post #85

> The HPC community is already used to GPUs — getting people to switch from GPUs to FPGAs requires larger benefits. It's worth pointing out that some scientists haven't even made the leap to CPGPU computing yet and are still relying upon OpenMP / multithreading on general purpose CPUs, even when a GPU would be clearly superior. Anecdotally, I remember hearing that climate science simulations are particularly bad abou…

In my experience, it's true. And it's unlikely to change - the simulation code was largely written in FORTRAN and C over a period of 50 years. This is in fact what makes Intel Phi so appealing to some.

For C/Fortran using LAPACK it should be as simple as relinking. https://www.olcf.ornl.gov/tutorials/gpu-accelerated-librarie...

Re: Why Use an FPGA Instead of a CPU or GPU?

#125

Post by shriver »

pjc50 wrote: post #28
shriver wrote: post #10

Earlier quoted context omitted.

There are a number of real issues with the emulation approach even now. Firstly, emulation isn't accurate - if you do floating point math in your application it will give you different results (within the tolerances of the OpenCL spec) on FPGA vs. CPU. So you can't test for correctness in the emulator. A second more serious issue is that getting performance that justifies using an FPGA requires tuning very carefully…

> if you do floating point math in your application it will give you different results That seems like a gross weakness in the emulator; floating point isn't actually nondeterministic!

Actually it's not as clear cut as you'd expect. Obviously you can't represent every number in floating point, so you have to choose a way to round numbers - and for simple operations like add you can correctly round the results. For transcendental operations like x^y it's actually unknown how many resources you'd need to correctly calculate x^y for every valid value of x and y[1]. So since you can't calculate these numbers to correct rounding, you have to choose a level of rounding for your approximation - like 3 units of least precision rounding at the output. Of course we all need to know how accurate these are - so the OpenCL standard specifies it[2] - exp requires being correct to 3ULPs for single/double and 2ULPs for half.

Now if you have 3 ULP to play with, the maker of an Intel CPU is going to design an exp instruction to best make use of the existing Intel functional units. But an Intel FPGA dev is going to design an exp instruction to best make use of Lookup Tables and 18x18 multiplies - because that's what they have on the FPGA.

So whilst you'll get the same answer for x^y on Intel CPU and Intel FPGA within 3 ULPs those rounding errors are going to be different between the two architectures. So now, if you want to compute a normal distribution on Intel FPGA vs CPU you'll get 3 ULPs in your exponent, but that'll carry forward into the rest of the equation.

So now you have a choice - do you use the built-in function for exp on the Intel CPU - which is OpenCL compliant just like the FPGA, and get unknown rounding errors in what is probably a mathematically sensitive task, or do you emulate the actual sub-operations the FPGA does? In which case your hardy RTL designer who wrote that exponent function RTL is going to have to write an implementation in C that emulates the hardware. Oh and they don't only have to do that for exp - they have to do that for 100s of mathematical functions, and it'll run dog slow on the CPU compared to using the native functions.

[1]https://en.wikipedia.org/wiki/Rounding#Table-maker's_dilemma

[2]https://www.khronos.org/registry/OpenCL/specs/opencl-2.1-env...

Re: Why Use an FPGA Instead of a CPU or GPU?

#126

Post by duck2 »

radarsat1 wrote: post #4
rini17 wrote: post #3

Is there high performance FPGA that does not depend on proprietary bloated windows-only toolchain?

Proprietary and bloated yes, but I believe both Xilinx and Altera both have software available for Linux, or am I wrong? At least I used Altera's suite on Linux once for a pilot project.

I recently installed Altera Quartus on Debian for a school project. It kept crashing after 2 seconds.

First result on google says quartus uses its own libcurl which is broken and you should copy the OS libcurl to /opt/altera/quartus/lin64/lib/whatever. Lots of issues like this.

Re: Why Use an FPGA Instead of a CPU or GPU?

#127

Post by physicsguy »

neuromantik8086 wrote: post #85

> The HPC community is already used to GPUs — getting people to switch from GPUs to FPGAs requires larger benefits. It's worth pointing out that some scientists haven't even made the leap to CPGPU computing yet and are still relying upon OpenMP / multithreading on general purpose CPUs, even when a GPU would be clearly superior. Anecdotally, I remember hearing that climate science simulations are particularly bad abou…

Massively depends on what you're doing as to whether it's possible, straightforward or useful to be honest. For many people it's fine, but there are plenty of people where the time investment is not worth it for a variety of reasons. It's nowhere near as simple as just porting things quickly unless you have a very simple code.

For example, I work on coupled finite-element/boundary-element calculations in magnetics. Porting our finite element calculations to GPU is possible but pointless because the memory requirements are too high - we just got some V100s on our University supercomputer but they're only the 16gb versions, and the compressed boundary element matrix of the simulation I was running just yesterday was 22gb alone, let alone all of the other data! It's nothing like people who do simulations in, for example, fluid dynamics, because the interactions they look at are generally local, whereas in our field we have a dominating non-local calculation.

If you instead use finite differences to tackle the problems we look at, then it's much less of a problem, but if you try and get into multi-GPU things you quickly run into the same memory issues because one of the calculations requires repeated FFT accelerated 3-D convolution to run in a reasonable amount of time, and in-place FFTs on multi-GPU can only be done on arrays that are < (memory on each GPU)/(Number of GPUs) because there needs to be an all-to-all communication. If you have 4 x 16gb V100s (which is $36k in my country), then that means the array you need to transform must be at most 4gb, and in practice it's less than that because we need to store other data on the GPU. That hugely limits the problems you can look at.

Re: Why Use an FPGA Instead of a CPU or GPU?

#128

Post by faragon »

IvanGoneKrazy wrote: post #110
faragon wrote: post #99

I would love to see projects like MAME and MESS targeting FPGA hardware for near-perfect hardware emulation of classic hardware.

The Anologue Super Nt project uses an FPGA to run SNES cartridges unemulated. https://www.analogue.co/pages/super-nt/

But it is not Open Source. There are more commercial products using FPGA's for emulating gaming console hardware.

Re: Why Use an FPGA Instead of a CPU or GPU?

#129

Post by kjeetgill »

shriver wrote: post #125
pjc50 wrote: post #28

Earlier quoted context omitted.

> if you do floating point math in your application it will give you different results That seems like a gross weakness in the emulator; floating point isn't actually nondeterministic!

Actually it's not as clear cut as you'd expect. Obviously you can't represent every number in floating point, so you have to choose a way to round numbers - and for simple operations like add you can correctly round the results. For transcendental operations like x^y it's actually unknown how many resources you'd need to correctly calculate x^y for every valid value of x and y[1]. So since you can't calculate these n…

> do you emulate the actual sub-operations the FPGA does?

Yes. It's an emulator.

> ... is going to have to write an implementation in C that emulates the hardware.

Makes sense. It's an emulator.

> ... and it'll run dog slow on the CPU compared to using the native functions.

Isn't that to be expected? It's an emulator. This isn't like games where it just has to look close. If it's a dev tool for testing correctness, exactness matters.

Re: Why Use an FPGA Instead of a CPU or GPU?

#130

Post by shriver »

kjeetgill wrote: post #129
shriver wrote: post #125

Earlier quoted context omitted.

Actually it's not as clear cut as you'd expect. Obviously you can't represent every number in floating point, so you have to choose a way to round numbers - and for simple operations like add you can correctly round the results. For transcendental operations like x^y it's actually unknown how many resources you'd need to correctly calculate x^y for every valid value of x and y[1]. So since you can't calculate these n…

> do you emulate the actual sub-operations the FPGA does? Yes. It's an emulator. > ... is going to have to write an implementation in C that emulates the hardware. Makes sense. It's an emulator. > ... and it'll run dog slow on the CPU compared to using the native functions. Isn't that to be expected? It's an emulator. This isn't like games where it just has to look close. If it's a dev tool for testing correctness, e…

Well last time I looked, the answer to question 1 for the Intel OpenCL SDK is actually no.

And while yes, it's expected to be slow compared to the native functions, that's not the problem. It's slow compared to simulation.

Post reply on HN