[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260513165450.35c13656@eclair>
Date: Wed, 13 May 2026 16:54:50 +0200
From: Joakim Sindholt <opensource@...sha.com>
To: musl@...ts.openwall.com
Subject: Re: musl multi-level table format for binary locale images
On Wed, 13 May 2026 08:28:17 -0400, Rich Felker <dalias@...c.org> wrote:
> On Wed, May 13, 2026 at 01:06:56PM +0200, Szabolcs Nagy wrote:
> > btw if this is a mappable format, then wouldn't little-endian repr
> > be better for most cpus? so get32 is optimized to a single load
> > (nowadays even unaligned loads are efficient, so compilers emit
> > them)
>
> My choice of big endian was purely aesthetic, in that I prefer it for
> on-disk/on-the-wire formats. It's the conventional default there, and
> conveys the sense that "this is serialized bytes, not a native integer
> you can access directly" so that the portability error is immediately
> apparent on mainstream archs if you try to do that.
It's also just easier to read when manually slogging through a binary
dump.
> If this is really the bottleneck I wouldn't be opposed to changing it,
> but I think bswap is basically free and the rest of the operation
> (mainly, chasing pointers/cache lines/TLBs) dominates the runtime.
You can keep it big endian with a clean conscience. Compilers have been
smart enough to turn this pattern into a single load and optional byte
swap for a long time now.
https://godbolt.org/z/d6vGeEEE8
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
