7 ms·

I'll believe it when we actually get some real world benchmarks with these. Knight's corner was also overhyped quite a bit by Intel's peak performance claims -

I'll believe it when we actually get some real world benchmarks with these. Knight's corner was also overhyped quite a bit by Intel's peak performance claims - mainly because the tools just weren't nearly on the same level as Nvidia's. To really make use of this kind of hardware, the compiler is just the start. You need debuggers, profilers, MPI integration, and, last but not least, a sensible programming model in the first place. Nvidia has been pushing that stack for close to 10 years now.

vegabook 10y ago
I think the idea is that the programming model is not much different from what we've all been doing on multicore for a while now already. Sure there'll be evolution, but it's not nearly as different as GPU compute. Also, I personally am hoping that concurrent algos will be much better suited to this than matrix-based GPUs which are basically good for massively parallel floating point only. For example, I'd love to see how a big fat BEAM VM will work on this, not to mention golang. IE I'm actually thinking that Knight's Landing will open up an oblique space where new things are possible, while not losing too much ground on the basic idea of the GPU which is masses of dumb floating point performance. Even in Python. Imagine firing up a 288-hardware-core Multiprocessing pool using a AVX-512 enabled Numpy...without changing your code. Personally that's numerical porn for me and I want Intel to shup up and take my money, now.
- m_mueller 10y ago
  not having to change your (OpenMP) code was exactly how Knight's corner was marketed, and it was also the reason why it tanked. IMO we're far off taking reasonable advantage of massive parallelism without changing code. The main reason is blocking - on multiple levels, grid, multicore, vector. Compilers just aren't smart enough to do that for you - and at least CUDA has merged two of those together so you only need to care about two levels of blocking. Talking about Numpy, isn't that what Numba Pro is already doing with GPU?

vegabook 10y ago

I think the idea is that the programming model is not much different from what we've all been doing on multicore for a while now already. Sure there'll be evolution, but it's not nearly as different as GPU compute. Also, I personally am hoping that concurrent algos will be much better suited to this than matrix-based GPUs which are basically good for massively parallel floating point only. For example, I'd love to see how a big fat BEAM VM will work on this, not to mention golang. IE I'm actually thinking that Knight's Landing will open up an oblique space where new things are possible, while not losing too much ground on the basic idea of the GPU which is masses of dumb floating point performance. Even in Python. Imagine firing up a 288-hardware-core Multiprocessing pool using a AVX-512 enabled Numpy...without changing your code. Personally that's numerical porn for me and I want Intel to shup up and take my money, now.

m_mueller 10y ago
not having to change your (OpenMP) code was exactly how Knight's corner was marketed, and it was also the reason why it tanked. IMO we're far off taking reasonable advantage of massive parallelism without changing code. The main reason is blocking - on multiple levels, grid, multicore, vector. Compilers just aren't smart enough to do that for you - and at least CUDA has merged two of those together so you only need to care about two levels of blocking. Talking about Numpy, isn't that what Numba Pro is already doing with GPU?