Comment by cmccabe | Hacker News Reader

Comment by cmccabe | Hacker News Reader

Parent Full thread

It's silly to make blanket statements like "FPGAs have become as capable, or more, than GPUs."

It depends on what you're trying to do! If you want to multiply big matrices, GPUs are great for that. A lot of scientific applications work well on GPUs. And obviously, GPUs are great for graphics.

Also, FPGAs are no longer blank templates on which you can stamp any design. The new ones all come with built-in "IP blocks" which you can't change. So you get a bunch of gates you can modify, but also perhaps dozen CPUs and a bank of memory, or so. Maybe someday GPUs and FPGAs will converge-- the former are getting more flexible, and the latter are getting less so.

The biggest problem with contemporary GPUs is that they're I/O-starved, which I don't see anywhere in your comments. PCI-e is just not enough bandwidth. That is why GPUs are a sideshow in big data. It doesn't matter how many cores you have if you're sipping your data through a straw.

The power consumption argument seems like a strawman. Replace a few incandescent lightbulbs in your home with LED ones. Congratulations. You can now run your GPU 24/7 and come out ahead in power consumption.

>> It's silly to make blanket statements like "FPGAs have become as capable, or more, than GPUs."

Umm, you took "at a ridiculously higher level of efficiency" out of my quote in order to call it silly? C'mon man.

If you've ever diligently crunched numbers on FPGA versus GPU monthly electricity costs at scale, I don't think you'd be capable of saying power efficiency is a strawman. If the idealistic efficient-resource-usage aspect is not convincing enough for you, we are talking millions and millions of dollars here (actually more). Look at Amazon GPU numbers and get back to me. We have detailed breakdowns of price comparisons that have been worked out in depth using the same algorithm. This is nothing like swapping out lightbulbs, that's an actual absurd and uninformed statement that can be verified and quantified as such.

And I do mention both IP blocks (even in quotes as you do) and how SoC's CPU-PL communication is much faster from being same-chip-integrated, hours before you did, so I'm not sure what you mean.

I'm also not getting why you use hard IP blocks as an argument that FPGAs are getting less flexible. They are helping to advance FPGA accessibility and flexibility a ton. Why do you think they're there? The development time savings are huge and the testing and optimization is by nature better.

The 7000 series has pretty heavy options, you can get a lot PL all your own on them. We've been specifically talking about an ARM+PL SoC, are you trying to say that an FPGA like a Virtex or Kintex is somehow not a "blank slate"? You want no standardization of any kind? The lack of that is a huge problem, and it's getting solutions.

I wasn't trying to be negative about FPGAs. I was just pointing out that there are good reasons to use GPUs in some scenarios. If your company can put FPGAs within reach of more people, that would be awesome.

I used to work at a startup company that had a plan to reduce power consumption in data centers by spinning down hard drives when they weren't in use. Too late, we learned that there isn't a lot of money in saving power. The average data center in the US might spend $500k/year on electricity. That sounds like a lot, until you consider that the fully loaded cost of a good engineer will be around $200k/year. Power becomes a factor only when you hit a wall in terms of how much can be delivered to the data center.

I was an electrical engineer in college, and I learned how to write Verilog and do register-transfer-level design. It's something that I don't think most software engineers have the background to do. Currently, I work in the area of big data, on Hadoop.

I cannot deny that Hadoop is not very power-efficient. But it offers some things that are more important to customers: infinite scalability, the ability to run on commodity hardware, and the ability to interface with the system via normal-looking software.

Actually, even writing Java code is too difficult for many Hadoop users now. They prefer to write SQL. (Even SQL is too hard for some, and they use automated tools to generate the SQL and produce charts.)

As you talk about your background more I'm getting where you're coming from. GPUs are obviously more powerful and capable for high-end graphics disregarding power efficiency. And if you're doing Hadoop big data your perspective makes more sense to me, because storage-centric applications really have no use for FPGAs. Maybe they'll be useful for querying one day, but they sure can't store large datasets. I get your point that FPGAs are not a universal panacea, but in the case of GPUs for supercomputing, and not graphics tasks, I think they are.

In the past, GPUs weren't that practical for big data, since they offered a lot of CPU power, but not much in the way of I/O. It's possible that PCI-e 3.0 and 4.0 will change that, since they supposedly offer up to 15 GB/s and 31 GB/s bandwidth.

Big data is more than just querying. There are people running fancy machine learning algorithms. Those are the people most likely to use the flexibility of having a Java (or other programming language) interface.

I'm curious why you think FPGAs will win over GPUs in HPC. I struggle to imagine academics writing Verilog or VHDL. I can just barely see them sending in legions of grad students to try to write CUDA or OpenCL, but RTL design seems a bridge too far. I also haven't heard of any of the big FPGA companies trying to make a splash in HPC, whereas NVIDIA has been very active with Tesla and its other high-end offerings.

Reply on news.ycombinator.com