6 ms·

Looks a lot more interesting than the Xeon Phi ever did. If they can provide the huge memory bandwidth this will need to keep it fed, and if they can offer a de

Looks a lot more interesting than the Xeon Phi ever did. If they can provide the huge memory bandwidth this will need to keep it fed, and if they can offer a decent programming model, then this could be very competitive. I suspect they can do these things and the next challenge for them is going to be optimized software. NVIDIA have a massive lead in terms of software support for their accelerators so I can see this being a challenge.

trhway 6y ago
>NVIDIA have a massive lead in terms of software support for their accelerators when around 2005-2006 Nvidia was hiring compiler people from Sun it was puzzling ...
rbanffy 6y ago
The nice thing about Phi was it that it looked like a lot of x86's. It was easy to program something, but, unfortunately, harder to make it perform like a similarly priced GPU. It was sold for HPC, but I saw it as an interesting way to explore what future Intel desktop and server CPUs could look like - core counts will only go up, after all. The last generation, with virtualization and the previous one, adding up to 16 GB of in-module memory that could either be system memory or behave like an L4 cache (as a comparison, IBM's latest z15 mainframe has about a gigabyte of L4 per 4-socket drawer). Too bad it never found its niche - it was too slow for HPC, lacked virtualization for servers and was ludicrously expensive (and hot) for desktops.
- gnufx 6y ago
  How was KNL too slow for HPC, like Cori? It does need to be the right sort of HPC that can use the SIMD and/or benefit from the memory bandwidth. Just the large core count (for the time and Intel) helps with MPI communication, keeping more of it local, or all of it for small enough jobs. However, we did have 64-core Bulldozers rather earlier.
  - rbanffy 6y ago
    > It does need to be the right sort of HPC Even then, it didn't work out and Intel discontinued it. It was fast enough for some tasks, but not enough popular ones to make it a market success.
gnufx 6y ago
They're pushing "One API" for programming. They rather have to deliver this time on the Aurora supercomputer.
- wmf 6y ago
  Like Roadrunner, they have to deliver something but it doesn't have to be broadly applicable. I expect that Ponte Vecchio and OneAPI will never be used outside of Aurora.
  - gnufx 6y ago
    I wasn't implying confidence, as you might have thought the original Aurora had to be delivered. Everything seems to be labelled "oneAPI" now, like the compiler and MPI.
- pjmlp 6y ago
  Except they are building on top of SYCL, which is already late to the game, as CUDA does C++17 as well, and is polyglot, whereas One API is C++ only and hopes someone else will create bindings, Khronos style in not understanding how to widespread adoption.
  - gnufx 6y ago
    Perhaps I should have said "for what it's worth". I'm not clever enough for C++, but it does seem to be what Livermore, for instance, are committed to. The oneapi propaganda does talk about other bindings, which I haven't looked for. The question might be how it works with OpenMP 5 offload, which was intended for portable performance.
cpgxiii 6y ago
The Xeon Phis really shit the bed on developer experience, so hopefully that experience has been taken to heart. The Xeon Phi marketing promise was basically "take your existing parallel x86 code, run it in on more cores", with some massive caveats: - For the KNC generation, you had to compile with the Intel C/C++ compiler, which at the time cost $$$ and completely ruled out anyone who wasn't already a HPC developer or a student with access to free ICC. - The KNC PCIe card actually made a lot of sense hardware-wise, but ran really hot and needed water cooling for a bearable desktop experience. Of course, water cooling was only available late in the KNC cycle from third parties. The cheap KNC cards Intel made available for developers were passively cooled?! and clearly an afterthought. - The system software was abjectly horrible. The kernel driver required ridiculous patching if you weren't using the officially supported RedHat/CentOS variants, and the MPSS system software itself needed hacks and workarounds to install and configure. - The KNC environment was just bizarre. It was Linux, so you could SSH to the card and do things, but it didn't run normal x86 binaries. The interaction between offload modes and card configuration/security was basically guaranteed to break if you didn't follow every step of several dozen in the manual exactly, which of course could be a problem when the instructions were for RedHat/CentOS and you were using a different distro. The KNL generation was poised to solve a lot of these problems - bootable, properly supported by GCC - and then Intel gave up on the PCIe card and the only developer platform was like $20k and it was absolutely out of reach for anyone not already invested in the platform. I'm convinced that there were a large number of users who were interested in the platform, and would have been well-served by the programming model and performance, but the barrier to entry was just too high. Nvidia got this right from basically day 1 - CUDA was available at a range of price points with (roughly) the same capabilities, so a developer could have an idea, try it out and see the benefits. Throughout almost all of CUDA's existence, for the vast majority of applications you can conclusively answer if it will work for your problem by testing on a high-end consumer GPU that costs less than $1000. Intel never understood that then, hopefully they do now.
- pjmlp 6y ago
  I sat on Intel's Larrabee session at GDCE 2009, they were selling the world how Larrabee would wipe out the competition, without really understanding why everyone else was moving into GPGPU. Apparently they still don't get it.

