Comment by digitailor | Hacker News Reader

Comment by digitailor | Hacker News Reader

Parent Full thread

Totally agree, that's why I mentioned this is about technology accessibility and really not much else. That's what I mean by kludge- it's far from ideal, but it "just works." And it's funny you mention CPUs- Von Neumann Turing machines are looking like a real kludge to me at this point as well... In my view SOCs like the Zynq are the real news, and those don't get talked about much on HN. Sequential PLUS parallel with high efficiency. So what if it's difficult to understand? Trying to really flexes the brain, and it's been worth it for me. But not easy.

That's why I wanted to start this conversation, I think it's germane to GPU efforts and people may not be aware. I would be more excited about a project like this spreading FPGA tech, and more effort being spent there. My company is doing it and we want a bigger open-source community with us. (We're not in a position to release code yet, but we will.)

Effort is energy. I'm hoping mentioning these technologies will give people pursuing projects like this some options on where to spend their efforts. There's a finite pool of people who are working in this space and I hope it grows.

I really love the idea of cloud-fpga solutions, but I can't begin to fathom how this could work without doing the fpga "coding" in a high level language. The simulation speed of verilog is too painful...

That said, working with the GPU requires a very specialized set of high level constructions as well; I imagine that most workloads could have significant parts of their computational path abstracted out to pretty common easy to port fpga processes.

If you ever launch a beta...let me know!

You're right on the money... our platform will be exposing high-level languages to the user, specifically, functional, dynamic, interpreted ones. That's our ace in the hole. I'm intentionally not mentioning our company name because it's not my intention to promote here; that would pollute the conversation. That being said, I've written your username down :)

Agreed that accessible FPGA SoCs are super exciting and I want to learn more about them. In the past when I've looked at these I've always been disappointed in the raw FLOPS available vs. GPUs, though it's difficult to compare directly, and I'm totally unfamiliar with the FPGA world. If I buy e.g. a ZYBO, make something cool, and want to scale it up to beat e.g. an NVIDIA GTX Titan in raw performance (4.5 TFLOPS), what are my options?

I guess it really depends on the application space you're interested in. We are building a cloud-FPGA platform but the barrier is just as you mention- the user being able do the programming. The idea is more people could scale their projects using the platform, but holy crap do we have a ways to go. We're going to lease out algorithmic services, basically, since getting a customer's design to work on our gear is more than difficult, there's way too much hardware variety. Portability is practically nonexistent, and that's what we're specifically trying to address.

Our approach for scaling is a monster FPGA board we're developing. It has a Zynq on it. It will be extremely inexpensive in terms of value next to, say, a highly-capable production server.

What kind of projects would you be working on if you bought a Zynq board?

Cloud FPGAs sound awesome. I'm interested in computer vision and machine learning, specifically "deep learning" neural nets. The current state of the art in neural nets is GPU implementations, and I think it's the right time to start thinking about FPGAs and eventually ASICs.

For deep learning, high performance in a single machine is important, as it's very difficult to distribute learning across multiple machines in an efficient way. A more powerful machine can train a bigger network in the same amount of time, and a bigger network can learn more complex things, with no known upper bound.

That's a great usage of FPGAs, and part of the platform will enable you to choose what algorithms you want to boot on your cluster slice. (In the FPGA space these pre-built algorithm circuits are called "IP blocks".) we will definitely be offering machine learning algorithms, with an eye towards minimizing data storage as much as possible. That may sound counter-intuitive, but there's a method to the madness (hopefully!)

I can imagine an fpga-cloud with an attached marketplace: you need performance for a certain algorithm, hardware engineers will compete and customize to your needs. I can think of quite a few engineers who'd love to participate.

That's the idea. I've just put my email address in my profile, please contact me about this if you like.

Your email is not visible, can you add it?

Actually I just reread and saw you used the word "compete", I had read it as "complete". Now that's a cool idea you have there.

Will this be similar to Parallella at all?

Parallella is an incredible project that I'm rooting for passionately. I am really looking forward to contributing to it, but we're more commercially oriented. Parallella is an Arduino/RP kind of project, and I have a feeling I will learn things from it. I, personally, still have a lot to learn in this space. Actually it feels kind of like a boundless area for learning. I really believe this is the next phase of computation, and that programming for non-Turing machines is the step that will prepare us for spintronics and quantum. I can't imagine Windows for Spintronics, I just can't. Our current software platforms, especially OSes, are going to have to change, and we want to start now. But the path is unclear- the full potential of reconfigurable computing has not yet been realized. That's why I find it exciting.

Do you think that there will be a computer in the near future that optimizes frequent workloads onto FPGA circuitry? Kind of like the storage optimization that occurs in certain SAN hardware now? This would require an OS component capable of identifying candidates from the workload and dynamically porting that to a hardware layer on the system.

Absolutely. That's a major part of what we're working on. The Zynq, specifically, allows for this more than has been possible previously. When your ARM(s) and your programmable logic are on the same wafer, you can kick tasks over more quickly. And shared resources are a big boon. This obviously is a gross oversimplification, and not straightforward from a x86 development point of view. The ARM runs Linux, or you can roll your own bare-metal OS for your application, and it plays the role you mention.

Now you're just making me jealous... ;)

Reply on news.ycombinator.com