From: Xan Phung <xan.phung@gmail.com>
To: musl@lists.openwall.com
Subject: Re: stdio glitch & questions
Date: Sat, 1 Dec 2018 09:15:56 +1100 [thread overview]
Message-ID: <CAO6moYvBB0Lb+g23hb0hc=WXsXoACtnSBjvQ7fSep-0Zky=W_g@mail.gmail.com> (raw)
In-Reply-To: <20181130160951.GS23599@brightrain.aerifal.cx>
[-- Attachment #1: Type: text/plain, Size: 2144 bytes --]
Thanks for the quick answer, and I've taken a look at the pre-2011 fwrite.c
code, and using SYS_writev is indeed much cleaner code!
See below on my proposed answer to your question about what the "cutoff"
should be for copying. (SYS_writev is fully retained, but the 2nd iovec
element will very often be zero length in this proposal, which makes
emulation of SYS_writev much more efficient).
On Sat, 1 Dec 2018 at 03:10, Rich Felker <dalias@libc.org> wrote:
>
> It would probably be welcome to make __stdio_write make use of
> SYS_write when it would be expected to be faster (len very small), but
> I'm not sure what the exact cutoff should be.
>
>
My proposal is the cutoff be 5-8 bytes (on 32 bit CPUs) , and on 64 bit
CPUs, 9-16 bytes.
The cutoffs are selected in such a way that the "no copy" loop (searching
for '\n') always ends on a word aligned position (opening the door to
future optimisations by using word-at-a-time search for '\n' instead of
byte-at-a-time). The "copy" branch is also guaranteed to only be a double
word at most, but a minimum of a single word (allowing a two word memcpy to
be done with just a 2x load/mask/store word code sequence). Some example
code is shown to give a general idea of word-aligning the cutoff amount
(but not yet doing word-at-a-time searching of '\n', or optimised two word
memcpy).
*CURRENT __fwritex.c CODE (lines 12-20)*:
if (f->lbf >= 0) {
/* Match /^(.*\n|)/ */
for (i=l; i && s[i-1] != '\n'; i--);
if (i) {
size_t n = f->write(f, s, i);
if (n < i) return n;
s += i;
l -= i;
}
}
*PROPOSED*:
size_t i, len;
if (f->lbf >= 0) {
const unsigned char *t = ALIGN(s+sizeof(size_t)*2);
for (i = l+s-t; ; i--) {
if (i <= 0) { /* SHORT LINE - copy up to 16 bytes into f->wpos
buffer and then flush line */
for (j = t-s; j && s[j-1] != '\n'; j--);
if (j) {
memcpy(f->wpos, s, j); f->wpos += j;
size_t n = f->write(f, t, 0);
if (n < 0) return n;
s += j;
l -= j;
} break;
}
if (t[i-1] == '\n') {
size_t n = f->write(f, s, len = i+t-s);
if (n < len) return n;
s += len;
l -= len;
break;
}
}
}
[-- Attachment #2: Type: text/html, Size: 6864 bytes --]
next prev parent reply other threads:[~2018-11-30 22:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-30 10:51 Xan Phung
2018-11-30 16:09 ` Rich Felker
2018-11-30 22:15 ` Xan Phung [this message]
2018-12-01 0:02 ` Rich Felker
2018-12-01 2:42 ` Xan Phung
2018-12-01 3:17 ` Rich Felker
2018-12-01 8:02 ` Xan Phung
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='CAO6moYvBB0Lb+g23hb0hc=WXsXoACtnSBjvQ7fSep-0Zky=W_g@mail.gmail.com' \
--to=xan.phung@gmail.com \
--cc=musl@lists.openwall.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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
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).