7 ms·
Can you elaborate a bit on why do you think Reduceron or using FPGA along with CPU is not a good idea? I thought that since the clocks aren't gonna be much high
by comboy 10y ago
Can you elaborate a bit on why do you think Reduceron or using FPGA along with CPU is not a good idea? I thought that since the clocks aren't gonna be much higher, that is the future. That maybe compilers will start generating some kind of VHDL that can make the app you spend your most CPU time on much faster (theoretical possibilities seems great with big enough FPGAs).
- adwn 10y agoSpeaking as someone who programs FPGAs for a living, they are good for three things (I'm simplifying a bit here): * interfacing with digital electronics, implementing low-level protocols, and deterministic/real-time control systems * emulating ASICs for verification * speeding up a small subset of highly specialized algorithms Of those, only the last one would apply in the context of this thread. However, caused by their structure and inherent tradeoffs, they are completely incapable of speeding up general purpose computation. As for specialized computation, if they heavily rely on floating-point ops, a GPU will nearly always be faster and cheaper.
- _yosefk 10y agoI think the new Stratix might well beat GPUs, not? The Reduceron specifically tries to quickly perform application of lambda expressions that GHC will try to avoid generating in the first place. The Reduceron speeds things up using several memory banks etc. but it still does things that shouldn't be done at all and the overhead is there at least in area and power.
- simias 10y agoI think FPGAs are too expensive to be used for general purpose computing. If on top of the chip price you add the development time it's just not cost effective. A high-end FPGA will cost you thousands of dollars and you won't be able to easily convert software code to HDL. A very high end GPU will be cheaper and easier to develop for. There are situations where a FPGA is better suited of course (very low latency real time signal processing for instance) but for general purpose computing FPGAs are not exactly ready for primetime IMO.
- adwn 10y ago> I think the new Stratix might well beat GPUs, not? Adding to what simias said, even an FPGA with built-in floating-point primitives can beat a GPU (in floating-point-heavy computations when the measure is performance/cost) only if the algorithm doesn't fit well onto the GPU architecture – for example, if you can make use of the highly flexible SRAM banks on the FPGA. I suppose there exist such workloads, but they're rare. Also, keep in mind that no FPGA comes even close to the raw external memory bandwidth of modern GPUs.
- someguy12 10y agoAltera/Intel and Xilinx have FPGAs coming out this year with HBM which should make them competitive with existing GPU memory bandwidth.
- dnautics 10y agoEven #2 is questionable. I had a front row view of a company that made a chip very quickly and one way they were able to do it was to not bother emulating ASIC in FPGA. There are some very nice and open-source hardware development tools that basically obviate that need.
- vmsplice 10y agoI'm just a curious hardware development newbie passing by but would you be willing to share the open-source development tools used? It would be really interesting to take a peek at something that was used to develop a chip very quickly. Most of the hardware stuff seems to be quite complicated and not all that open.
- rwmj 10y agoI'm not the original poster, but perhaps he's thinking of https://chisel.eecs.berkeley.edu/ https://chisel.eecs.berkeley.edu/ I believe it can (or could?) generate C++ code which compiles into a program that simulates your design.
- dnautics 10y agoThey wanted to use chisel for the whole stack, but that was impossible because of one of their engineers.
- dnautics 10y agoCheck out verilator
- adwn 10y agoOnce you get to the point where you need ASIC emulation, there are no open-source tools that are up to the task. You don't need emulation for simple stuff like Bitcoin miners or other small and/or highly regular chips. You use it if you develop a large SoC taking tens of millions of dollars to develop. It takes months after finishing your HDL code and before you get the first silicon from the fab, and you don't want to wait that long before you can start testing your custom software. So, no, #2 isn't questionable, it's routine practice. In fact, the largest FPGAs by Xilinx and Altera are structured explicitly with that use case in mind.