On: PyPy is faster than C, again: string formatting

[lilyball]

Sounds like this would be the equivalent of some theoretical

    exp = CompileSprintfFormat("%d %d");
    for (i = 0; i < 10000000; i++) {
        RunCompiledSprintf(exp, i, i);
    }

All I'm really getting out of this is that PyPy now compiles sprintf formats for you and saves the results, and that there's no equivalent API in libc.

[TylerE → lilyball]

That's not really it. This, at least in my understanding, is a fully generic optimization, of operations on constant strings.

[lilyball → TylerE]

From the article:

> In the case of PyPy, we specialize the assembler if we detect the left hand string of the modulo operator to be constant.

So it's very much a targeted optimization at the modulo operator (which is Python's equivalent of sprintf).

[kingkilr → lilyball]

I wouldn't say it's particularly targeted, let me show you the code that makes this happen: https://bitbucket.org/pypy/pypy/src/unroll-if-alt/pypy/objsp...

[pja → kingkilr]

Yeah, the point is that by expressing the algorithm in Python, the JIT gets to go hog wild optimising tight loops like this one.

Which is great: why do all that work writing some kind of custom sprintf generating function when you can just let the JIT do it for you on the fly?

[greyfade → TylerE]

In that case, wouldn't it be more fair to compare it to a C++ re-implementation of sprintf using the new `constexpr` keyword?

[DasIch → lilyball]

You shouldn't have to use such an API though and this case could be optimized by any C compiler.