mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Evan Green' <evan@rivosinc.com>, Jessica Clarke <jrtc27@jrtc27.com>
Cc: Palmer Dabbelt <palmer@rivosinc.com>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	Yangyu Chen <cyy@cyyself.name>,
	Conor Dooley <conor.dooley@microchip.com>,
	Guo Ren <guoren@kernel.org>, Jisheng Zhang <jszhang@kernel.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	Xianting Tian <xianting.tian@linux.alibaba.com>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Greentime Hu <greentime.hu@sifive.com>,
	Simon Hosie <shosie@rivosinc.com>,
	Li Zhengyu <lizhengyu3@huawei.com>,
	Andrew Jones <ajones@ventanamicro.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alexghiti@rivosinc.com>,
	"Ley Foon Tan" <leyfoon.tan@starfivetech.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Heiko Stuebner <heiko.stuebner@vrull.eu>,
	Anup Patel <apatel@ventanamicro.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Sia Jee Heng <jeeheng.sia@starfivetech.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Andy Chiu <andy.chiu@sifive.com>
Subject: RE: [PATCH 1/2] RISC-V: Probe for unaligned access speed
Date: Thu, 29 Jun 2023 12:05:14 +0000	[thread overview]
Message-ID: <53dc6959cc8849d6b66676ad48c1376a@AcuMS.aculab.com> (raw)
In-Reply-To: <CALs-HssZG8daTJaRK8JPT0VRk=23CtO6B_5kq4Xa_DdLELjaZw@mail.gmail.com>

From: Evan Green
> Sent: 27 June 2023 20:12
> 
> On Mon, Jun 26, 2023 at 2:42 PM Jessica Clarke <jrtc27@jrtc27.com> wrote:
> >
> > On 23 Jun 2023, at 23:20, Evan Green <evan@rivosinc.com> wrote:
> > >
> > > Rather than deferring misaligned access speed determinations to a vendor
> > > function, let's probe them and find out how fast they are. If we
> > > determine that a misaligned word access is faster than N byte accesses,
> > > mark the hardware's misaligned access as "fast".
> >
> > How sure are you that your measurements can be extrapolated and aren’t
> > an artefact of the testing process? For example, off the top of my head:
> >
> > * The first run will potentially be penalised by data cache misses,
> >   untrained prefetchers, TLB misses, branch predictors, etc. compared
> >   with later runs. You have one warmup, but who knows how many
> >   iterations it will take to converge?
> 
> I'd expect the cache penalties to be reasonably covered by a single
> warmup. You're right about branch prediction, which is why I tried to
> use a large-ish buffer size, minimize the ratio of conditionals to
> loads/stores, and do the test for a decent number of iterations (on my
> THead, about 1800 and 400 for words and bytes).
> 
> When I ran the test a handful of times, I did see variation on the
> order of ~5%. But the comparison of the two numbers doesn't seem to be
> anywhere near that margin (THead C906 was ~4x faster doing misaligned
> word accesses, others with slow misaligned accesses also reporting
> numbers not anywhere close to each other).

Isn't the EMULATED case so much slower than anything else that
it is even pretty obvious from a single access?
(Possibly the 2nd access to avoid 'cold cache'.)

One of the things that can perturb measurements is hardware
interrupts. That can be mitigated by counting clocks for a few
(10 is plenty) iterations of a short request and taking the
fastest value.
For short hot-cache code sequences you can actually compare the
actual clock counts with theoretical minimum values.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

  reply	other threads:[~2023-06-29 12:06 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-23 22:20 [PATCH 0/2] RISC-V: Probe for misaligned " Evan Green
2023-06-23 22:20 ` [PATCH 1/2] RISC-V: Probe for unaligned " Evan Green
2023-06-25 21:42   ` David Laight
2023-06-26 14:14   ` Conor Dooley
2023-06-27 19:11     ` Evan Green
2023-06-29 14:03       ` Conor Dooley
2023-06-29 23:10         ` Evan Green
2023-06-26 21:42   ` Jessica Clarke
2023-06-27 19:11     ` Evan Green
2023-06-29 12:05       ` David Laight [this message]
2023-06-29 23:09         ` Evan Green
2023-06-30  8:29           ` David Laight
2023-06-23 22:20 ` [PATCH 2/2] RISC-V: alternative: Remove feature_probe_func Evan Green
2023-06-26 13:07   ` Conor Dooley
2023-06-30 21:57     ` Evan Green
2023-06-24 10:08 ` [PATCH 0/2] RISC-V: Probe for misaligned access speed Conor Dooley
2023-06-26 19:48   ` Evan Green
2023-06-24 10:22 ` Yangyu Chen
2023-06-26  9:24   ` David Laight
2023-06-26 19:49     ` Evan Green
2023-06-26 19:48   ` Evan Green

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=53dc6959cc8849d6b66676ad48c1376a@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=ajones@ventanamicro.com \
    --cc=alexghiti@rivosinc.com \
    --cc=andy.chiu@sifive.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=apatel@ventanamicro.com \
    --cc=conor.dooley@microchip.com \
    --cc=corbet@lwn.net \
    --cc=cyy@cyyself.name \
    --cc=evan@rivosinc.com \
    --cc=greentime.hu@sifive.com \
    --cc=guoren@kernel.org \
    --cc=heiko.stuebner@vrull.eu \
    --cc=jeeheng.sia@starfivetech.com \
    --cc=jrtc27@jrtc27.com \
    --cc=jszhang@kernel.org \
    --cc=leyfoon.tan@starfivetech.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=lizhengyu3@huawei.com \
    --cc=masahiroy@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=palmer@rivosinc.com \
    --cc=paul.walmsley@sifive.com \
    --cc=shosie@rivosinc.com \
    --cc=xianting.tian@linux.alibaba.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

all inboxes | Powered by JetHome®