Intel Gears Up for FPGA Push • Hacker News Board

Re: Intel Gears Up for FPGA Push

#61

Post by rightos » Tue, Oct 03, 2017, 1:09 PM UTC

fulafel wrote: post #32

burntrelish1273 wrote: post #13

The biggest problem with reconfigurable computing is it's either an afterthought, tools are too narrow/proprietary or an extra add-in card. Add a million LUTs and several thousand special-purpose blocks (ALUs, CAM, SRAM, DSPs, etc.) on CPU die that can be reconfigured within a few 10k cycles (ie process context), and then future AI-enabled optimizing compilers could incrementally profile and accelerate applications w…

I thought FPGAs had a limited number of updates, enough to preclude this level of dynamism?

Most are loaded from SRAM or similar, but it could be fairly simple to make it load from your main RAM and then there wouldn't be any issue there.

Re: Intel Gears Up for FPGA Push

#62

Post by jalons » Tue, Oct 03, 2017, 1:14 PM UTC

nakedrobot2 wrote: post #47

nimish wrote: post #44

Tooling tooling tooling. FPGA hardware is cool but the tooling fucking sucks. Like stepping back into the time where you needed to pay thousands of dollars to get decent compilers and debuggers. The ability for anyone to develop software for CPUs at zero-cost is an amazing freedom. You literally cannot do that on certain fpgas--not only do they cost thousands, so do the tools to actually create a working design. Unti…

FPGA's are extremely powerful, but the toolchain is absolute dog shit. Xilinx, shame on you. Intel, will you change anything here? The compound problem of this in reality is that finding the right people who have the right strain of semi-insanity to do this really well, is very slim. And most of them are tied up with a massive salary from some aerospace company such as Raytheon, GE, Honeywell, or someone like Philips…

HFT also still pays top dollar for competent FPGA developers. I'd wager they're willing to pay more than the listed industries too, especially if you factor in profit sharing and bonus structures.

Re: Intel Gears Up for FPGA Push

#63

Post by Boothroid » Tue, Oct 03, 2017, 1:15 PM UTC

simias wrote: post #58

AriaMinaei wrote: post #43

In the case of Lisp and Smalltalk and other highly dynamic languages, would these on-die FPGAs open new compiler optimisation opportunities?

The problem is that tailor-made FPGA designs won't run nearly as fast as a modern ASIC CPU. That's why for instance FPGA emulators are not more common, for older hardware software implementations are accurate enough and manage to run in realtime so the additional cost and complexity of FPGAs is not warranted. For more modern hardware software implementations can't reach absolute accuracy in real time but FPGAs big an…

I'm kind of fascinated by any type of accelerator chip for some reason - I think it has something to do with the design of the computers I had when I was a kid i.e. Spectrum, Amiga etc which had dedicated chips for particular facets of the functioning that became iconic. I would love to do something with FPGAs and am certain their potential is massive, but struggle to come up with a use case that seems in any way novel, and I don't really want to just build my own VGA controller, get bored, and stop there!

Re: Intel Gears Up for FPGA Push

#64

Post by Boothroid » Tue, Oct 03, 2017, 1:23 PM UTC

katastic wrote: post #10

I've honestly been waiting for this since for YEARS. I've had a vision for "the future of computing". FPGAs that reconfigure themselves ( This would be hard for a single person, but any large company could handle making this. You can even do it with off-the-shelf FPGAs. The biggest problems are 1) bandwidth. The "macro" function size needs to be bigger than the latency hit you take for asking the FPGA over computing…

I've been thinking of something similar recently - to extend your idea slightly, why couldn't the flashing of the FPGA happen per tick? Thus at every tick your FPGA could become entirely different hardware, tailored to whatever task is required at that tick.

Re: Intel Gears Up for FPGA Push

#65

Post by aeruder » Tue, Oct 03, 2017, 1:32 PM UTC

simias wrote: post #45

nimish wrote: post #44

Tooling tooling tooling. FPGA hardware is cool but the tooling fucking sucks. Like stepping back into the time where you needed to pay thousands of dollars to get decent compilers and debuggers. The ability for anyone to develop software for CPUs at zero-cost is an amazing freedom. You literally cannot do that on certain fpgas--not only do they cost thousands, so do the tools to actually create a working design. Unti…

I dream of a GCC/LLVM for FPGAs. I'm not holding my breath for Intel to help with that though.

C (or really any traditional programming language) doesn't really map to an FPGA. There are some compilers out there that attempt to convert traditional C code to state machines for FPGAs, but FPGAs are really a completely different paradigm. You're actually describing digital logic, not a sequence of steps.

That being said, there are soft-processors that have been written in VHDL/Verilog and can be incorporated into a FPGA design, and those CPUs do often have GCC support (Microblaze Xilinx, NIOS 2 Altera, plenty of MIPS CPUs out there, etc.).

Re: Intel Gears Up for FPGA Push

#66

Post by microcolonel » Tue, Oct 03, 2017, 1:46 PM UTC

0xbear wrote: post #23

microcolonel wrote: post #12

Earlier quoted context omitted.

Idunno, Xeon Phi, their GPUs since about 2007 (though a lot better recently), good cooperation and documentation with their NICs, direct participation in both major open compiler toolchains, all the stuff that 01.org lists... I think they're doing pretty well with open (aside from the products themselves, but that's kinda the point of having a company). Frankly Intel has done an adequate to good job of providing open…

