By: anon2 (anon.delete@this.anon.com), February 23, 2021 5:30 pm
Room: Moderated Discussions
rwessel (rwessel.delete@this.yahoo.com) on February 23, 2021 9:44 am wrote:
> none (none.delete@this.none.com) on February 23, 2021 7:37 am wrote:
> > Anon (no.delete@this.spam.com) on February 23, 2021 6:21 am wrote:
> > > anon2 (anon.delete@this.anon.com) on February 23, 2021 4:20 am wrote:
> > > > Apparently not easy for Intel though because they've been at it for years, every generation
> > > > telling us that finally rep mov doesn't suck, and every generation we find rep mov sucks.
> > >
> > > Which only proves Intel don't put much effort in it, and memcpy isn't the
> > > only case, gather sucked for generations until Skylake, Intel really loves
> > > having a lot of poorly implemented instructions, which proves nothing.
> > >
> > > > Which terrible ISAs / implementation are you talking about here?
> > >
> > > About any implementation that have several ifs to choose the
> > > most apropriate case and takes up to a few kB of the I$.
> > >
> > > > If they suck so bad at memcpy
> > > > then they must be even more inefficient to implement all other kinds of data movement that an
> > > > application will do, which (being ~everything except memcpy) is even more common than memcpy.
> > >
> > > No, memcpy is the most common memory operation, the other kind of data movement
> > > is more complex, a situation where there is advantages in doing by software.
> >
> > So Intel doesn't care about the most common memory operation? Are they that incompetent? Or
> > is it just that it is quite difficult to make it fast?
>
>
> Given that they're willing to spend a bazillion transistors on vector extensions that
> matter to hardly anyone*, how hard or costly could a fast memcpy() be? And if there's
> some huge issue with the interface provided by rep/movsb, define a new one.
The hard, sad fact you can't escape is that microcode is not magic. It can not solve any of the hard problems (i.e., unpredictability of control and data use) that normal instructions face.
If you had some amazing magical feature that Linus seems to believe exists in microcode that could instruct the load and store queues and caches "be ready for a transfer of this length" and have them magically do the right thing, then you would just make that available to software. Everything wants the caches and queues to magically do the right thing. The idea that memcpy is the only thing that might care is stupid.
If you had some additional unit or facility in the load/store units that was dedicated to data movement and could do these variable lengths or copies or things faster than the regular LSU instructions, then... you would just make this usable to to the ISA. Rocket science, I know.
Intel does seem to require massive vector registers to get the best LSU performance in some cases, but that seems more like they're being lazy and using rep ; mov as a crutch to try avoid putting proper intelligence into the LSU for larger memory operations. Faced with the likes of AMD and particularly Apple who are really pushing this kind of intelligence into the cores, I don't know how much longer they'll be able to coast on that strategy.
"Oh but rep ; mov is a tiny instruction that helps code size"
Wrong. That microcode has to be stored somewhere. Repeat after me, microcode is not magical. If you want complex instructions to be served very fast from microcode, then you have to store and wire those bits somewhere that could be used by general purpose i-cache. And special purpose caches are rarely superior to general ones, except where implementation constraints make that infeasible (e.g., L1 caches split to be close to their units).
Any time you think microcode can do something magical that a sane ISA can not, pinch yourself and have another think about it.
Yes it is upgraded with your processor. No that's not *such* a vast benefit that it makes the instruction indispensable, or even very interesting at all. A few % improvement on a few % portion of your workload, but you already had to upgrade your libraries and software anyway to get the overall 1,5,10,20% performance improvement that came from new instructions and instruction cost changes anyway.
> none (none.delete@this.none.com) on February 23, 2021 7:37 am wrote:
> > Anon (no.delete@this.spam.com) on February 23, 2021 6:21 am wrote:
> > > anon2 (anon.delete@this.anon.com) on February 23, 2021 4:20 am wrote:
> > > > Apparently not easy for Intel though because they've been at it for years, every generation
> > > > telling us that finally rep mov doesn't suck, and every generation we find rep mov sucks.
> > >
> > > Which only proves Intel don't put much effort in it, and memcpy isn't the
> > > only case, gather sucked for generations until Skylake, Intel really loves
> > > having a lot of poorly implemented instructions, which proves nothing.
> > >
> > > > Which terrible ISAs / implementation are you talking about here?
> > >
> > > About any implementation that have several ifs to choose the
> > > most apropriate case and takes up to a few kB of the I$.
> > >
> > > > If they suck so bad at memcpy
> > > > then they must be even more inefficient to implement all other kinds of data movement that an
> > > > application will do, which (being ~everything except memcpy) is even more common than memcpy.
> > >
> > > No, memcpy is the most common memory operation, the other kind of data movement
> > > is more complex, a situation where there is advantages in doing by software.
> >
> > So Intel doesn't care about the most common memory operation? Are they that incompetent? Or
> > is it just that it is quite difficult to make it fast?
>
>
> Given that they're willing to spend a bazillion transistors on vector extensions that
> matter to hardly anyone*, how hard or costly could a fast memcpy() be? And if there's
> some huge issue with the interface provided by rep/movsb, define a new one.
The hard, sad fact you can't escape is that microcode is not magic. It can not solve any of the hard problems (i.e., unpredictability of control and data use) that normal instructions face.
If you had some amazing magical feature that Linus seems to believe exists in microcode that could instruct the load and store queues and caches "be ready for a transfer of this length" and have them magically do the right thing, then you would just make that available to software. Everything wants the caches and queues to magically do the right thing. The idea that memcpy is the only thing that might care is stupid.
If you had some additional unit or facility in the load/store units that was dedicated to data movement and could do these variable lengths or copies or things faster than the regular LSU instructions, then... you would just make this usable to to the ISA. Rocket science, I know.
Intel does seem to require massive vector registers to get the best LSU performance in some cases, but that seems more like they're being lazy and using rep ; mov as a crutch to try avoid putting proper intelligence into the LSU for larger memory operations. Faced with the likes of AMD and particularly Apple who are really pushing this kind of intelligence into the cores, I don't know how much longer they'll be able to coast on that strategy.
"Oh but rep ; mov is a tiny instruction that helps code size"
Wrong. That microcode has to be stored somewhere. Repeat after me, microcode is not magical. If you want complex instructions to be served very fast from microcode, then you have to store and wire those bits somewhere that could be used by general purpose i-cache. And special purpose caches are rarely superior to general ones, except where implementation constraints make that infeasible (e.g., L1 caches split to be close to their units).
Any time you think microcode can do something magical that a sane ISA can not, pinch yourself and have another think about it.
Yes it is upgraded with your processor. No that's not *such* a vast benefit that it makes the instruction indispensable, or even very interesting at all. A few % improvement on a few % portion of your workload, but you already had to upgrade your libraries and software anyway to get the overall 1,5,10,20% performance improvement that came from new instructions and instruction cost changes anyway.
