mailing list of musl libc
 help / color / mirror / code / Atom feed
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 --]

&gt; Interesting -- so you're lazily constructing the nl_arg data when you
&gt; first discover the need for it, rather than unconditionally doing the
&gt; first pass to look for it. Do you measure a relevant performance
&gt; 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&amp; 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);


&gt; Stylistically, I like that the patch is minimally invasive and does
&gt; not make complex changes (like what I suggested above) together with
&gt; the intended functional change. I don't really like building up extra
&gt; "special meaning" state like whether nl_arg_ptr is null on top of
&gt; whether f is null to represent what mode the printf_core is operating
&gt; in, but this can/should probably be cleaned up as a separate patch to
&gt; 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.

&gt; On a technical note, some compilers are bad about hoisting large local
&gt; objects out of their scopes when inlining. This results in the large
&gt; floating point buffer from fmt_fp getting allocated at the top of
&gt; printf_core, and presumably causes a recursive call to printf_core to
&gt; double the stack requirements here, which is problematic. I'm not sure
&gt; if we should try to avoid recursion (it should be fairly
&gt; straightforward to do so) or just try to fix the unwanted hoisting to
&gt; 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.

&gt; It looks like these two hunks are almost not needed, since it's not
&gt; 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?

&gt; However, %m does
&gt; not take an argument, but might have width/precision in * form. It'd
&gt; 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.

&gt; No check has been made that you haven't already consumed arguments via
&gt; non-positional-form format specifiers. This will make things blow up
&gt; much worse if the caller wrongly mixes them, consuming wrong-type args
&gt; from the wrong positions rather than erroring out (as we do now) or
&gt; trapping (probably ideal). Right now we don't actually catch all forms
&gt; of mixing either, but we do necessarily consume all positional args in
&gt; order before attempting to consume any erroneously-specified
&gt; non-positional ones. Your patch changes this to happen in the order
&gt; things were encountered. So I think, as a first step before even doing
&gt; this patch, we should update the l10n flag to a tri-state thing where
&gt; it can be yes/no/indeterminate, to allow erroring out on any specifier
&gt; 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;

      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).