Recent Features
| |||||||||||||
GCC Explorer - an interactive take on compilationGCC Explorer - an interactive take on compilationPosted May 24, 2012 17:26 UTC (Thu) by ncm (subscriber, #165)In reply to: GCC Explorer - an interactive take on compilation by Richard_J_Neill Parent article: GCC Explorer - an interactive take on compilation
... because we've all had programs that we discovered ran too slowly because they called printf instead of puts.
How do you turn it off?
(Log in to post comments)
GCC Explorer - an interactive take on compilation Posted May 24, 2012 17:33 UTC (Thu) by cborni (subscriber, #12949) [Link]
> How do you turn it off?
-fno-builtin should turn that off
GCC Explorer - an interactive take on compilation Posted May 24, 2012 18:10 UTC (Thu) by njs (guest, #40338) [Link]
-fno-builtin-printf, I think, unless you also hate things like memcpy optimisations.
(It's not actually that uncommon to log some strings from inside a CPU-intensive loop, and printf does have a fair amount of overhead relative to puts.)
GCC Explorer - an interactive take on compilation Posted May 24, 2012 20:02 UTC (Thu) by pjm (subscriber, #2080) [Link]
I don't understand; why would you want to turn it off?
The point about compilers doing these sorts of micro-optimizations is that it saves the programmer from thinking about the inefficiency and deciding whether or not there's a reasonable alternative that would avoid the inefficiency. Having a good optimizer results in more readable code, and less distracted programmers. (And as an added bonus, the code occasionally even runs faster.)
GCC Explorer - an interactive take on compilation Posted May 25, 2012 6:45 UTC (Fri) by alankila (subscriber, #47141) [Link]
Different schools of thought. Some people don't like it when compiler does things behind your back and distances the running code too much from the written code. Wholesale function replacement seems like nasty thing to have done.
The sad matter of fact is that printf API is not very well designed, in that every time printf is executed, the format string is scanned again, looking for the % characters. A more carefully designed API would require you to preprocess the format string using something like printf_t format = printf_prepare("foo %d bar"), and then you could use the format repeatedly without any parsing overhead.
In this way, it would be possible to have a dumber compiler and likely more efficiency than with current printf.
GCC Explorer - an interactive take on compilation Posted May 25, 2012 13:40 UTC (Fri) by vonbrand (subscriber, #4458) [Link] Given that your compiler is allowed to assume that a function called
GCC Explorer - an interactive take on compilation Posted May 25, 2012 20:38 UTC (Fri) by mpr22 (subscriber, #60784) [Link] An even more carefully designed API would allow you to do so rather than requiring you to.
GCC Explorer - an interactive take on compilation Posted May 26, 2012 12:43 UTC (Sat) by alankila (subscriber, #47141) [Link]
Sure. I cold imagine a printf macro that just expands to static initialization of the format followed by use of that format. There's some good things to be said for brevity, and in seriousness I do not propose this. It is perfectly acceptable to waste CPU cycles and memory, because proportionally speaking they aren't in such a short supply.
GCC Explorer - an interactive take on compilation Posted Jun 2, 2012 21:27 UTC (Sat) by vonbrand (subscriber, #4458) [Link] Oh, come on. The compiler surely could figure out that this is
GCC Explorer - an interactive take on compilation Posted Jun 3, 2012 5:37 UTC (Sun) by quotemstr (subscriber, #45331) [Link]
Your transformation isn't valid: consider multithreading. One printf will write to a stream as an atomic operation (enforced by internal stdio locks), but the output from discrete output functions may overlap.
GCC Explorer - an interactive take on compilation Posted Jun 3, 2012 9:23 UTC (Sun) by dgm (subscriber, #49227) [Link]
That's why a naive coder with a optimizing compiler cannot beat a good coder. The compiler is bound by the precise semantics of the code, even if there are aspects of it that you don't care. The compiler has to care.
GCC Explorer - an interactive take on compilation Posted May 28, 2012 0:00 UTC (Mon) by jamesh (guest, #1159) [Link]
While it might seem like a down side, processing the format string at runtime is great for translation. To switch languages, a program can simply substitute in different format strings in its printf call. If the printf implementation supports positional arguments, then the translation can even reorder the interpolated values.
In contrast, schemes like C++'s IO streams based output (which sounds a lot like what you'd expect the compiler to convert a printf call to) end up with lots of short fragments of text that are harder to translate as a unit.
|
|||||||||||||