> There is a transition period (the rightmost of the two shaded regions, in orange14) of ~11 μs15 where the CPU is halted: no samples occur during this period16. For fun, I’ll call this a frequency transition.
It stops executing for 35 thousand cycles. I call that a "lockup" "as it shifts".
This isn't the real problem though...the problem with the existing AVX-512 implementations is the "relaxation time" causes subsequent scalar code to be slow.
From later in the same post:
> Here, we have the worst case scenario of transitions packed as closely as possible, but we lose only ~20 μs (for 2 transitions) out of 760 μs, less than a 3% impact. The impact of running at the lower frequency is much higher: 2.8 vs 3.2 GHz: a 12.5% impact in the case that the lowered frequency was not useful (i.e., because the wide SIMD payload represents a vanishingly small part of the total work).
Interestingly enough, this is another feature that is supposed to have been improved on server Icelake. The frequency transition halt time is now pretty much negligible. The "core frequency transition block time" goes from ~12 us on CLX (similar to the number quoted above) to ~0 us on ICX.
It is definitely a problem of defective hardware. But there are plenty of people out there with both Intel and Ryzen systems who disable every C-State and every Turbo setting because any change in power levels causes their system to crash. Lockup, bluescreen, kernel panic or just computation errors.
Some of that is from overclocking. Some is from old and/or defective power supplies. Some is from motherboard VRMs. And some, like the original Ryzen 1700X, is from bad SOC-internal power management.
At any rate, I have read forum posts reporting system failures caused by AVX. Either overcurrent or clockrate changes crashing it.
So it seems to have support. I wouldn't call that "misinformation."
> But there are plenty of people out there with both Intel and Ryzen systems who disable every C-State and every Turbo setting because any change in power levels causes their system to crash.
There are plenty of people with both Intel and Ryzen systems that are straight-up broken and don't power on at all.
Defects happen. Improperly designed systems happen. Misconfigurations happen. While those situations are unfortunate for the small percentage of people experiencing them, they shouldn't be used to judged the platform's capabilities as a whole.
> So it seems to have support. I wouldn't call that "misinformation."
Using anonymous, largely unverifiable anecdotes posted on web forums as evidence for a population-wide problem is a textbook case of selection bias.
And if you're OK with that, let me throw in my own anecdote.
All of my systems, which include:
* Skylake, Coffee Lake, Haswell/Broadwell, Sandy Bridge/Ivy Bridge, and Westmere/Nehalem Intel processors,
* Zen 2, K10, and K8 AMD processors,
...have been able to reliably execute supported vector instructions (SSE, AVX, etc.) for extended periods of time without any problems.
Dylan16807|5 years ago
> There is a transition period (the rightmost of the two shaded regions, in orange14) of ~11 μs15 where the CPU is halted: no samples occur during this period16. For fun, I’ll call this a frequency transition.
It stops executing for 35 thousand cycles. I call that a "lockup" "as it shifts".
tarlinian|5 years ago
From later in the same post:
> Here, we have the worst case scenario of transitions packed as closely as possible, but we lose only ~20 μs (for 2 transitions) out of 760 μs, less than a 3% impact. The impact of running at the lower frequency is much higher: 2.8 vs 3.2 GHz: a 12.5% impact in the case that the lowered frequency was not useful (i.e., because the wide SIMD payload represents a vanishingly small part of the total work).
Interestingly enough, this is another feature that is supposed to have been improved on server Icelake. The frequency transition halt time is now pretty much negligible. The "core frequency transition block time" goes from ~12 us on CLX (similar to the number quoted above) to ~0 us on ICX.
(Slide with frequency transition info: https://images.anandtech.com/doci/15984/202008171754441.jpg)
zlynx|5 years ago
Some of that is from overclocking. Some is from old and/or defective power supplies. Some is from motherboard VRMs. And some, like the original Ryzen 1700X, is from bad SOC-internal power management.
At any rate, I have read forum posts reporting system failures caused by AVX. Either overcurrent or clockrate changes crashing it.
So it seems to have support. I wouldn't call that "misinformation."
theevilsharpie|5 years ago
There are plenty of people with both Intel and Ryzen systems that are straight-up broken and don't power on at all.
Defects happen. Improperly designed systems happen. Misconfigurations happen. While those situations are unfortunate for the small percentage of people experiencing them, they shouldn't be used to judged the platform's capabilities as a whole.
> So it seems to have support. I wouldn't call that "misinformation."
Using anonymous, largely unverifiable anecdotes posted on web forums as evidence for a population-wide problem is a textbook case of selection bias.
And if you're OK with that, let me throw in my own anecdote.
All of my systems, which include:
* Skylake, Coffee Lake, Haswell/Broadwell, Sandy Bridge/Ivy Bridge, and Westmere/Nehalem Intel processors,
* Zen 2, K10, and K8 AMD processors,
...have been able to reliably execute supported vector instructions (SSE, AVX, etc.) for extended periods of time without any problems.