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

Intel Announces Knights Mill: A Xeon Phi for Deep Learning

anandtech.com

Post reply on HN
Print view View original

21–30 of 57 posts

Re: Intel Announces Knights Mill: A Xeon Phi for Deep Learning

#21

Post by joe_the_user »

argonaut wrote: post #6
cs702 wrote: post #2

We badly need an alternative to Nvidia/CUDA for deep learning... but realistically, if Intel wants to make headway in the deep learning market, it must offer hardware that can not only compete on performance with Nvidia, but also work out-of-the-box (that is, without requiring lots of one-off tinkering and tweaking) with popular deep/machine learning frameworks like TensorFlow, Caffe, Torch, and Theano. There is a lo…

But being drop-in compatible means supporting CUDA or the CPU interface.

Is there a problem with a system that's CUDA compatible?

CUDA seems to me like the only simple SIMD-type computing system that's fairly straightforward to program and understand at this point.

Drop-in CUDA compatibility seems like a good thing.

Re: Intel Announces Knights Mill: A Xeon Phi for Deep Learning

#22

Post by joe_the_user »

duaneb wrote: post #16
cs702 wrote: post #2

We badly need an alternative to Nvidia/CUDA for deep learning... but realistically, if Intel wants to make headway in the deep learning market, it must offer hardware that can not only compete on performance with Nvidia, but also work out-of-the-box (that is, without requiring lots of one-off tinkering and tweaking) with popular deep/machine learning frameworks like TensorFlow, Caffe, Torch, and Theano. There is a lo…

This is also on upstream projects not to lock themselves into CUDA. Yes, it's great, but everyone suffers when there's only one supported API. Even more so when it's closed and locked to a specific vendor, as CUDA is.

I'd love an alternative to CUDA.

The problem is that as far as I can see, OpenCL is in no way that. Basically, OpenCL gives me the impression that the oceans of boiler plate required both make development hard and effectively locks you into a specific vendor also since the boiler-plate is going to be setting things up for one's specific vendor.

Re: Intel Announces Knights Mill: A Xeon Phi for Deep Learning

#24

Post by hyperbovine »

flamedoge wrote: post #20
xadhominemx wrote: post #18

Earlier quoted context omitted.

If you're a hobbyist, why would you care about lock in?

Because you don't have control over what Google does. They may kill TPU altogether leaving your work irrelevant.

Hobbies come, hobbies go.

Re: Intel Announces Knights Mill: A Xeon Phi for Deep Learning

#25

Post by cma »

duaneb wrote: post #16
cs702 wrote: post #2

We badly need an alternative to Nvidia/CUDA for deep learning... but realistically, if Intel wants to make headway in the deep learning market, it must offer hardware that can not only compete on performance with Nvidia, but also work out-of-the-box (that is, without requiring lots of one-off tinkering and tweaking) with popular deep/machine learning frameworks like TensorFlow, Caffe, Torch, and Theano. There is a lo…

This is also on upstream projects not to lock themselves into CUDA. Yes, it's great, but everyone suffers when there's only one supported API. Even more so when it's closed and locked to a specific vendor, as CUDA is.

Can companies that don't have agreements/court rulings with Intel implement Xeon Phi ISAs?

Re: Intel Announces Knights Mill: A Xeon Phi for Deep Learning

#26

Post by rch »

ThinkBeat wrote: post #9

I wish they had a range that was affordable for a hobbyist. You can buy a cheap Nvidia card to "get your feet wet". I would like to play with these things.

Keep an eye on Colfax - they've had some nice deals in the past:

http://www.colfax-intl.com/nd/

Re: Intel Announces Knights Mill: A Xeon Phi for Deep Learning

#27

Post by jcoffland »

cs702 wrote: post #2

We badly need an alternative to Nvidia/CUDA for deep learning... but realistically, if Intel wants to make headway in the deep learning market, it must offer hardware that can not only compete on performance with Nvidia, but also work out-of-the-box (that is, without requiring lots of one-off tinkering and tweaking) with popular deep/machine learning frameworks like TensorFlow, Caffe, Torch, and Theano. There is a lo…

Since Intel's product is just a bunch of CPUs it should work with OpenCL out of the box.

Re: Intel Announces Knights Mill: A Xeon Phi for Deep Learning

#29

Post by willvarfar »

flamedoge wrote: post #20
xadhominemx wrote: post #18

Earlier quoted context omitted.

If you're a hobbyist, why would you care about lock in?

Because you don't have control over what Google does. They may kill TPU altogether leaving your work irrelevant.

You don't have control over what nvidia, intel or the rest of them either.

If you want to get your 'feet wet', then why bother?

Re: Intel Announces Knights Mill: A Xeon Phi for Deep Learning

#30

Post by pjmlp »

joe_the_user wrote: post #22
duaneb wrote: post #16

Earlier quoted context omitted.

This is also on upstream projects not to lock themselves into CUDA. Yes, it's great, but everyone suffers when there's only one supported API. Even more so when it's closed and locked to a specific vendor, as CUDA is.

I'd love an alternative to CUDA. The problem is that as far as I can see, OpenCL is in no way that. Basically, OpenCL gives me the impression that the oceans of boiler plate required both make development hard and effectively locks you into a specific vendor also since the boiler-plate is going to be setting things up for one's specific vendor.

Only with OpenCL 2.x have they came around and started to support C++ for writing kernels, as well as, a standard bytecode for any other language to target. Which most vendors still don't support.

Whereas CUDA supported C++ and Fortran from day 1, with the PTX support added a few versions later.

Also the debugging tools, from the presentations I have seen, are much more developer friendly on CUDA.

Of course developers rather use APIs that offer more modern experiences than ones still stuck in pure C, with a compiler at the driver level, forcing each programmer to writer the boilerplate to compile and link.

Now it might already be too late for OpenCL in spite of the latest improvements.

Post reply on HN