Deutsch   English   Français   Italiano  
<jwvh66qtimu.fsf-monnier+comp.arch@gnu.org>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Stefan Monnier <monnier@iro.umontreal.ca>
Newsgroups: comp.arch
Subject: Re: unaligned load/store
Date: Thu, 26 Dec 2024 13:38:04 -0500
Organization: A noiseless patient Spider
Lines: 27
Message-ID: <jwvh66qtimu.fsf-monnier+comp.arch@gnu.org>
References: <memo.20241128153105.12904U@jgd.cix.co.uk>
	<jwvcyi87lva.fsf-monnier+comp.arch@gnu.org>
	<vini47$sgi$1@gal.iecc.com>
	<jwvldww6253.fsf-monnier+comp.arch@gnu.org>
	<vio4ge$1eka$1@gal.iecc.com>
	<jwvmshc49i0.fsf-monnier+comp.arch@gnu.org>
	<9534a1cd1364f2127a1951cc85002f29@www.novabbs.org>
	<lsp0tqFs7aoU1@mid.individual.net>
	<cadda24092db49d26e62096c589fbf9c@www.novabbs.org>
	<vk9us6$pm19$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Thu, 26 Dec 2024 19:38:08 +0100 (CET)
Injection-Info: dont-email.me; posting-host="27a4432ad389d20129f54945a5a43d71";
	logging-data="3265322"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18wHyfhnXityEMUJZsPvvKR/dL7ORERdXY="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:pdHOZkN5JzIP2VEZ/ZfWCgSSB/s=
	sha1:U4YTU60uzMDarXQeS+0H+K9E1gQ=
Bytes: 2567

>> Aligned data is always best, Misaligned data comes at very low cost.
>> SW overhead = 0
> Thinking about this for a bit... for a clean-sheet architecture
> like My66000, could there actually be an advantage to do
> struct layout like the VAX did, with everything aligned on byte
> boundaries?

I highly doubt it.  Making unaligned accesses work efficiently is great,
but that's no reason to abuse them:

- Going back to Mitch's description, in case B.1 the misalignment is
  truly "free", but for B.2, B.3, and B.4 the misalignment does come at
  a cost, not necessarily visible in terms of cycles but at least in
  terms of cache bandwidth, which can have an impact on overall speed
  and energy use.
  Of course, properly aligning your data will also come with costs,
  but "packed structs" don't come totally free.
- AFAIK most efforts to support concurrency take it for granted that
  atomic accesses are supported only when properly aligned.

I expect it's at least as easy (and more portable) to reorder fields by
order of (expected) size to avoid excessive padding in aligned data,
than it is to add manual padding/alignment to avoid the cost of
misalignment in "packed structs".


        Stefan