Hacker News Reader

Comment by metrognome | Hacker News Reader

When the author compares the number of CPU instructions that sprintf compiles to in both C and Julia, he fails to take into account dynamic linking in C:

  jmp	__sprintf_chk

I would guess that another few hundred instructions run as a result of this jmp. Thus, the difference in the number of instructions that C's sprintf and Julia's @sprintf compile to are not as drastic as the author makes it seem.

View on HN

I believe that author's point was the size of the resulting generated code, which is fair. The original intent of making it a macro was to get a faster version of printf. However, as it turns out the major time sink in printf is not the formatting, but converting binary into decimal, so specializing on the format string doesn't actually help.

Also note that the author asks for the native code for arguments of type `(AbstractString, Float64)`. The first is an abstract type — which means that this code will never get called in the first place. Julia will resolve the type of the string, and then dispatch to the concrete implementation. Which, for an ASCIIString, is 3x shorter.

This is actually a good point, but what about Unicode? Will `(UTF8String, Float64)` emit another function?

It's the same on 0.4, and Strings are getting a big overhaul on 0.5. Here are the results for 0.4:

    $ julia -e 'f(a, b) = @sprintf("this is a %s %15.1f", a, b); code_native(f, (AbstractString, Float64))' | wc -l
    WARNING: Returned code may not match what actually runs.
         628

    $ julia -e 'f(a, b) = @sprintf("this is a %s %15.1f", a, b); code_native(f, (ASCIIString, Float64))' | wc -l
         194

    $ julia -e 'f(a, b) = @sprintf("this is a %s %15.1f", a, b); code_native(f, (UTF8String, Float64))' | wc -l
         194

Thanks, this looks better. I'll need to update the post.

__sprintf_chk is shared between all calls to sprintf which is not true for Julia.

Reply on news.ycombinator.com