trhway 6y ago

>NVIDIA have a massive lead in terms of software support for their accelerators when around 2005-2006 Nvidia was hiring compiler people from Sun it was puzzling ...

rbanffy 6y ago

The nice thing about Phi was it that it looked like a lot of x86's. It was easy to program something, but, unfortunately, harder to make it perform like a similarly priced GPU. It was sold for HPC, but I saw it as an interesting way to explore what future Intel desktop and server CPUs could look like - core counts will only go up, after all. The last generation, with virtualization and the previous one, adding up to 16 GB of in-module memory that could either be system memory or behave like an L4 cache (as a comparison, IBM's latest z15 mainframe has about a gigabyte of L4 per 4-socket drawer). Too bad it never found its niche - it was too slow for HPC, lacked virtualization for servers and was ludicrously expensive (and hot) for desktops.

gnufx 6y ago
How was KNL too slow for HPC, like Cori? It does need to be the right sort of HPC that can use the SIMD and/or benefit from the memory bandwidth. Just the large core count (for the time and Intel) helps with MPI communication, keeping more of it local, or all of it for small enough jobs. However, we did have 64-core Bulldozers rather earlier.
- rbanffy 6y ago
  > It does need to be the right sort of HPC Even then, it didn't work out and Intel discontinued it. It was fast enough for some tasks, but not enough popular ones to make it a market success.

gnufx 6y ago

They're pushing "One API" for programming. They rather have to deliver this time on the Aurora supercomputer.

wmf 6y ago
Like Roadrunner, they have to deliver something but it doesn't have to be broadly applicable. I expect that Ponte Vecchio and OneAPI will never be used outside of Aurora.
- gnufx 6y ago
  I wasn't implying confidence, as you might have thought the original Aurora had to be delivered. Everything seems to be labelled "oneAPI" now, like the compiler and MPI.
pjmlp 6y ago
Except they are building on top of SYCL, which is already late to the game, as CUDA does C++17 as well, and is polyglot, whereas One API is C++ only and hopes someone else will create bindings, Khronos style in not understanding how to widespread adoption.
- gnufx 6y ago
  Perhaps I should have said "for what it's worth". I'm not clever enough for C++, but it does seem to be what Livermore, for instance, are committed to. The oneapi propaganda does talk about other bindings, which I haven't looked for. The question might be how it works with OpenMP 5 offload, which was intended for portable performance.

cpgxiii 6y ago

The Xeon Phis really shit the bed on developer experience, so hopefully that experience has been taken to heart. The Xeon Phi marketing promise was basically "take your existing parallel x86 code, run it in on more cores", with some massive caveats: - For the KNC generation, you had to compile with the Intel C/C++ compiler, which at the time cost $$$ and completely ruled out anyone who wasn't already a HPC developer or a student with access to free ICC. - The KNC PCIe card actually made a lot of sense hardware-wise, but ran really hot and needed water cooling for a bearable desktop experience. Of course, water cooling was only available late in the KNC cycle from third parties. The cheap KNC cards Intel made available for developers were passively cooled?! and clearly an afterthought. - The system software was abjectly horrible. The kernel driver required ridiculous patching if you weren't using the officially supported RedHat/CentOS variants, and the MPSS system software itself needed hacks and workarounds to install and configure. - The KNC environment was just bizarre. It was Linux, so you could SSH to the card and do things, but it didn't run normal x86 binaries. The interaction between offload modes and card configuration/security was basically guaranteed to break if you didn't follow every step of several dozen in the manual exactly, which of course could be a problem when the instructions were for RedHat/CentOS and you were using a different distro. The KNL generation was poised to solve a lot of these problems - bootable, properly supported by GCC - and then Intel gave up on the PCIe card and the only developer platform was like $20k and it was absolutely out of reach for anyone not already invested in the platform. I'm convinced that there were a large number of users who were interested in the platform, and would have been well-served by the programming model and performance, but the barrier to entry was just too high. Nvidia got this right from basically day 1 - CUDA was available at a range of price points with (roughly) the same capabilities, so a developer could have an idea, try it out and see the benefits. Throughout almost all of CUDA's existence, for the vast majority of applications you can conclusively answer if it will work for your problem by testing on a high-end consumer GPU that costs less than $1000. Intel never understood that then, hopefully they do now.

pjmlp 6y ago
I sat on Intel's Larrabee session at GDCE 2009, they were selling the world how Larrabee would wipe out the competition, without really understanding why everyone else was moving into GPGPU. Apparently they still don't get it.