5 ms·
1. Have you ever tried programming an fpga? 2. Plenty of workloads don't map that well to an fpga without modification. Deep learning, molecular dynamics and o
by deepnotderp 7y ago
1. Have you ever tried programming an fpga?
2. Plenty of workloads don't map that well to an fpga without modification. Deep learning, molecular dynamics and other workloads that are relatively embarrassingly parallel, control flow light and high compute/bandwidth ratios map well to specialized hardware, but most real world code does not fit that bill!
- ezconnect 7y agoYes I have programmed FPGAs. We are reaching the limit of the silicon and the only way to get faster is to run the CPU on something different or each software get implemented on hardware which is getting cheaper.
- deepnotderp 7y ago> Yes I have programmed FPGAs And was it a pleasurable experience? Do you really think people will rewrite all their software for fpgas? And what if you're memory or I/O bottlenecked as so many processors are today?
- ezconnect 7y agoFor me it's a pleasurable experience. > Do you really think people will rewrite all their software for fpgas? A compiler will do it for them. If technology moves in that direction they don't have any choice anyways. > And what if you're memory or I/O bottlenecked as so many processors are today? I/O will never run as fast as the CPU.
- icxa 7y ago> I/O will never run as fast as the CPU. In the era of kernal bypass and modern IO accelerators seen in some data centers today, I wonder if this is even true today?
- rcxdude 7y agosomething which was on HN a few days ago (I/O is faster than CPU): https://news.ycombinator.com/item?id=19818899 https://news.ycombinator.com/item?id=19818899
- tntn 7y agoThe adoption of FPGAs is, IMO, limited by the quantity of people who can write RTL. Lots of people can write assembly, a lot more can write C or C++, and legion of people can write software in higher level languages. Compared to the quantity of software engineers, there are extremely few people that can write RTL of moderate complexity, and even for those few, the development process is much slower than software. This could change, and I'd love to see that, but without improved "programmability" FPGAs will remain niche. I haven't followed the latest developments very closely, but Xilinx seems to be moving in this direction with Everest through the addition of vector cores.
- jcranmer 7y ago> This could change, and I'd love to see that, but without improved "programmability" FPGAs will remain niche. I haven't followed the latest developments very closely, but Xilinx seems to be moving in this direction with Everest through the addition of vector cores. As a disclaimer, I've never personally worked with FPGAs, but a lot of my coworkers have, and I'm mostly parroting their views. And those views are... FPGAs are a dead-end technology. For a while, they were considered the "obvious" next frontier of HPC, just once we got the programming model sorted out. And they stalled at that phase for over a decade, until CUDA came out and everyone realized just how much better GPGPUs were at providing the necessary HPC speedup while requiring far less development time. So how do you fix FPGAs? Well, you start substituting actual hardware logic instead of emulating everything with LUTs. And as you do this, you start to end up at coarse-grained reconfigurable arrays instead.
- analognoise 7y agoI'd have just stopped at "I have never worked with FPGAs". To say they're a dead end is to totally misunderstand what they're good at and capable of. Source: Professional FPGA designer.
- davemp 7y agoI work with FPGAs professionally. I'd tend to agree with OP that FPGAs are a dead end, considering that the trend is to bake in as much hard IP as possible and have a dual core CPU on every chip.
- tejuis 7y agoThere are some contradictions in here. If you map your functionality from software (on CPU) to FPGA, your software becomes hardware. FPGA is hardware. FPGA is retargetable, but it is not programmable in the sense what SW requires. The resources are preallocated, which is the essential property of hardware. In software you allocate and deallocate memory, which is your dynamic resource. You don't have that in HW. You can implement a memory manager in HW, but your system will not be flexible enough to be soft. Also you can synthesize your CPU on FPGA, but the performance is poor compared to a hard CPU on FPGA. Currently FPGAs are becoming popular in accelerating software functions to offload the CPU. The most powerful FPGAs have a lot of fixed logic CPUs in them (i.e. hard macros). You can't just say that I'll just go ahead and run my software functions as hardware. For certain type of workloads you always need software, in practice (not in theory).
- wyatwerp 7y agoDoes it matter which workloads always need software? If anything, the networking use-case shows that a workload, any workload, that is ubiquitous & can benefit tremendously from programmable hardware is what matters. In a shared-memory system, just implementing libc (or the Java VM, or the Erlang VM) on an FPGA might be a win. It has to be enough bang for the buck for FPGA, but not so much that somebody would make fixed-hardware for it. On that note, haven't networking end-points had fixed hardware also for ages now? Maybe it is inevitable that a successful application of FPGA's breeds interest in fixed-function hardware for it.
- BubRoss 7y agoHow will that help memory latency, which is the biggest bottleneck to most programs?