From: Jan Beulich <jbeulich@suse.com>
To: Indu Bhagat <indu.bhagat@oracle.com>
Cc: "linux-toolchains@vger.kernel.org"
<linux-toolchains@vger.kernel.org>,
Jens Remus <jremus@linux.ibm.com>,
Sterling Augustine <saugustine@google.com>,
Pavel Labath <labath@google.com>,
Andrii Nakryiko <andrii@kernel.org>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Serhei Makarov <smakarov@redhat.com>,
Binutils <binutils@sourceware.org>
Subject: Re: Unaligned access trade-offs for SFrame FRE layout
Date: Sun, 14 Sep 2025 16:14:33 +0200 [thread overview]
Message-ID: <9d104c46-855c-4b36-8226-1f59b59e455c@suse.com> (raw)
In-Reply-To: <b7b139c6-1963-4ffc-a872-518010a50563@oracle.com>
On 12.09.2025 19:34, Indu Bhagat via Binutils wrote:
> TL;DR: Thinking and experimenting a bit on the possible approaches for
> avoiding unaligned accesses in the SFrame FRE layout (in SFrame V3), I
> am not convinced that avoiding unaligned accesses for performance is
> worth it. IMO, forsaking compactness for avoiding unaligned accesses is
> not a good trade off for SFrame.
>
> Problem Statement
> On architectures such as x86_64, AArch64, and s390x, unaligned memory
> accesses are handled transparently by the hardware but incur a
> performance penalty.
As you say in a reply, may incur. However, shouldn't we also consider
possible ports of SFrame to architectures which don't handle this as
transparently? Off the top of my head I don't, for example, recall
whether RISC-V requires unaligned accesses to be handled transparently
by the hardware.
Jan
next prev parent reply other threads:[~2025-09-14 14:14 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-12 17:34 Unaligned access trade-offs for SFrame FRE layout Indu Bhagat
2025-09-12 18:19 ` Segher Boessenkool
2025-09-12 19:18 ` Steven Rostedt
2025-09-13 7:56 ` Indu Bhagat
2025-09-15 16:04 ` Steven Rostedt
[not found] ` <CAEG7qUxk_cZYv3X_VM6+ZGaVFAD-7jdPd3xA92xYHUAqyzb2Xw@mail.gmail.com>
2025-09-13 8:01 ` Indu Bhagat
2025-09-14 14:14 ` Jan Beulich [this message]
2025-09-14 14:39 ` Rainer Orth
2025-09-14 15:23 ` Jan Beulich
2025-09-14 16:18 ` Rainer Orth
2025-09-14 18:10 ` Jan Beulich
2025-09-15 5:42 ` Indu Bhagat
2025-09-15 16:07 ` Steven Rostedt
2025-09-15 17:22 ` Segher Boessenkool
2025-09-16 6:05 ` Fangrui Song
2025-09-16 15:58 ` Steven Rostedt
2025-09-18 10:39 ` Jens Remus
2025-09-16 16:03 ` Indu Bhagat
2025-09-16 16:32 ` Fangrui Song
2025-09-16 16:44 ` Segher Boessenkool
2025-09-16 17:05 ` Fangrui Song
2025-09-16 17:54 ` Segher Boessenkool
2025-09-16 17:33 ` Indu Bhagat
2025-09-17 21:12 ` Steven Rostedt
2025-09-17 23:55 ` Alan Modra
2025-09-15 9:08 ` Segher Boessenkool
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9d104c46-855c-4b36-8226-1f59b59e455c@suse.com \
--to=jbeulich@suse.com \
--cc=andrii@kernel.org \
--cc=binutils@sourceware.org \
--cc=indu.bhagat@oracle.com \
--cc=jpoimboe@kernel.org \
--cc=jremus@linux.ibm.com \
--cc=labath@google.com \
--cc=linux-toolchains@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=saugustine@google.com \
--cc=smakarov@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).