3 ms·

> For example x86 traditionally has `rep movsb`. However that doesn’t mean it will remain the fastest way to do things in the long term Starting with Ice Lake,

> For example x86 traditionally has `rep movsb`. However that doesn’t mean it will remain the fastest way to do things in the long term Starting with Ice Lake, you can just use `rep movsb` all the time, and the processor will move memory in the fastest way it can. The CPUID feature "ERMS", "Enhanced REP MOVSB", means you should use `rep movsb` for any memory copy that's at least 128 bytes. The CPUID feature "FSRM", "Fast Short REP MOVSB", implies ERMS and additionally means that you should use `rep movsb` for any memory copy, even if it's shorter than 128 bytes.

twoodfin 6y ago
Neat! Have any of the common libc’s picked this up yet? How does ERMS deal with interrupts? If I `rep movsb` while interrupted, do I also get the fast implementation?
- temac 6y ago
  Maybe while resuming from interrupt you go slow for a while, although I suspect you eventually recover even if that happen. The interrupt will be slow as hell anyway, regardless of if you are doing rep movsb or not. Actually rep movsb with ERMS better has to work well in presence of exceptions (to support virtual memory well), so as what happens in the core in case of interrupt is very similar to what happens on exceptions, I think it's fine to use ERMS even on a system that is heavily interrupted. Or maybe you ask what happens in an interrupt handler? Probably the same thing as everywhere else, I don't see why it would be different. The state of the interrupted code has been flushed back to architectural at this point, so you can and do regular microarchitectural optims (it would even be difficult not too, there is not often a slow path and then optims on top of that, it's more the whole implementation that is made using optimisation tricks everywhere)
- JoshTriplett 6y ago
  > Neat! Have any of the common libc’s picked this up yet? glibc has, as has the Linux kernel. > How does ERMS deal with interrupts? If I `rep movsb` while interrupted, do I also get the fast implementation? Whether or not you have ERMS/FSRM available, interrupts are always defined to occur at an architecturally defined state. I don't know of any reason why, when it resumes, it would stop being optimized.

twoodfin 6y ago

Neat! Have any of the common libc’s picked this up yet? How does ERMS deal with interrupts? If I `rep movsb` while interrupted, do I also get the fast implementation?

temac 6y ago
Maybe while resuming from interrupt you go slow for a while, although I suspect you eventually recover even if that happen. The interrupt will be slow as hell anyway, regardless of if you are doing rep movsb or not. Actually rep movsb with ERMS better has to work well in presence of exceptions (to support virtual memory well), so as what happens in the core in case of interrupt is very similar to what happens on exceptions, I think it's fine to use ERMS even on a system that is heavily interrupted. Or maybe you ask what happens in an interrupt handler? Probably the same thing as everywhere else, I don't see why it would be different. The state of the interrupted code has been flushed back to architectural at this point, so you can and do regular microarchitectural optims (it would even be difficult not too, there is not often a slow path and then optims on top of that, it's more the whole implementation that is made using optimisation tricks everywhere)
JoshTriplett 6y ago
> Neat! Have any of the common libc’s picked this up yet? glibc has, as has the Linux kernel. > How does ERMS deal with interrupts? If I `rep movsb` while interrupted, do I also get the fast implementation? Whether or not you have ERMS/FSRM available, interrupts are always defined to occur at an architecturally defined state. I don't know of any reason why, when it resumes, it would stop being optimized.