By: anon2 (anon.delete@this.anon.com), February 23, 2021 3:51 pm
Room: Moderated Discussions
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,
It proves no such thing.
But even if it did, you contradict yourself: "easy to implement in hardware" means not much effort is required. By definition.
> 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.
That's got nothing to do with what we were talking about. Your definition of "proof" appears to be conveniently flexible too.
>
> > 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$.
Imagine being pleased about your shitty hardware microcode not even being able to beat the worst possible software implementation of memcpy imaginable. Wow.
>
> > 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.
>
No, you just misunderstood me. I didn't say there was a more common memory operation than memcpy, I said all other memory operations are more common than memcpy.
So you concede your slow core with a crappy memcpy microcode is too stupid to even cope with plain loads and stores (heaven forbid it might have to do a simple ALU instruction of work on the data, oh the complexity!) Sounds like a good model to avoid.
> 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,
It proves no such thing.
But even if it did, you contradict yourself: "easy to implement in hardware" means not much effort is required. By definition.
> 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.
That's got nothing to do with what we were talking about. Your definition of "proof" appears to be conveniently flexible too.
>
> > 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$.
Imagine being pleased about your shitty hardware microcode not even being able to beat the worst possible software implementation of memcpy imaginable. Wow.
>
> > 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.
>
No, you just misunderstood me. I didn't say there was a more common memory operation than memcpy, I said all other memory operations are more common than memcpy.
So you concede your slow core with a crappy memcpy microcode is too stupid to even cope with plain loads and stores (heaven forbid it might have to do a simple ALU instruction of work on the data, oh the complexity!) Sounds like a good model to avoid.
