Ross Ridge writes:
The entire parsing of the format string is affected by the multi-byte
> character encoding. I don't know how GCC would be able tell that a byte
> with the same value as '%' in the middle of string would actually be
> interpreted as '%' character rather than a part of an extende
[EMAIL PROTECTED] (Ross Ridge) writes:
> I don't think that's true, but regardless many systems have runtime
> character sets that are dependent on locale. If GCC doesn't support this,
> then GCC is broken.
Geoffrey Keating writes:
> I don't think it's unreasonable to insist that you tell the com
On Thu, Oct 11, 2007 at 07:57:57PM -0400, [EMAIL PROTECTED] wrote:
> Heikki Linnakangas writes:
> >The only features in the printf-family of functions that depends on the
> >locale are the conversion with thousand grouping ("%'d"), and glibc
> >extension of using locale's alternative output digits
[EMAIL PROTECTED] (Ross Ridge) writes:
> Ross Ridge writes:
> >The compiler can't in general know what encoding that printf, fprintf,
> >and sprintf will use to parse the string. It's locale dependent.
>
> Paolo Bonzini writes:
> >It is undefined what happens if you run a program in a different
Ross Ridge wrote:
>The compiler can't in general know what encoding that printf, fprintf,
>and sprintf will use to parse the string. It's locale dependent.
Bernd Schmidt writes:
>Does this mean it can vary from one run of the program to another?
Yes, that's the whole point having locales. So a
Ross Ridge wrote:
> The compiler can't in general know what encoding that printf, fprintf,
> and sprintf will use to parse the string. It's locale dependent.
Does this mean it can vary from one run of the program to another? I'll
admit I don't understand locales very well, but doesn't this sound
Ross Ridge writes:
>The compiler can't in general know what encoding that printf, fprintf,
>and sprintf will use to parse the string. It's locale dependent.
Paolo Bonzini writes:
>It is undefined what happens if you run a program in a different charset
>than in the one you specified for -fexec-ch
Andreas Schwab writes:
The compiler is supposed to know the encoding of the strings.
The compiler can't in general know what encoding that printf, fprintf,
and sprintf will use to parse the string. It's locale dependent.
It is undefined what happens if you run a program in a different char
[EMAIL PROTECTED] (Ross Ridge) writes:
> The entire parsing of the format string is affected by the multi-byte
> character encoding. I don't know how GCC would be able tell that a byte
> with the same value as '%' in the middle of string would actually be
> interpreted as '%' character rather than
Andreas Schwab wrote:
[EMAIL PROTECTED] (Ross Ridge) writes:
The entire parsing of the format string is affected by the multi-byte
character encoding. I don't know how GCC would be able tell that a byte
with the same value as '%' in the middle of string would actually be
interpreted as '%' cha
[EMAIL PROTECTED] (Ross Ridge) writes:
> The entire parsing of the format string is affected by the multi-byte
> character encoding. I don't know how GCC would be able tell that a byte
> with the same value as '%' in the middle of string would actually be
> interpreted as '%' character rather tha
Heikki Linnakangas writes:
>The only features in the printf-family of functions that depends on the
>locale are the conversion with thousand grouping ("%'d"), and glibc
>extension of using locale's alternative output digits ("%Id").
The entire parsing of the format string is affected by the multi
On 2007-10-10, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> The only features in the printf-family of functions that depends on the
> locale are the conversion with thousand grouping ("%'d"), and glibc
> extension of using locale's alternative output digits ("%Id").
And those dealing with float
On Wed, Oct 10, 2007 at 04:22:45PM -0400, Kaveh R. GHAZI wrote:
> > But these things are rarely going to be a huge win, and I get
> > the impression that competing compiler developers only do them
> > when they help with standard benchmarks.
>
> Their loss. I agree with avoiding these micro opts
On Wed, 10 Oct 2007, Joe Buck wrote:
> On Wed, Oct 10, 2007 at 12:12:25AM -0400, Kaveh R. GHAZI wrote:
> > One simplification I don't believe we do yet, that should always be a win,
> > is turning: sprintf (foo, "%c", bar); into:*foo = bar;
>
> You need the null terminator: foo[0] = bar; f
On Wed, Oct 10, 2007 at 12:12:25AM -0400, Kaveh R. GHAZI wrote:
> One simplification I don't believe we do yet, that should always be a win,
> is turning: sprintf (foo, "%c", bar); into:*foo = bar;
You need the null terminator: foo[0] = bar; foo[1] = 0;
But these things are rarely going to
Joe Buck wrote:
> If your program has one or two dominant sprintf calls (as in the example
> that motivated this exercise), it pays off. But for a large program with
> thousands of {,s,f}printf calls, this kind of code size expansion could
> easily hurt instead of help. Without some data showing
Kaveh R. GHAZI wrote:
> On Mon, 8 Oct 2007, Heikki Linnakangas wrote:
>
>> sprintf(dest, "%d", arg1); -> a new function that does the same thing,
>> but without the overhead of parsing the format string. Like itoa on some
>> platforms. We could inline it as well. That would allow further
>> optimi
On Mon, 8 Oct 2007, Heikki Linnakangas wrote:
> sprintf(dest, "%d", arg1); -> a new function that does the same thing,
> but without the overhead of parsing the format string. Like itoa on some
> platforms. We could inline it as well. That would allow further
> optimizations, if for example the co
On Tue, Oct 09, 2007 at 09:46:35PM +0100, Heikki Linnakangas wrote:
> Essentially,
>
> sprintf(dest, "%d-%d-%d", a, b, c);
>
> is transformed into:
>
> dest += sprintf_prim_d(dest, a);
> *(dest++) = '-';
> dest += sprintf_prim_d(dest, b);
> *(dest++) = '-';
> dest += sprintf_prim_d(dest, c);
>
Denys Vlasenko <[EMAIL PROTECTED]> writes:
> /* Fast path for "...%s...%s...%s..." */
> while (p[1] == 's') {
That does not handle multibyte characters.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key finge
Denys Vlasenko wrote:
> On Tuesday 09 October 2007 20:48, Heikki Linnakangas wrote:
>> but it does beat glibc (5.20s) by a wide margin.
>> However, preparsing the format string in gcc still beats the linux
>> version hands down (0.82s).
>
> You preparse "%d-%d-%d"? Into what?
Essentially,
sprin
On Tuesday 09 October 2007 20:48, Heikki Linnakangas wrote:
> The new linux code is slightly but not much faster than the old one
> (3.04s vs 3.16s),
Test on my machine (three runs)
$ time ./sprintf-linux
./sprintf-linux 10-70-110
user0m2.018s
user0m2.024s
user0m1.997s
$ time ./sprin
Denys Vlasenko wrote:
> On Monday 08 October 2007 16:08, Heikki Linnakangas wrote:
>> Denys Vlasenko wrote:
>>> In linux kernel, decimal conversion in vsprintf() is optimized
>>> with custom conversion code. x3 faster, and no, it's not written in
>>> assembly.
>> Interesting. I copy-pasted the cod
Denys Vlasenko writes:
> On Monday 08 October 2007 13:50, Heikki Linnakangas wrote:
> > While profiling a test case of exporting data from PostgreSQL, I noticed
> > that a lot of CPU time was spent in sprintf, formatting timestamps like
> > "2007-10-01 12:34". I could speed that up by an order
On Monday 08 October 2007 16:08, Heikki Linnakangas wrote:
> Denys Vlasenko wrote:
> > On Monday 08 October 2007 13:50, Heikki Linnakangas wrote:
> >> While profiling a test case of exporting data from PostgreSQL, I noticed
> >> that a lot of CPU time was spent in sprintf, formatting timestamps lik
It's too far-fetched for my tastes. I think gcc should not do it.
How gcc can know what printf() and puts() mean in *my* libc?
Well, that's what -fno-builtin is for.
More precisely, -ffreestanding.
I think such optimizations should be done in glibc.
The point is that you can't. GCC knows i
Denys Vlasenko wrote:
> On Monday 08 October 2007 13:50, Heikki Linnakangas wrote:
>> While profiling a test case of exporting data from PostgreSQL, I noticed
>> that a lot of CPU time was spent in sprintf, formatting timestamps like
>> "2007-10-01 12:34". I could speed that up by an order of magni
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> I don't have much experience with GCC hacking, but I did put together a
> prototype to do some of the above, and it does look like you can get
> very significant speedups. Before I continue with that, has something
> like this been proposed before
On Monday 08 October 2007 13:50, Heikki Linnakangas wrote:
> While profiling a test case of exporting data from PostgreSQL, I noticed
> that a lot of CPU time was spent in sprintf, formatting timestamps like
> "2007-10-01 12:34". I could speed that up by an order of magnitude by
> replacing the spr
30 matches
Mail list logo
