From: David Laight <David.Laight@ACULAB.COM>
To: 'maobibo' <maobibo@loongson.cn>, Huacai Chen <chenhuacai@kernel.org>
Cc: WANG Xuerui <kernel@xen0n.name>,
Jiaxun Yang <jiaxun.yang@flygoat.com>,
"loongarch@lists.linux.dev" <loongarch@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v2] LoongArch: add checksum optimization for 64-bit system
Date: Thu, 16 Feb 2023 09:03:08 +0000 [thread overview]
Message-ID: <8bc06b0ef9c243b087e944e0611b54b5@AcuMS.aculab.com> (raw)
In-Reply-To: <0d591c10-e897-d00a-dbf0-a069389ef196@loongson.cn>
From: maobibo
> Sent: 14 February 2023 14:19
...
> Got it. It makes use of pipeline better, rather than number of ALUs for
> different micro-architectures. I will try this method, thanks again for
> kindly help and explanation with patience.
It is also worth pointing out that if the cpu does 'out of order'
execution it may be just as good to just repeat blocks of:
load v0, addr, 0*8
add sum0, v0
sltu v0, sum0, v0
add carry0, v0
Assuming the prefetch/decode logic can predict the loop
and generate enough decoded instruction for all the alu units.
The add/sltu/add will be queued until the load completes
and then execute in the next three clocks.
The load for the next block will be scheduled as soon as
the load/store unit has finished processing the previous load.
So all the alu instructions just wait for the required input
to be available and a memory load executes every clock.
Multiple sum0 and carry0 registers aren't actually needed.
But having 2 of each (even if the loop is unrolled 4 times)
might help a bit.
If the cpu does 'register renaming' (as most x86 do) you
can use the same register name for 'v0' in all the blocks
(even though it is alive with multiple values).
But a simpler in-order multi-issue cpu will need you to
correctly interleave the instructions for maximum throughput.
It also does no hard for a very simple cpu that has delays
before a read value can be used.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2023-02-16 9:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-09 3:58 Bibo Mao
2023-02-09 9:35 ` David Laight
2023-02-09 11:55 ` maobibo
2023-02-09 12:39 ` David Laight
2023-02-10 3:21 ` Huacai Chen
2023-02-10 7:12 ` maobibo
2023-02-10 10:06 ` maobibo
2023-02-10 11:08 ` David Laight
2023-02-10 13:30 ` maobibo
2023-02-14 1:31 ` maobibo
2023-02-14 9:47 ` David Laight
2023-02-14 14:19 ` maobibo
2023-02-16 9:03 ` David Laight [this message]
2023-02-16 9:26 ` maobibo
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=8bc06b0ef9c243b087e944e0611b54b5@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=chenhuacai@kernel.org \
--cc=jiaxun.yang@flygoat.com \
--cc=kernel@xen0n.name \
--cc=linux-kernel@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=maobibo@loongson.cn \
/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®