7 ms·
> Larrabee ran Compute Shaders and OpenCL very well - in many cases better (in flops/watt) than rival GPUs Oh god the horror that was OpenCL on Xeon Phi. 1)
by pavanky 10y ago
> Larrabee ran Compute Shaders and OpenCL very well - in many cases better (in flops/watt) than rival GPUs
Oh god the horror that was OpenCL on Xeon Phi.
1) It was extremely buggy. Any OpenCL program of decent complexity was bound to encounter bugs in their driver.
2) FLOPS are not the only measure for computations / simulations. The bandwidth is is extremely important for many applications. Whatever Xeon Phis OpenCL was doing was not achieving anything close to its peak. Any OpenCL kernels we had tuned would end up improving the performance of the host CPU (16 x 2 Xeon) as well. It would usually result in the Xeon CPU performing better than the Xeon Phis.
3) NVIDIA released multiple generations of their GPUs since Xeon Phi was released. The performance per watt on NVIDIA and AMD GPUs has been improving substantially over the last 3 years while Xeon Phi's stagnated in 2012.
4) Even their claim for best FLOPS / WATT is wrong. The Tesla K20 released around the same time had the same power usage (225W) but about 50% higher FLOPS (2TFLOPS vs 3TFLOPS single precision).
The only selling point was that they were x86 cores and hence did not require rewriting your code. But you had to write additional directives indicating what part of your code you wanted to offload to your accelerator and when you wanted to get it back. The best performance ironically came after a lot of tuning for your application.
4 years down the line, GPU based accelerators still dominate the market and growing. and I wonder how many of the researchers who went with Xeon Phis regret their decision.
- gbrown_ 10y agoI agree with all of your points but I think KNL will be a turning point. Traditional multi core CPUs simply aren't an option to advance in the HPC space any more. Per generation there's not enough of a performance improvement to make it effective. And buying more of them isn't feasible from a power perspective. So everyone is going to have to re-write for massive parallelism. I think Intel's KNL and future Knights will be the most attractive path for a lot of people. You have the tooling and familiarity of x86 and a simpler memory model than GPUs.
- ak217 10y agoPascal is supposed to have unified memory. I haven't used it yet, but their marketing says one address space.
- gbrown_ 10y agoI've not dug into this enough yet but all prior generations of Nvidia GPUs have had caveats when adding steps to unify main memory. It certainly isn't "one address space" as far as the OS is concerned, perhaps Nvidia is saying this is sufficiently well enough abstracted in CUDA 8. The true land of milk and honey is prophesied in Volta when paired with Power 9 and CAPI, first appearing in the Summit and Sierra systems.
- pavanky 10y agoI don't have access to KNL so I can not comment on it. Any competition is good for the HPC space.
- llukas 10y agoDo you still need to use vector instructions on KNL to get top performance? If so then forgot about "familiarity" when rewriting.
- m_mueller 10y agoThis is exactly the biggest downfall of the Larrabee/Phi programming model. The claim that you can just deploy your CPU code is simply wrong if vectorization isn't taken into account. I'd argue it's worse than porting it to GPU if you start with code that's "naively" parallelized for CPU with OpenMP statements without unrolling/vector intrinsics. The reason is that the actual kernel code can stay the same for CUDA, or it can be relatively easily transformed (something I'm working on [1]) - just take whatever was inside your OpenMP loops and move it into a CUDA kernel. Meanwhile for Phi I'd have to now care about two levels of parallelism instead of just one (multicore/vector). The entire reason why GPU has been so successful, is that its performance is relatively predictable compared to x86 cores because of its much simpler architecture - and putting hundreds of them on a single chip doesn't change that. Granted, there are applications that will perform better on KNL than GPU (I expect), because it has a somewhat greater degree of freedom (although the bandwidth you get when actually using that freedom will be a deciding factor on whether it's actually worth it over the latest CPUs in those cases). [1] https://github.com/muellermichel/Hybrid-Fortran https://github.com/muellermichel/Hybrid-Fortran
- elihu 10y agoThat's just because KNL is the only chip available right now with AVX-512; presumably this will be available on other CPUs in the future.
- gbrown_ 10y agoDo you still need to use vector instructions on KNL to get top performance? Yes, but this is also the case for regular Xeons. If so then forgot about "familiarity" when rewriting. When I say "familiarity" I'm referring to tooling in things like compilers and debuggers as well as just the instruction set.
- 10y ago
- derefr 10y ago> The only selling point was that they were x86 cores and hence did not require rewriting your code. Not quite; the selling point was that they were x86 cores and hence did not require hiring graphics programmers to write your GPGPU code. You certainly did have to rewrite and refactor to get code shoved onto the Phi, but a non-HPC-focused team could do such a rewrite+refactor with just the people they already had.
- emcq 10y agoCuda did not share many similarities to the graphics pipeline back then. Even now it's a stretch to compare the two. x86 was and is still a weak selling point. Developers from all backgrounds are deploying their apps on varying architectures like ARM or the JVM without much stress. The hard part about writing code that is fast for an architecture is only made more complex by having your compute units be x86 rather than simple SP vector units of a GPU. I know many folks without a graphics background writing cuda apps but no one outside of hpc research environments dabbling in the complexities of xeon phi. The reason for this is simple; if you get your code to be in a cuda friendly structure you have created a data parallel rewrite that leverages the highly parallel memory bus of GPUs to get a pretty easy speedup. By being constrained to a semi opinionated programming interface people can see real speedups and not get bogged down in multithreading, multiprocessing, and buggy device drivers.
- unsignedqword 10y agoMy impression that everyone was using AVX512 intrinsics on Xeon Phi, although I suppose that's not what actually happened...