Hacker News Reader

Comment by simias | Hacker News Reader

I'd say that printf, with its own DSL, is actually pretty slow. It's meant for debugging or "slow" I/O, if you need to write a lot of data it should be avoided.

A few years ago for debugging purposes I wanted to hexdump a large amount of data. Turns out that the standard hexdump tool was pretty slow at it, writing a simple C utility that would format the dump "by hand" instead of using printf was about an order of magnitude faster. You have fully static code instead of the interpreted format string, you can unroll all the formatting, you don't have to rewrite the characters that don't change in every line (spaces, delimiters etc...). It's lightning fast but of course not very flexible.

View on HN

> I'd say that printf, with its own DSL, is actually pretty slow.

Yes, of course it is. That's why I took it as an example. Since I work on RealTime systems I usually have to use plain 'write' instead. But that is because 'printf' is an incredibly complex function, not because 'C is slow'.

At this point I feel like it's almost a philosophical argument but:

- printf is a standard function in C's stdlib.

- Because of the nature of the function (using a special purpose format strings and varargs instead of some kind of generic system) the function can't really be aggressively optimized and inlined without compiler magic. This limitation is caused by C's own limitations when it comes to generic programming and type introspection, printf needs to be told explicitly through a "side-channel" (the format string) what types to expect because C lacks the infrastructure to do that by itself. It also means that you can't extend the function for custom types and that you can't type-check the parameters without compiler magic.

- Even though some compilers do implement special magic around printf to perform more aggressive optimizations (like replacing it with "puts" if there's no formatting going on for instance) it's still generally trivial to beat its performance in non-trivial case with handwritten code.

Given all of the above I would say that makes this particular corner of C rather slow indeed. Or at least slower than it might be compared to an hypothetical language that made it easier to optimize string formatting.

You're entirely right, but I feel like you're trying really hard to misunderstand deng's original comment. It's an apt analogy, partly because of what you wrote. This article's title is as ridiculous as an article titled "Is C fast?" with a story about a faster_printf that only supports %d.

It's been a long time since I've done C++. I wonder if

   int x;
   cout << x;

ought to be faster than printf("%d", x), by virtue of knowing the types ahead of time?

If it weren't for locales, probably yes ;P

Yes, but only if you first call

  ios::sync_with_stdio(false);

https://en.cppreference.com/w/cpp/io/ios_base/sync_with_stdi...

Pedantic: No. If you write

  #include “studio.h”
  int x;
  printf(“%d”, x);

the compiler knows the types ahead of time, too, so that cannot explain any speed difference (and yes, C compilers do try to avoid the generic printf in the library. See http://www.ciselant.de/projects/gcc_printf/gcc_printf.html for examples)

(The #include is essential. With it, the compiler can know what printf does, and, in theory, optimize it to a int-to-string conversion and a puts system call. Without it, it cannot, because it doesn’t know what the printf function does (in this case, it is easier to generate fast code for the compiler if it doesn’t have the source available than when it would see source code for a function called printf)

Utterly pedantic: no. As given, both are undefined behavior, and it is trivial for a compiler to discover that.

> and yes, C compilers do try to avoid the generic printf in the library

That is true for certain format strings (containing only %s or %c conversions), but for %d GCC and Clang don't seem to want to call a print_int function, possibly because there is none: https://gcc.godbolt.org/z/rltFse

Reply on news.ycombinator.com