Liste des Groupes | Revenir à c arch |
On Tue, 17 Sep 2024 11:48:12 +0200That's it, yes. It's not the access that is slower for 32-bit x, it's using it later after the increment because the increment has to be wrapped.
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
David Brown wrote:Taken in isolation, on something like x86=64 or aarch64, where resultOn 17/09/2024 08:07, Terje Mathisen wrote:>David Brown wrote:>On 16/09/2024 10:37, Terje Mathisen wrote:>This becomes much simpler in Rust where usize is the only legal>
index type:
>
Yeah, you have to actually write it as
>
 Â y = p[x];
 Â x += 1;
>
instead of a single line, but this makes zero difference to the
compiler, right?
I don't care much about the compiler - but I don't think this is
an improvement for the programmer. (In general, I dislike
trying to do too much in a single expression or statement, but
some C constructs are common enough that I am happy with them.Â
It would be hard to formulate concrete rules here.)
>
And the resulting object code is less efficient than you get with
signed int and "y = p[x++];" (or "y = p[x]; x++;") in C.
Is that true? I'll have to check godbolt myself if that is really
the case!
It is not true - or at least, it shouldn't be true. I had thought
the Rust code was using the equivalent of a C "unsigned int" here,
which would require extra code for wrapping semantics. But that
was just my misunderstanding of Rust and its types - with a 64-bit
unsigned type, it should give the same results as C. However,
there's no harm in checking it and letting us know.
No need to check this particular point, Rust's usize was obviously
designed to be an unsigned type large enough to index into the entire
addressable memory range, so on a 64-bit platform it has to be 64
bits.>That's actually surprising to me, I would have guessed any 32-bit
(I've previously shown how "y = p[x++];" in C is less efficient on
x86-64 if x is "unsigned int", compared to "int" or 64-bit types
for x.)
index would be less efficient than a full-width type, but if the
idionm is very, very common in C code, then it makes sense to make it
fast.
>
Doing so would typically require either sign- or zero-extending all
32-bit variables when loaded into a 64-bit register, right?
>
Terje
>
of 32-bit addition is by default zero-extended, there is no difference
between 32-bit and 64-bit unsigned x.
However when statement shown above is part of the sequence, even short
one, 64-bit x allows compiler optimizations that are impossible with
32-bit.
E.g.
y1 = p[x++]
y2 = p[x++]
On x86-64 with 64-bit x the second load can be implemented as
mov dstreg, [rcx+rdx*4+4]
On aarch64 with 64-bit x both loads can be folded into single 'load
pair' instruction.
Les messages affichés proviennent d'usenet.