From: =?gb18030?B?ODQ3NTY3MTYx?= <847567161@qq.com>
To: =?gb18030?B?bXVzbA==?= <musl@lists.openwall.com>
Subject: [musl] =?gb18030?B?UmWjulJlo7ogW211c2xdIFJlOiBSZTogUmU6IFtQYXRjaCAxLzFdIHZmcHJpbnRmOiBvcHRpbWl6ZSB2ZnByaW50ZiBwZXJmb3JtYW5jZQ==?=
Date: Tue, 16 May 2023 17:32:51 +0800 [thread overview]
Message-ID: <tencent_26B8E38FF26E364CE34C825585599E65E009@qq.com> (raw)
In-Reply-To: <20230515162234.GL4163@brightrain.aerifal.cx>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 4100 bytes --]
> Interesting -- so you're lazily constructing the nl_arg data when you
> first discover the need for it, rather than unconditionally doing the
> first pass to look for it. Do you measure a relevant performance
> difference doing this?
Yes, the benchmark show there are about 30% benefits for commonly used format string.
BM_stdio_printf_s, 160 ns£¨before opt£©, 110 ns £¨after opt£©
static void BM_stdio_printf_s(benchmark::State& state) {
while (state.KeepRunning()) {
char buf[BUFSIZ];
snprintf(buf, sizeof(buf), "this is a more typical error message with detail: %s",
"No such file or directory");
}
}
MUSL_BENCHMARK(BM_stdio_printf_s);
> Stylistically, I like that the patch is minimally invasive and does
> not make complex changes (like what I suggested above) together with
> the intended functional change. I don't really like building up extra
> "special meaning" state like whether nl_arg_ptr is null on top of
> whether f is null to represent what mode the printf_core is operating
> in, but this can/should probably be cleaned up as a separate patch to
> keep the functional change itself simple, like what you've done.
I add nl_arg_filled to indicate whether we have completed the acquisition of parameters.
> On a technical note, some compilers are bad about hoisting large local
> objects out of their scopes when inlining. This results in the large
> floating point buffer from fmt_fp getting allocated at the top of
> printf_core, and presumably causes a recursive call to printf_core to
> double the stack requirements here, which is problematic. I'm not sure
> if we should try to avoid recursion (it should be fairly
> straightforward to do so) or just try to fix the unwanted hoisting to
> begin with (something I've been wanting to do for a while).
I modified buf to be declared when using ranther than at the top of printf_core.
> It looks like these two hunks are almost not needed, since it's not
> allowed to mix positional and non-positional forms.
Thanks£¬ I had changed it in patch.
So musl don't support these format strings, right?
printf("yc test: %*2$d \n", 2, 10);
printf("yc test: %.*2$f \n", 1.123456, 10);
Does "%n$d", "%*n$d" or "%.*n$d" should be used together?
> However, %m does
> not take an argument, but might have width/precision in * form. It'd
> be nice if there were some way to avoid this duplication of logic.
Do you mean "%*m$" or "%.*m$"?
What do you mean "duplication of logic"? I don't get it.
> No check has been made that you haven't already consumed arguments via
> non-positional-form format specifiers. This will make things blow up
> much worse if the caller wrongly mixes them, consuming wrong-type args
> from the wrong positions rather than erroring out (as we do now) or
> trapping (probably ideal). Right now we don't actually catch all forms
> of mixing either, but we do necessarily consume all positional args in
> order before attempting to consume any erroneously-specified
> non-positional ones. Your patch changes this to happen in the order
> things were encountered. So I think, as a first step before even doing
> this patch, we should update the l10n flag to a tri-state thing where
> it can be yes/no/indeterminate, to allow erroring out on any specifier
> that mismatches the existing yes/no.
I remember you mentioned "calling printf with an invalid format
string has undefined behavior" here, so maybe it's also ok.
https://www.openwall.com/lists/musl/2023/05/07/1
Chuang Yin
[-- Attachment #2: optimize_printf_core.diff --]
[-- Type: application/octet-stream, Size: 1970 bytes --]
diff --git a/src/stdio/vfprintf.c b/src/stdio/vfprintf.c
index 9b961e7f..4a01ca1e 100644
--- a/src/stdio/vfprintf.c
+++ b/src/stdio/vfprintf.c
@@ -427,7 +427,7 @@ static int getint(char **s) {
return i;
}
-static int printf_core(FILE *f, const char *fmt, va_list *ap, union arg *nl_arg, int *nl_type)
+static int printf_core(FILE *f, const char *fmt, va_list *ap, union arg *nl_arg, int *nl_type, char nl_arg_filled)
{
char *a, *z, *s=(char *)fmt;
unsigned l10n=0, fl;
@@ -437,7 +437,6 @@ static int printf_core(FILE *f, const char *fmt, va_list *ap, union arg *nl_arg,
unsigned st, ps;
int cnt=0, l=0;
size_t i;
- char buf[sizeof(uintmax_t)*3+3+LDBL_MANT_DIG/4];
const char *prefix;
int t, pl;
wchar_t wc[2], *ws;
@@ -462,6 +461,11 @@ static int printf_core(FILE *f, const char *fmt, va_list *ap, union arg *nl_arg,
if (l) continue;
if (isdigit(s[1]) && s[2]=='$') {
+ if (!nl_arg_filled) {
+ if (printf_core(0, fmt, ap, nl_arg, nl_type, 1) < 0) {
+ return -1;
+ }
+ }
l10n=1;
argpos = s[1]-'0';
s+=3;
@@ -528,6 +532,7 @@ static int printf_core(FILE *f, const char *fmt, va_list *ap, union arg *nl_arg,
if (!f) continue;
+ char buf[sizeof(uintmax_t)*3+3+LDBL_MANT_DIG/4];
z = buf + sizeof(buf);
prefix = "-+ 0X0x";
pl = 0;
@@ -665,10 +670,6 @@ int vfprintf(FILE *restrict f, const char *restrict fmt, va_list ap)
/* the copy allows passing va_list* even if va_list is an array */
va_copy(ap2, ap);
- if (printf_core(0, fmt, &ap2, nl_arg, nl_type) < 0) {
- va_end(ap2);
- return -1;
- }
FLOCK(f);
olderr = f->flags & F_ERR;
@@ -680,7 +681,7 @@ int vfprintf(FILE *restrict f, const char *restrict fmt, va_list ap)
f->wpos = f->wbase = f->wend = 0;
}
if (!f->wend && __towrite(f)) ret = -1;
- else ret = printf_core(f, fmt, &ap2, nl_arg, nl_type);
+ else ret = printf_core(f, fmt, &ap2, nl_arg, nl_type, 0);
if (saved_buf) {
f->write(f, 0, 0);
if (!f->wpos) ret = -1;
prev parent reply other threads:[~2023-05-16 9:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-15 10:04 [musl] Re: Re: Re: [Patch 1/1] vfprintf: optimize vfprintf performance =?gb18030?B?ODQ3NTY3MTYx?=
2023-05-15 16:22 ` Rich Felker
2023-05-16 9:28 ` [musl] =?gb18030?B?UmWjulttdXNsXSBSZTogUmU6IFJlOiBbUGF0Y2ggMS8xXSB2ZnByaW50Zjogb3B0aW1pemUgdmZwcmludGYgcGVyZm9ybWFuY2U=?= =?gb18030?B?ODQ3NTY3MTYx?=
2023-05-16 9:32 ` =?gb18030?B?ODQ3NTY3MTYx?= [this message]
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=tencent_26B8E38FF26E364CE34C825585599E65E009@qq.com \
--to=847567161@qq.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).