Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Mon, 16 Sep 2024 16:04:02 +0300
Organization: A noiseless patient Spider
Lines: 61
Message-ID: <20240916160402.0000087f@yahoo.com>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
	<vbcob9$dvp4$1@dont-email.me>
	<vbd6ia$e0ld$2@dont-email.me>
	<UxpCO.174965$Hld5.7714@fx15.iad>
	<vc41rl$1fhjd$1@dont-email.me>
	<2024Sep14.152652@mips.complang.tuwien.ac.at>
	<d93c1dc0455692767c89ea9f7bd47ed1@www.novabbs.org>
	<vc4o0l$1kuqf$1@dont-email.me>
	<vc6vno$285g2$1@dont-email.me>
	<vc8qor$2od9v$1@dont-email.me>
	<vc99fi$2re3k$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Mon, 16 Sep 2024 15:03:37 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7b4ecf2c0b8427f1b1d344bec1b1bd8b";
	logging-data="2968006"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19c+fmHYW9FxaLrIYGxdl6lpAKC1v4waII="
Cancel-Lock: sha1:iLAum+mjO/lGLuTsaTyUulSPcv8=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 3909

On Mon, 16 Sep 2024 14:48:50 +0200
David Brown <david.brown@hesbynett.no> wrote:

> On 16/09/2024 10:37, Terje Mathisen wrote:
> > David Brown wrote: =20
> >> On 14/09/2024 21:26, Thomas Koenig wrote: =20
> >>> MitchAlsup1 <mitchalsup@aol.com> schrieb:
> >>> =20
> >>>> In many cases int is slower now than long -- which violates the
> >>>> notion of int from K&R days. =20
> >>>
> >>> That's a designers's choice, I think.=C2=A0 It is possible to add
> >>> 32-bit instructions which should be as fast (or possibly faster)
> >>> than 64-bit instructions, as AMD64 and ARM have shown.
> >>> =20
> >>
> >> For some kinds of instructions, that's true - for others, it's not
> >> so easy without either making rather complicated instructions or
> >> having assembly instructions with undefined behaviour (imagine the
> >> terror that would bring to some people!).
> >>
> >> A classic example would be for "y =3D p[x++];" in a loop.=C2=A0 For a
> >> 64-bit type x, you would set up one register once with "p + x",
> >> and then have a load with post-increment instruction in the loop.
> >> You can also do that with x as a 32-bit int, unless you are of the
> >> opinion that enough apples added to a pile should give a negative
> >> number of apples.=C2=A0 But with a wrapping type for x - such as
> >> unsigned int in C or modulo types in Ada, you have little choice
> >> but to hold "p" and "x" separately in registers, add them for
> >> every load, and do the increment and modulo operation.=C2=A0 I really
> >> can't see this all being handled by a single instruction. =20
> >=20
> > This becomes much simpler in Rust where usize is the only legal
> > index type:
> >=20
> > Yeah, you have to actually write it as
> >=20
> >  =C2=A0 y =3D p[x];
> >  =C2=A0 x +=3D 1;
> >=20
> > instead of a single line, but this makes zero difference to the=20
> > compiler, right?
> >  =20
>=20
> I don't care much about the compiler - but I don't think this is an=20
> 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.)
>=20
> And the resulting object code is less efficient than you get with
> signed int and "y =3D p[x++];" (or "y =3D p[x]; x++;") in C.
>=20
>=20
>=20

It's not less efficient. usize in Rust is approximately the same as
size_t in C. With one exception that usize overflow panics under debug
build.