Inside the Microsoft FPGA-based configurable cloud [video] | Hacker News Reader

Inside the Microsoft FPGA-based configurable cloud [video]

channel9.msdn.com

41 pointswillyyr18 comments

Open articleView on HN

The explanation of FPGAs between 5:00 and ~12:00 was very very good.

TL;DW:

- FPGAs are more power-efficient than CPUs and GPUs

- FPGAs are more flexible than ASICs

FPGAs vs CPUs:

- CPU: Sequentially apply instructions on data in place

- FPGA: In parallel, flow data through instructions in place

Tried to scan the video to see if they have any support for reconfigure.io [1] (Code FPGAs with Go concurrency primitives). Didn't see any mention. Anybody knows more? Or I'll have to watch the vid in detail ... looks pretty pedagogic anyways :) ...

[1] https://reconfigure.io/

In general, code meant for sequential processors (even massively parallel sequential processors) doesn't really translate into the potential gains you see from FPGAs. I'm pretty skeptical that this gives you any gains.

Even OpenCL->HDL wasn't the huge boon it was supposed to be.

1) You're right. The problem here is the unpredictability of the buffer's size - it's equivalent to halting problem in general. You miss just one item in the buffer and you risk circuit not working at random times.

2) OpenCL->HDL takes hours to complete due to need to synthesize, whereas OpenCL->CPU code takes seconds at worst. The time to get working (synthesized) code is major blocking factor in utilizing FPGAs anywhere.

Do you think pure paradigms could be mapped, or are you skeptical of any general purpose language being able to efficiently compile to FPGAs _and_ CPUs (and GPUs)?

I've watched the whole video, no mention about this.

Google's TPU uses 28-40 W, Microsoft's uses 25 watts.

Relevant but not deep: https://redmondmag.com/blogs/the-schwartz-report/2016/10/dif...

Why aren't more people deploying FPGAs like this? I started looking into using FPGAs for distributed systems work about six years ago when I was building a distributed database. Since then, about once a month I come across some problem that an FPGA could be useful for (i.e., enhance the performance enough that something otherwise infeasible becomes feasible). The devices themselves aren't that expensive (<$100) so why doesn't every server have one? Is there some hidden cost I'm not aware of (socket real estate, power consumption)? Or is it just a chicken-and-egg problem with not enough engineers asking for them because they don't know how they work because they're not more widely deployed?

There are plenty of PCI and PCIe cards available with an FPGA.

I would assume it's the chicken-and-egg problem. Why add a ~$100 component to a machine that might never be used? It's similar to how servers never had GPUs because that was a thing only consumers that play videogames need, right up until the point that a mixed combo of A) system on a chip manufacturers needed to always include a GPU for design simplicity, and B) GPUs were realized to be rather efficient generic math co-processors for a wider variety of problem domains than just "graphics" (because who needs graphics on a headless server?).

Honestly?

It's that I have no idea where to even buy a reasonable FPGA card with a high-speed interconnect so I could build my own Catapult-esque system.

Something where I could buy a fully working card with standard networking FPGA blocks to build against, and have the FPGA mesh and PCI(e) connectors "just work" with minimal config.

I've never moved off "well, that's cute" on demo boards because the market requires a lot of hardware customization to do anything neat (eg, MS designing their own for this).

And, well, not to harp too much on the tooling... But the tooling is annoying. Workable, but annoying.

FPGAs are hard/expensive to program (including being very painful to debug), at least for most tasks - and few people are good at both FPGA and software development, so you may need different people to do the programming. New FPGA generations can require substantial re-work, at least for best performance. Many tasks would require kernel support (which is another "hard/expensive to program, and annoying to debug", although not nearly as bad).

You need a deployment scenario where FPGAs beat GPUs (and CPUs) by enough to be worth that pain, but not by enough that someone already has a ready-made ASIC for you. I agree that one would expect to see more deployment of FPGA's naively, but not a lot.

Yep, this right here. You really need a good reason to choose an FPGA. The inherent throughput and a lot of stuff is incredibly powerful, but the development is much more involved. To me anything sufficiently nontrivial always feels building a house with Lego.

This seems right, except that Microsoft has clearly developed a higher level language than VHDL / Verilog for writing "virtualized network functions" that compiles down to something they can flash onto an FPGA (they call it Flow Tables in the presentation). So there's a higher level language that's, presumably, more intuitive for "normal" engineers to work with. When a new FPGA comes out the compiler is re-written and high level code stays the same. Basically the same thing we do with CPUs. So they're not _inherently_ hard to program.

SDN is common, and definitely a scenario where FPGAs outperform GPUs. Same for machine learning. (FWIW, Google uses ASICs for both of these use cases.) What we need is a high level language and access to FPGAs. I've been interested in business opportunities in this area, but it's hard to monetize. What's somewhat surprising is that the language bit hasn't been solved in the open source world either. My suspicion is that the reason an open source language like Flow Tables doesn't exist (AFAIK) is that there's not widespread access to FPGAs.

One of the great benefits of FPGA compared to ASIC is that when you have some obscure low level bug appear you can just patch it on already sold devices, just like in software. You can also implement new features the same way, limited of course.

Maybe I think too recursively/iteratively, but I actually find it hard to think of problems where an FPGA is trivially valuable. How often am I just folding a function with fixed circuit-depth across a stream of values?

Does anybody know if the FPGA accelerated NIC uses a different driver on the guest VM, or just the standard hyperv net driver?

If it uses the standard hyperv driver, can a guest be migrated live between accelerated and unaccelerated hosts?

Yeah, there's a different driver in the VM needed

Reply on news.ycombinator.com