Hacker News Reader

Comment by varelse | Hacker News Reader

Correct, Intel is playing dirty with Skylake. Sandybridge (i7-3820), IvyBridge (i7-4820), and Haswell (i7-5930k) all had 40 PCIE lane high-end consumer CPUs. Such CPUs could be used with PLX PCIE switches to build inexpensive quad-GPU supercomputers:

http://exxactcorp.com/index.php/solution/solu_list/85

As far as I can tell, there is no Skylake analog to these CPUs. So instead of building something better than a GPU, all Intel can do is buy Altera and do their worst to raise the price of building a fat GPU server.

Previously, they blocked the ability to send P2P copies between GPUs over QPI. But PLX 8747 PCIE switches provided a nice workaround (as will a single 8796 switch this round).

I guess those can, do, and those who can't, erect roadblocks.

View on HN

The -E chips have always been released a year to a year and a half after the standard models. Broadwell-E has been announced and looks to be shipping in February or March according to rumors, and Skylake E about a year or so out.

The biggest curiosity for me is the lack of the Xeon E3s. Those launched simultaneously with the past few generations of desktops, with nothing so far regarding when/if they're going to be released, other than a mention in the Skylake chipset datasheet that the last four io lanes were skylake only.

Edit: Completely forgot about the Xeon D chips. That could be an interesting path to go for the desktop supercomputer route. 32 pcie lanes, and 4-8 cores with hyperthreading. They're not as beefy of a core, but with 10gig-e onboard, could quite possibly fit in the role of GPU router.

It doesn't make much sense to say that Intel can't build something better than a GPU, right? It's like saying the reason nvidia doesn't build CPUs is because they can't build a better CPU than Intel. It distracts the conversation.

So the question really is, what is the long term strategy and why? It appears to me that Intel has validated some of this "custom hardware" FPGA strategy and that their view is it will be "better together."

I agree that Intel is erecting roadblocks, but I doubt it is because they "can't build a GPU," rather more likely because "they can erect roadblocks." In fact, they are obligated, by their shareholders, to erect those roadblocks (or to play dirty if you want).

On the contrary, Xeon Phi has absolutely been a move to get some of the hot GPGPU market, and it's not working very well. AFAIK they don't have any cases where they beat GPUs on performance per watt (or per hardware dollar). So it's highly accurate to say they can't build something better than a GPU (so far).

You seriously need to investigate what a cluster#$%! Xeon Phi is. Their attempt to kill NVIDIA was a joke and continues to be one for anyone not getting paid to say otherwise.

IMO if Intel really cared about "shareholder value(tm)" they would have acquired NVIDIA by hook or by crook. Instead, they bought the promising redheaded stepchild Altera.

Meanwhile, NVIDIA owns the ML/Deep Learning space for at least the next 2-3 years no matter what manure Intel tries to fling at them. If only AMD had a decent driver/tools team, this battle could be far more interesting.

That said, 2018 or so and beyond is a green field(tm) if Intel stops choking on its own process and exploits its process advantage to build a GPU killer either as a co-processor or by integrating sufficient multiple AVX units into the cores of its CPU roadmap.

All IMO of course.

Intel had already price-segmented "inexpensive" supercomputers by restricting ECC to Xeon chips. The good news was that the low-end Xeons were only about $100 more than the Core i7 in the same socket.

We don't know whether Intel will restrict the low-end Xeon PCI-E lane counts for skylake, because the skylake Xeons aren't out yet.

I will be very alarmed if the next generation of 1-socket (cheap) Xeons feature the same sharply restricted I/O as the non-Xeon units.

the !/$ on ECC has been craptastic for a rather long time. In fact, on GPUs, it's more likely your GPU is bad from the get-go than it is to encounter an ECC error:

http://www.robinbetz.com/papers/xsede13_betz_walker_ecc.pdf

Reply on news.ycombinator.com