You can’t even use their main product without loading in opaque binary blobs and agreeing to a backdoor.

That's true, that's my greatest gripe with them. It's a major part of why I'm looking to other platforms for my workstation.

That said, you can't escape that with their nearest competitor, so it's a bit of a moot point for now.

Re: Intel Gears Up for FPGA Push

#67

Post by AriaMinaei » Tue, Oct 03, 2017, 1:49 PM UTC

simias wrote: post #58

AriaMinaei wrote: post #43

In the case of Lisp and Smalltalk and other highly dynamic languages, would these on-die FPGAs open new compiler optimisation opportunities?

The problem is that tailor-made FPGA designs won't run nearly as fast as a modern ASIC CPU. That's why for instance FPGA emulators are not more common, for older hardware software implementations are accurate enough and manage to run in realtime so the additional cost and complexity of FPGAs is not warranted. For more modern hardware software implementations can't reach absolute accuracy in real time but FPGAs big an…

I remember a talk by Alan Kay where he mentioned a number of problems commonly solved serially, such as 2D layout and typesetting, and then he demonstrated a parallel algorithm for each problem. If I remember and understand correctly (I may not), one of his points was that such algorithms can become trivially implementable in a dynamic language and would run fast too, if the hardware supported some of the primitives of that dynamic language natively. He expressed hope that FPGAs may create such an opportunity.

Re: Intel Gears Up for FPGA Push

#68

Post by scottlegrand2 » Tue, Oct 03, 2017, 1:53 PM UTC

booblik wrote: post #37

katastic wrote: post #10

I've honestly been waiting for this since for YEARS. I've had a vision for "the future of computing". FPGAs that reconfigure themselves ( This would be hard for a single person, but any large company could handle making this. You can even do it with off-the-shelf FPGAs. The biggest problems are 1) bandwidth. The "macro" function size needs to be bigger than the latency hit you take for asking the FPGA over computing…

> As CPUs are designed for one thing "few, large, complex cases" while FPGAs are perfect for many, parallel simple cases" even more than a GPU. FPGAs are quite good at parallel simple cases, that is correct, but they would lose to GPUs in performance/watt in most cases. Where FPGAs really shine is in parallel complex, non-uniform cases, especially cases that don’t map well to the classic CPU instructions, but can eas…

FPGAs own low latency computation (less than 1 microsecond) because GPUs really need 3-20 microseconds to initialize after a kernel launch. This is why they're used instead of GPUs at the front line of high frequency trading. When I was at a hedge fund, I tried in vain to get Nvidia to do something about this based on the unofficial work of another former Nvidia employee implying this could be improved dramatically.

All that said, these are golden years to be a low-level programmer who understands parallel algorithms whether you work in Tech or at a hedge fund because there just aren't that many of us.

But the real problem with FPGAs is that even if they find another lucrative application where they excel relative to GPUs, Nvidia can simply dedicate transistors in their next GPU family to erasing that advantage as they did with 8-bit and 16-bit MAD instructions in Pascal and with the tensor cores in Volta. Too bad they don't care about latency or I believe they could disrupt FPGAs from HFT in a year or two when someone started using them and started winning.

Re: Intel Gears Up for FPGA Push

#69

Post by selimthegrim » Tue, Oct 03, 2017, 1:54 PM UTC

AriaMinaei wrote: post #67

simias wrote: post #58

Earlier quoted context omitted.

The problem is that tailor-made FPGA designs won't run nearly as fast as a modern ASIC CPU. That's why for instance FPGA emulators are not more common, for older hardware software implementations are accurate enough and manage to run in realtime so the additional cost and complexity of FPGAs is not warranted. For more modern hardware software implementations can't reach absolute accuracy in real time but FPGAs big an…

I remember a talk by Alan Kay where he mentioned a number of problems commonly solved serially, such as 2D layout and typesetting, and then he demonstrated a parallel algorithm for each problem. If I remember and understand correctly (I may not), one of his points was that such algorithms can become trivially implementable in a dynamic language and would run fast too, if the hardware supported some of the primitives…

Do you remember the title or have a link?

Re: Intel Gears Up for FPGA Push

#70

Post by simias » Tue, Oct 03, 2017, 1:57 PM UTC

aeruder wrote: post #65

simias wrote: post #45

Earlier quoted context omitted.

I dream of a GCC/LLVM for FPGAs. I'm not holding my breath for Intel to help with that though.

C (or really any traditional programming language) doesn't really map to an FPGA. There are some compilers out there that attempt to convert traditional C code to state machines for FPGAs, but FPGAs are really a completely different paradigm. You're actually describing digital logic, not a sequence of steps. That being said, there are soft-processors that have been written in VHDL/Verilog and can be incorporated into…

Oh that's not what I was implying, sorry for the confusion. I meant an open source, portable HDL compiler/synthesizer like what GCC/LLVM are for software. As the parent and many others point out in this thread the tooling is a really sore point for FPGA development. It's always big, clunky, often buggy closed source applications (often running on an unhealthy dose of Tcl scripts cobbled together).

And of course if you change supplier you have to relearn everything or pay for an other third-party closed source solution to abstract some of the differences between the environments of Xilinx, Altera/IntelFPGA and friends.