4 ms·

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

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.

vitaut 10y ago
__sprintf_chk is shared between all calls to sprintf which is not true for Julia.
KenoFischer 10y ago
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.
3JPLW 10y ago
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.
- vitaut 10y ago
  This is actually a good point, but what about Unicode? Will `(UTF8String, Float64)` emit another function?
  - 3JPLW 10y ago
    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
    - vitaut 10y ago
      Thanks, this looks better. I'll need to update the post.

vitaut 10y ago

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

KenoFischer 10y ago

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.

3JPLW 10y ago

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.

vitaut 10y ago
This is actually a good point, but what about Unicode? Will `(UTF8String, Float64)` emit another function?
- 3JPLW 10y ago
  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
  - vitaut 10y ago
    Thanks, this looks better. I'll need to update the post.