Test results for Knights Landing
agner.org
Test results for Knights Landing
1–10 of 19 posts
Re: Test results for Knights Landing
#2Seems to me Intel is placing their bet on the compiler doing the lion's share of the work here -- and where hand optimization is needed, another bet that having a consistent instruction set across their big Xeon cores and these MIC devices will make things easier for developers?
Re: Test results for Knights Landing
#3Seems to me Intel is placing their bet on the compiler doing the lion's share of the work here -- and where hand optimization is needed, another bet that having a consistent instruction set across their big Xeon cores and these MIC devices will make things easier for developers?
Intel has been betting on the compoler doing low level optimizations for about forever now, their compilers and software development tools are not a small part of their business.
At this point Intel is betting that anyone who's capable of doing large scale low level optimization will be designing their own hardware including the CPU so they'll better focus on high performance computing for the masses.
Interoperability with x86 big cores is also what intel wants because it means that the software can run on anything, even GPU based HPC efforts want X86 compatibility this is why AMD and Intel dragged NVIDIA to court a couple years back.
Re: Test results for Knights Landing
#4Seems to me Intel is placing their bet on the compiler doing the lion's share of the work here -- and where hand optimization is needed, another bet that having a consistent instruction set across their big Xeon cores and these MIC devices will make things easier for developers?
It doesn't seem like a particularly bad approach. I would guess that most developers don't have the skills (or time, for that matter) to be able to efficiently write code at the hand optimisation level.
Abstracting this away to the compiler is a safe bet, and developers will soon learn ways to at least generally optimise the code for the compiler, much like people have already learned to optimise code for javac, v8, etc.
Re: Test results for Knights Landing
#5Agner says that he sees no point in hyperthreading. Then he also complains that most AVX512 operations have a latency of 2 clock cycles.
Those two, I think, go hand in hand: the point is not using unused execution resources with the additional hyperthreads (thus the decode limitation), but using the other threads to fill the pipeline bubbles created by the higher latency instructions, a-la barrel processor.
edit: this of course works as KNL is aimed at throughput jobs, not anything latency sensitive.
Re: Test results for Knights Landing
#6Seems to me Intel is placing their bet on the compiler doing the lion's share of the work here -- and where hand optimization is needed, another bet that having a consistent instruction set across their big Xeon cores and these MIC devices will make things easier for developers?
Actually the whole masking and scatter-gather in AVX512 is to simplify the job of the compiler by pretty much allowing any loop to be vectorized relatively trivially.
It doesn't really require any new compiler breakthrough, as it is pretty much what all the GPU compilers (i.e. cuda) have been doing for a while already.
Re: Test results for Knights Landing
#7Seems to me Intel is placing their bet on the compiler doing the lion's share of the work here -- and where hand optimization is needed, another bet that having a consistent instruction set across their big Xeon cores and these MIC devices will make things easier for developers?
Actually the whole masking and scatter-gather in AVX512 is to simplify the job of the compiler by pretty much allowing any loop to be vectorized relatively trivially. It doesn't really require any new compiler breakthrough, as it is pretty much what all the GPU compilers (i.e. cuda) have been doing for a while already.
Not to mention scatter-gather and masking in Cray's vector processors. You do still need dependency understanding in the compiler, but that's pretty easy now compared to the late 1970s.
Re: Test results for Knights Landing
#8Agner says that he sees no point in hyperthreading. Then he also complains that most AVX512 operations have a latency of 2 clock cycles. Those two, I think, go hand in hand: the point is not using unused execution resources with the additional hyperthreads (thus the decode limitation), but using the other threads to fill the pipeline bubbles created by the higher latency instructions, a-la barrel processor. edit: thi…
This is correct, it is not possible to get peak IPC without using all the hyperthreads, by design. It is not a CPU even though it uses a CPU's ISA, so treating it as a CPU for optimization purposes is a mistake.
The advantage of its microarchitecture is that if you use the hyperthreads correctly, it will run a broad range of code at close to the theoretical IPC of the silicon without too much code effort (if you understand the model). This is in contrast to CPUs, which rarely get close to their theoretical IPC no matter what you do, or GPUs, which can only run a very narrow range of codes at close to theoretical IPC. In principle it is extremely efficient in terms of operation throughput, and it isn't sensitive to what those operations are, but it requires a large number of independent operations to be in flight to do its magic hence all the hypertheads.
While the architecture explicitly uses latency-hiding to get throughput, it is mostly about latency-hiding at the sub-microsecond level. As a practical matter, it shouldn't affect the perceived latency of most real-world software.
Re: Test results for Knights Landing
#9Agner says that he sees no point in hyperthreading. Then he also complains that most AVX512 operations have a latency of 2 clock cycles. Those two, I think, go hand in hand: the point is not using unused execution resources with the additional hyperthreads (thus the decode limitation), but using the other threads to fill the pipeline bubbles created by the higher latency instructions, a-la barrel processor. edit: thi…
This is correct, it is not possible to get peak IPC without using all the hyperthreads, by design. It is not a CPU even though it uses a CPU's ISA, so treating it as a CPU for optimization purposes is a mistake. The advantage of its microarchitecture is that if you use the hyperthreads correctly, it will run a broad range of code at close to the theoretical IPC of the silicon without too much code effort (if you unde…
I've no idea in what way KNL isn't a CPU, or how optimizing for it is fundamentally different, from running one in an HPC setting. For vectorized floating point code of the sort for which we're particularly interested in these things (e.g. DGEMM), you get peak performance from a single thread/core.
The design is supposed to be "balanced", and it does appear to do a reasonable job of that for the sort of code that uses the bulk of the time on our system. In some cases, Broadwell will do substantially better, of course. I don't have URLs for performance examples to hand.
People mostly seem to be ignoring the potentially important additions in KNL -- the memory system and the built-in interconnect (though I don't know if the latter is available yet). Also the large core count should help by keeping more MPI communication local. I don't know of any relevant results for multi-node jobs, but 64 cores covers a fair number of the HPC jobs I see.
Re: Test results for Knights Landing
#10Seems to me Intel is placing their bet on the compiler doing the lion's share of the work here -- and where hand optimization is needed, another bet that having a consistent instruction set across their big Xeon cores and these MIC devices will make things easier for developers?
I don't know about that, but Intel are putting some effort into relevant libraries (typically free software, other than MKL, I'm pleased to say). An example is the small matrix multiplication library libxsmm, which is written up for Supercomputing 16 as referenced from the repo on github. ("Simple loops"...)