Hacker News Reader

Comment by dmmalam | Hacker News Reader

Is there any breakthrough in programming these things? From a quick glance at the paper it seem like the kernels are still hand written in Verilog. Though there seem to be some significant software infrastructure in integrating the FPGAs into cluster management systems.

I think easily and uniformly programming disparate compute devices (CPUs, SIMD, GPUs, FPGAs, ISPs, DSPs, and eventually quantum) is the next BIG problem in programming languages. Several Haskell projects seem promising, but these still tend to be nice DSLs that generate verilog or shaders.

On most mobile SoCs the CPU usually takes an increasingly smaller part of the die; there are 10gbe network cards with FPGAs on them; and we've got parrella. The hardware exists, we sorely need the next breakthrough programming environment.

View on HN

> I think easily and uniformly programming disparate compute devices (CPUs, SIMD, GPUs, FPGAs, ISPs, DSPs, and eventually quantum) is the next BIG problem in programming languages.

The biggest challenge to producing a unified programming model across all of these is dealing with moving data around. CPU vs GPU vs FPGA all have very different memory access characteristics. Gary Sabot was the first to try to tackle the problem of dealing with memory layout/locality in a language with what he called the Paralation model (http://www.amazon.com/The-Paralation-Model-Architecture-Inde...) and a lot of that work carried over into NESL (http://www.cs.cmu.edu/~scandal/nesl.html). Hadoop is a very lobotomized and hard to use modern version of these ideas.

I wouldn't knock DSLs - a lot of people are having good results using DSLs to program FPGAs (for example that's pretty much what http://www.novasparks.com/ does - http://lisp-univ-etc.blogspot.com/2013/06/lisp-hackers-marc-...).

Yea, totally agree that memory is at the heart of the problem. Not only in needing a unified view, but also in bandwidth constraints that seem to be the bottleneck in so much code (von neumann bottleneck).

I think a real solution would not just be software only, it would include a hardware component (or tuned to work with a particular chip): a SoC with a few fat cpu cores, many lite core, a GPU, some fpga fabric, all sharing a large cache subsystem and memory.

Convey computer has something that looks like a useful FPGA development model. Basically you move critical sections of your code into the hardware using a hardware description language(with some help from the sdk), and when writing the software , you just call that section almost normally , and convey system manages this transfer of control between cpu and FPGA as needed.

Using that you create a unique "instruction set" that can generally fit a number of applications in the same area. With that programmers can program normally and still benefit from a decent speedup.

BTW it seems that convey has a deal with DELL, and also has developed a memcached acceleration kit. This stuff will probably be available only to big cloud providers, giving them another big advantage on the DIY guys.

Altera and Xilinx are starting to support compiling OpenCL to FPGAs. Not sure how efficient that is, but that is at least a step towards unified programming environment of various types of devices.

CPUs, GPUs, DSPs, FPGAs... they are so different, it's hard to say they ever could be programmed uniformly.

I think they could - in fact I'm starting a PhD in a similar area soon! It's a matter of providing a high level enough programming language (e.g. Haskell) and a smart enough compiler that can automatically parallelise sections, and with the right middleware/compiler back end it should be possible!

I buy CPU+GPU unification (in fact I highly anticipate it) and I also buy that a DSP could function as a dynamic coprocessor, as they are often programmed in C.

But my day job revolves around HDLs, and it is my opinion that a higher level language isn't the answer. Fifty years from now it might be, but state-of-the-art HDL compilers just aren't good enough yet. It's like C compilers a few decades ago, where you had to insert some inline ASM in your code here and there because the compilers were still developing.

So I guess what I'm saying is you can't target CPU, GPU, DSP, & FPGA in one compiler until we can master targeting FPGA even just by itself.

Fair I suppose - but I still think it doesn't contradict my point. I believe that what we need is a general (and smart!) enough language, along with advanced enough and intelligent enough back ends, which should solve the problem. It will obviously take a while, but it's a really quite large area of research at the moment!

That is true of Haskell at this point too. Stictness annotations and unboxed types are sometimes necessary to squeeze maximum performance.

I think the idea would be to keep the backdoors, the question is how to make them still usable in that case.

To make a comparison for anyone who hasn't programmed FPGAs (especially on the path to etching silicon), placement is extraordinarily important. Not only can (will) you make a highly non-optimal layout, FPGAs are not orthogonal. You'll spend a lot of time trying to route the bits that need to talk to each other via direct connection as much as possible instead of going through a gp line or worse.

Depending on the make and model of FPGA, you will have "large" areas that you either can't or don't want to plop logic.

You can have a pretty netlist that validates and simulates correctly (although you'll eventually end up dealing with Cadence, who seem to have the right hand side of the bugs per line of code curve locked up) but still takes weeks or months of that inline ASM work to make it competitive with a rack of Xeons. The edit/compile/debug cycle is not quick by any means past a trivial number of gates.

Dealing with that junk is why IP blocks are so attractive, but you end up on the road to structured ASICs and that just leads to misery.

In theory it should be possible, but doing so in the general case is a ridiculously hard problem as sliverstorm hints upon.

If I was back at school, this is something I would definitely spend time on.

Some possible ideas:

- Writing different LLVM backends to target the various hardware. You still would need some runtime to schedule/organise the tasks.

- A language with a very powerful type system (ie fully dependent) which allows a high level of programmer intent to be extracted by a compiler. (ie we are only doing Multiply-adds on a specific range of doubles, so create an custom fpga for just that)

- Just writing a bunch of libraries which provide nice APIs for the various functions, kinda like NumPy.

I dont think Haskell is suitable. In fact there are very few languages that are. The reason is you need dependent types in order to compete with VHDL when it comes to type safety. I only know of two general purpose languages that support that, Idris and Nimrod (kinda.. Its coming along).

Your work sounds interesting. Contact me at skyfex@gmail.com if you want to exchange more ideas

Maybe we can open some group for this discussion. Anyway; email in my HN profile if you want to exchange ideas as well.

I agree that haskell isn't smart enough, but I think it's a step in the right direction, in that a lot of constructs seem geared to abstracting away the details of how to perform certain computations, and more about describing what a computation should perform.

Chalmers univeristy has a HDL built as Haskell modules called Lava: http://www.cse.chalmers.se/edu/year/2012/course/_courses_201... Don't think its used outside of the university though.

Berkeley has Chisel where you write something like C + Scala and you get Verilog for hardware instantiation and C for verification https://chisel.eecs.berkeley.edu/

It actually is just Scala. The whole thing is a Scala DSL.

I thought you could write some modules in C

I suppose you could, in practice, write modules for simulation in C or C++ and hook it up to the C++ code that the compiler generates. I doubt this is very useful in practice since you can't generate any Verilog from it.

Have a look at OpenCL, I know that can run on at least FPGAs and GPUs.

Better direct programming would be a big help, but check out 'dynamic method migration' sometime. There is still work to be done on the performance, but the concepts have at least been demonstrated; quite a while ago, actually.

This was in the comments: https://www.synflow.com/

Just learn a (or both) HDL, they are not hard to understand.

Reply on news.ycombinator.com