3 ms·

It makes more sense when you read Torvalds' initial argument. AVX-512 draws so much power that (especially in laptops) they have to lower the base clock of the

by ohazi 6y ago

It makes more sense when you read Torvalds' initial argument. AVX-512 draws so much power that (especially in laptops) they have to lower the base clock of the entire CPU. This doesn't matter too much if you're doing HPC, because lowering the clock 20% but gaining 200% in throughput is still a net win. But the computer can't change the clock speed instantly, so there's a fairly large penalty for just executing some AVX-512 instructions and then immediately trying to go back to other tasks (which is what happens if you try to use AVX-512 to implement memcpy). Or if you're trying to simultaneously use other parts of that core for other tasks, they'll be slower. So back to whether it'll speed up video encoding... Perhaps, but the original complaint was that "when is it appropriate to use AVX-512" already has a lot of asterisks on a Xeon in a data center... It's going to have even more asterisks in a power constrained laptop, which suggests that bringing it to laptops may not be the best option, given the availability of other options. Apparently it's difficult for Intel to look at AVX-512 objectively. The fact that their HPC customers love it doesn't imply that it's well designed or appropriate for laptops.

captainbland 6y ago
> It makes more sense when you read Torvalds' initial argument. I did but: > AVX-512 draws so much power that (especially in laptops) they have to lower the base clock of the entire CPU. This doesn't matter too much if you're doing HPC, because lowering the clock 20% but gaining 200% in throughput is still a net win. Is still basically true for encoding tasks and other SIMD-heavy operations. > But the computer can't change the clock speed instantly, so there's a fairly large penalty for just executing some AVX-512 instructions and then immediately trying to go back to other tasks (which is what happens if you try to use AVX-512 to implement memcpy). This is interesting on this point: https://travisdowns.github.io/blog/2020/01/17/avxfreq1.html https://travisdowns.github.io/blog/2020/01/17/avxfreq1.html There is a cost to switching frequencies but the cost is generally lower than the performance impact of the new frequency itself. Which kind of makes sense given how frequently dynamic frequency scaling and turbo boost/turbo core like to change the frequency of the CPU. That said, just because somebody's decided to try and use a CPU feature sub-optimally (e.g. by implementing memcpy with AVX-512 so that it gets used sporadically in the context of otherwise non-AVX related work), I don't think that necessarily justifies removing it. It does sound like the power management for it ought to be fixed, though. Is it just me or is the idea of having power management for a specific instruction extension rather than integrating it into the rest of the dynamic frequency scaling/turbo boost TDP management kind of a smell? But I do kind of buy into the idea in the sibling comment that the transistors might have been better spent on the iGPU, though - at least in the short term.
Matthias247 6y ago
As some who works on server/data-center software for workloads with very high utilization I can concur that it seems hard to judge where AVX-512 would end up having a net positive or negative impact. E.g. all that my server might be doing is running a webserver/proxy. Now 50% of requests might be using TLS, which requires crypto operations that could potentially benefit from AVX512. Other stuff might be using compression or erasure-coding mechansims that could benefit too. However all of those operations are very short and work on a few kB worth of data. Then they are interleaved by lots of other operations which would benefit more from the higher frequency. So am I now better of having AVX-512 active or not? That's only something that benchmarks for the actual workload could tell.

by ohazi 6y ago

captainbland 6y ago

> It makes more sense when you read Torvalds' initial argument. I did but: > AVX-512 draws so much power that (especially in laptops) they have to lower the base clock of the entire CPU. This doesn't matter too much if you're doing HPC, because lowering the clock 20% but gaining 200% in throughput is still a net win. Is still basically true for encoding tasks and other SIMD-heavy operations. > But the computer can't change the clock speed instantly, so there's a fairly large penalty for just executing some AVX-512 instructions and then immediately trying to go back to other tasks (which is what happens if you try to use AVX-512 to implement memcpy). This is interesting on this point: https://travisdowns.github.io/blog/2020/01/17/avxfreq1.html https://travisdowns.github.io/blog/2020/01/17/avxfreq1.html There is a cost to switching frequencies but the cost is generally lower than the performance impact of the new frequency itself. Which kind of makes sense given how frequently dynamic frequency scaling and turbo boost/turbo core like to change the frequency of the CPU. That said, just because somebody's decided to try and use a CPU feature sub-optimally (e.g. by implementing memcpy with AVX-512 so that it gets used sporadically in the context of otherwise non-AVX related work), I don't think that necessarily justifies removing it. It does sound like the power management for it ought to be fixed, though. Is it just me or is the idea of having power management for a specific instruction extension rather than integrating it into the rest of the dynamic frequency scaling/turbo boost TDP management kind of a smell? But I do kind of buy into the idea in the sibling comment that the transistors might have been better spent on the iGPU, though - at least in the short term.

Matthias247 6y ago

As some who works on server/data-center software for workloads with very high utilization I can concur that it seems hard to judge where AVX-512 would end up having a net positive or negative impact. E.g. all that my server might be doing is running a webserver/proxy. Now 50% of requests might be using TLS, which requires crypto operations that could potentially benefit from AVX512. Other stuff might be using compression or erasure-coding mechansims that could benefit too. However all of those operations are very short and work on a few kB worth of data. Then they are interleaved by lots of other operations which would benefit more from the higher frequency. So am I now better of having AVX-512 active or not? That's only something that benchmarks for the actual workload could tell.