Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.arch Subject: Re: Optimization by programmers Date: Mon, 28 Sep 2026 02:59:06 -0700 Organization: A noiseless patient Spider Lines: 45 Message-ID: <86bj9hr91x.fsf@linuxsc.com> References: <1177fdi$26ea4$1@dont-email.me> <2026Sep13.162747@mips.complang.tuwien.ac.at> <118h4cj$fi2a$1@dont-email.me> <2026Sep19.082513@mips.complang.tuwien.ac.at> <2026Sep21.191719@mips.complang.tuwien.ac.at> <118tshf$r2kv$1@dont-email.me> <118uv1g$18lk0$1@dont-email.me> <86pky4rpmb.fsf@linuxsc.com> <1193dsi$2pbdi$1@dont-email.me> <868q4qsjdy.fsf@linuxsc.com> <11969ba$3lmsq$5@dont-email.me> <119b6fd$1buj2$1@dont-email.me> <20260927181805.0000132e@yahoo.com> <119bepl$1fl0g$1@dont-email.me> <20260927194301.0000194f@yahoo.com> <86mrt2r33i.fsf@linuxsc.com> <119btc7$1n32h$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Mon, 28 Sep 2026 09:59:07 +0000 (UTC) Injection-Info: dont-email.me; logging-data="2328839"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18DE5XtbQuE6d6ec163ClY9cOZ3fMrQUfA="; posting-host="c8eafada0e624169865912be13036e37" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:Attvdzlc2ilZ6gyJZcEaYccJw20= sha1:3F6IUf9UWz/Yobf/Zh9Zzgr6TVQ= sha256:937KtHSC9rhIIDsJj3dadtlXI3GUt3FhScsiHUrEXy8= sha1:DKhN5zIUiwv/uv0r7dsatSrKFh8= sha256:vVODjl63MO5FLzm/3uxIIJKcNyQbkltVJ1RYIgGDdHk= Xref: csiph.com comp.arch:118285 Terje Mathisen writes: > Tim Rentsch wrote: > >> Michael S writes: >> >>> On Sun, 27 Sep 2026 18:04:05 +0200 >>> David Brown wrote: >>> >>>> On 27/09/2026 17:18, Michael S wrote: >>>> >>>>> Fortran is not the same as C. >>>>> My understanding is that in Fortran array indexes are by default >>>>> 32-bit. That couses real cost under wrapv. >>>>> In C there is no such thing as default size of array index. The >>>>> programmer can define it as 32-bit and suffer the same performance >>>>> degradatioon under wrapv as Fortran does. Or he can define index as >>>>> either ptrdiff_t or size_t and suffere no degradation. >>>> >>>> You certainly /can/ do that. But a lot of C code uses "int" for >>>> array indexing. The "ideal" type in many cases would be >>>> "int_fast32_t" to say it should be of a big enough size (32-bit is >>>> enough range for a great many purposes) but can bigger if that's >>>> faster. On most 64-bit targets, "int_fast32_t" will be 64-bit. >>> >>> That's not universal. >>> For example, on both alive 64-bit Windows targets int_fast32_t is >>> 32-bit. >>> Godbolt shows the same for clang for MIPS64. I have no idea what OS it >>> targets. >>> >>> Besides, int_fast32_t is both above my threshold of acceptable ugliness >>> and acceptable geekery. >> >> I favor a type equivalent to size_t for use as array index variables. > > In Rust, the only acceptable array index is of type "usize", which is > effectively the same as u64 on most platforms these days, but does not > need to be so: On a 32-bit target, it would be the same as u32. > > So effectively very similar to size_t. Maybe that limitation works okay in Rust. In C sometimes it's important to allow a signed value for indexing. Probably 99% of the time size_t is good, but not always.