3 ms·
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 evolu
by 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 agonot 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?