Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel Xeon processor with FPGA now shipping

fpgaer.wordpress.com

Post reply on HN
Print view View original

11–20 of 81 posts

Re: Intel Xeon processor with FPGA now shipping

#11

Post by meuk »

vegetablepotpie wrote: post #8
arcanus wrote: post #2

Could this be a hint at Intel's supercomputing and AI strategy? They cannot compete with GPUs on flops with Xeon, but an embedded FPGA might get them closer. It is a risky strategy however. Even if they can attain similar performance, which I doubt, programmability remains the big problem for FPGAs. I know Intel is pushing openCL but it simply does not have an ecosystem for software right now, and it remains to be se…

>programmability remains the big problem for FPGAs I agree because there's added levels of complexity with HDLs that SW doesn't have to deal with. What would be nice is if there was a tool that you could declare your problem (functions) and your constraints (throughput, LUTs available) and it would figure out the memory, ALUs and pipe-lining needed to solve the problem.

That is called high-level synthesis and there are some tools for this available (and I know at least one company who produces a proprietary toolchain - including hardware - for this).

In my experience, high-level synthesis makes things a lot easier for the programmer, but you still have to be aware of very low-level details (and you still can get bitten by abstractions that you don't fully understand).

Re: Intel Xeon processor with FPGA now shipping

#12

Post by sddfd »

This is great! I think that some time in the future, FPGA will be a vital part for data processing.

In theory, an application with a computation-heavy task could program the FPGA to provide part of that task in hardware (think the hot innermost loop body).

What I am worried about is the infrastructure that is needed to make this happen: Is there even support for this in our compilers? What would support look like?

Re: Intel Xeon processor with FPGA now shipping

#13

Post by gbrown_ »

batbomb wrote: post #6
quadruplebond wrote: post #4

Earlier quoted context omitted.

Pretty sure that Phi as you know it is largely being left. Argonne's Aurora exascale machine was suppose to be Xeon Phi, but it has been postponed till 2021 and will likely use some other tech. Also look at the top 500 list from late 2017. Trinity the NNSA computer at #7 is Phi based but only gets about 50% of theoretical peak.

Phi is dead. The next NERSC computer is GPUs. Not sure what Argonne is doing but there’s no reason to think it won’t be GPUs. The only reason Phi/KNL made sense was because it seemed like a conservative choice when GPUs were more exotic, which may have been okay if Intel didn’t have the crazy yield problems they had. FPGAs don’t make sense because the conservative choice at this point is GPU. I don’t think any of the…

> The next NERSC computer is GPUs.

Got a source on this? I've not seen an official mention of what sort of architecture NERSC-9 will be.

> Not sure what Argonne is doing but there’s no reason to think it won’t be GPUs.

It will be a future Intel processor [1].

[1] https://www.hpcwire.com/2017/09/27/us-coalesces-plans-first-...

Re: Intel Xeon processor with FPGA now shipping

#14

Post by chrisseaton »

sddfd wrote: post #12

This is great! I think that some time in the future, FPGA will be a vital part for data processing. In theory, an application with a computation-heavy task could program the FPGA to provide part of that task in hardware (think the hot innermost loop body). What I am worried about is the infrastructure that is needed to make this happen: Is there even support for this in our compilers? What would support look like?

> Is there even support for this in our compilers? What would support look like?

FPGA offload has been a very active area of compiler research for more than a decade. I like this paper for example https://dri.es/files/fpl05-paper.pdf

Re: Intel Xeon processor with FPGA now shipping

#15

Post by chx »

On a whole different level, if you are merely interested in FPGAs in your computer then the PicoEVB neatly goes in the same M.2 slot as wifi cards do and communicates over PCIe, even if just PCIe Gen 2 x1. As far as I am aware this is, by far, the cheapest way to get an FPGA on the PCIe bus.

Re: Intel Xeon processor with FPGA now shipping

#16

Post by mtgx »

sehugg wrote: post #10

From The Next Platform ( https://www.nextplatform.com/2018/05/24/a-peek-inside-that-i... ): The initial workload that Intel is targeting is putting Open Virtual Switch, the open source virtual switch, on the FPGA, offloading some switching functions in a network from the CPU where such virtual switch software might reside either inside a server virtualization hypervisor or outside of it but alongside virtual machines…

That seems like a weak benefit. I don't think the fpga part will be cheap. In fact it will probably be significantly more expensive than the CPU. So then why not buy a chip with twice the cores if running twice the VMs is what you want to do with it? Also you can buy an AMD EPYC chip with twice the cores for about the same price you'd pay only for the CPU part of this chip/half the intel cores.

Re: Intel Xeon processor with FPGA now shipping

#17

Post by exikyut »

meuk wrote: post #11
vegetablepotpie wrote: post #8

Earlier quoted context omitted.

>programmability remains the big problem for FPGAs I agree because there's added levels of complexity with HDLs that SW doesn't have to deal with. What would be nice is if there was a tool that you could declare your problem (functions) and your constraints (throughput, LUTs available) and it would figure out the memory, ALUs and pipe-lining needed to solve the problem.

That is called high-level synthesis and there are some tools for this available (and I know at least one company who produces a proprietary toolchain - including hardware - for this). In my experience, high-level synthesis makes things a lot easier for the programmer, but you still have to be aware of very low-level details (and you still can get bitten by abstractions that you don't fully understand).

That company might fruitfully make their system available within a datacenter / "VPS"-type context, eg the way Cloud9 does it. (https://c9.io/, you make a free account, you instantly get a Web based editor connected to a Debian VM)

If their system accepts "mostly ordinary" code in eg C, a fair amount of stuff would probably work with it, so it could scale beyond educational exploration/tinkering, too.

Re: Intel Xeon processor with FPGA now shipping

#18

Post by convery »

chx wrote: post #15

On a whole different level, if you are merely interested in FPGAs in your computer then the PicoEVB neatly goes in the same M.2 slot as wifi cards do and communicates over PCIe, even if just PCIe Gen 2 x1. As far as I am aware this is, by far, the cheapest way to get an FPGA on the PCIe bus.

Cool, will check it out. Thanks for sharing.

Re: Intel Xeon processor with FPGA now shipping

#19

Post by exikyut »

semi-extrinsic wrote: post #5
quadruplebond wrote: post #4

Earlier quoted context omitted.

Pretty sure that Phi as you know it is largely being left. Argonne's Aurora exascale machine was suppose to be Xeon Phi, but it has been postponed till 2021 and will likely use some other tech. Also look at the top 500 list from late 2017. Trinity the NNSA computer at #7 is Phi based but only gets about 50% of theoretical peak.

My personal tinfoil hat take is that Xeon Phi was made to make China waste top dollar on their supercomputers going with a less useful accelerator made by a US company.

Once China figured that out, the way they'd implement not falling for the same trick twice is simply never using US tech again. Which would limit other opportunities.

It's also at least plausible that they'd probably have people trained to think like Americans who might think of the same thing in advance.

Re: Intel Xeon processor with FPGA now shipping

#20

Post by baybal2 »

mtgx wrote: post #16
sehugg wrote: post #10

From The Next Platform ( https://www.nextplatform.com/2018/05/24/a-peek-inside-that-i... ): The initial workload that Intel is targeting is putting Open Virtual Switch, the open source virtual switch, on the FPGA, offloading some switching functions in a network from the CPU where such virtual switch software might reside either inside a server virtualization hypervisor or outside of it but alongside virtual machines…

That seems like a weak benefit. I don't think the fpga part will be cheap. In fact it will probably be significantly more expensive than the CPU. So then why not buy a chip with twice the cores if running twice the VMs is what you want to do with it? Also you can buy an AMD EPYC chip with twice the cores for about the same price you'd pay only for the CPU part of this chip/half the intel cores.

>Also you can buy an AMD EPYC chip with twice the cores for about the same price you'd pay only for the CPU part of this chip/half the intel cores.

Indeed. What benefits the most from being turned into FPGA circuit are stateless or minimally stateful circuits like media decoders/encoders.

Complex stuff like fancy routers, classifiers, internet protocol inspection/handling will not gain a hundredfold speedup unlike the stuff above. This is why cheap x86 based routers are still a thing.

At the moment, I am involved with one cloud provider in China that bids big on cheap FPGAs and RDMA. AWS and Azures can be defeated in detail.

The plan is following: provide hardware accelerated "building blocks" of any modern dotcom business.

Need memcached? We have it running on RDMA, from a bare metal ASIC, 10 times faster than any x86.

Need transcoding? We have it available on RDMA, from a bare metal ASIC, 10 times cheaper than any AWS instance on buck/megabyte.

Need API proxy for TLS/Gzip with gigabytes per second throughput? We have it running on RDMA, from a box with 4 PCIe accelerators, and AWS has nothing to offer for this use case other than "buy a hundred of top tier high performance instances and put them behind load balancers"

Post reply on HN