From: David Laight <David.Laight@ACULAB.COM>
To: "'Maciej W. Rozycki'" <macro@orcam.me.uk>,
Tiezhu Yang <yangtiezhu@loongson.cn>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Xuefeng Li <lixuefeng@loongson.cn>
Subject: RE: [PATCH v2] MIPS: Check __clang__ to avoid performance influence with GCC in csum_tcpudp_nofold()
Date: Wed, 17 Mar 2021 16:09:17 +0000 [thread overview]
Message-ID: <6e7bc85a3f92419f89117fc1381511be@AcuMS.aculab.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2103171541590.21463@angie.orcam.me.uk>
From: Maciej W. Rozycki
> Sent: 17 March 2021 15:36
..
> > > Not that I grok the mips opcodes.
> > > But that code has horridness on its side.
>
> It's a 32-bit one's-complement addition. The use of 64-bit operations
> reduces the number of calculations as any 32-bit carries accumulate in the
> high 32-bit word allowing one instruction to be saved total compared to
> the 32-bit variant. Nothing particularly unusual for me here; I've seen
> worse stuff with x86.
The 'problem' is that mips doesn't have a carry flag.
So the 64-bit maths is 'tricky'.
It may well be that a loop based on:
do {
val = *ptr++;
sum += val;
carry += sum < val;
} while (ptr != limit)
will generate much better code.
I think there is a 'setlt' instruction for the compare.
It certainly would on the nios (which is mips-like).
That is (probably) 6 instructions for 4 bytes.
I suspect there may be a data stall after the memory read.
So an interleaved unroll would remove that stall.
That would be 10 clocks for 8 bytes.
The x86-64 code is 'interesting'.
It has repeated 'add carry' instructions.
On Intel cpus prior to (at least) Haswell they take two clocks each.
So the code is no faster than adding 32bit values to a 64bit sum.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2021-03-17 16:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-09 4:18 Tiezhu Yang
2021-03-14 20:49 ` Maciej W. Rozycki
2021-03-15 12:26 ` Tiezhu Yang
2021-03-15 12:42 ` David Laight
2021-03-17 0:26 ` Tiezhu Yang
2021-03-17 15:35 ` Maciej W. Rozycki
2021-03-17 16:09 ` David Laight [this message]
2021-03-17 21:36 ` Maciej W. Rozycki
2021-03-15 10:24 ` Alexander Lobakin
2021-03-15 12:10 ` Tiezhu Yang
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=6e7bc85a3f92419f89117fc1381511be@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=lixuefeng@loongson.cn \
--cc=macro@orcam.me.uk \
--cc=tsbogend@alpha.franken.de \
--cc=yangtiezhu@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®