Messages in this thread | | | From | David Laight <> | Subject | RE: [linus:master] [iov_iter] c9eec08bac: vm-scalability.throughput -16.9% regression | Date | Thu, 16 Nov 2023 11:38:08 +0000 |
| |
From: David Howells > Sent: 16 November 2023 10:14 > > David Laight <David.Laight@ACULAB.COM> wrote: > > > On haswell (which is now quite old) both 'rep movsb' and > > 'rep movsq' copy 16 bytes/clock unless the destination > > is 32 byte aligned when they copy 32 bytes/clock. > > Source alignment make no different, neither does byte > > alignment. > > I think the i3-4170 cpu I'm using is Haswell. Does that mean for my > particular cpu, just using inline "rep movsb" is the best choice?
I've just looked at a slight old copy of the instruction timing doc from https://www.agner.org/optimize
Apart from P4 (130 clock setup!) the setup cost for 'rep movs' is relatively small. I think everything since sandy bridge and bulldozer (except atoms, but including silvermont) do fast copies for 'rep movsb'. (But the C2758 atom we use claims erms.)
I'd bet that the overhead for using 'rep movsb' for a short copy is less than that of the mispredicted branch (or two) to select the required code.
That rather implies always using 'rep movsb' is best unless someone is compiling explicitly for an old cpu. And apart from P4 an explicit 'rep movsl' will be fastest then because the setup cost is minimal/zero.
The cutoff for using 'rep movsb' for constant sized copies is probably also a lot less than you might expect. Especially assuming cold cache.
This all makes that POS that gcc is inlining even more stupid.
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
| |