4 ms·

I love PyPy, those guys are amazing. However, every time I see "faster than C" almost always a bit of trickery/wordplay is involved. The examples aren't compar

I love PyPy, those guys are amazing. However, every time I see "faster than C" almost always a bit of trickery/wordplay is involved. The examples aren't comparable. The equivalent would be to have Python code invoke an external function which sits in a pre-compiled .so Bulk of the work is happening inside of sprintf(), why handicap C by not letting it to compile the code? The fair comparison would be to place the source of sprinf() nearby and see if C compiler inlines that call or/and unrolls the loop, otherwise it's just about packaging/linking, not really about code generation. Edit: I see this became #1 on HN front page today. I want to take advantage of this and say that http://mailgun.net http://mailgun.net, the programmable email platform, is looking for an engineer who'd find this discussion interesting. See my profile. And we're users of PyPy too! :)

skorgu 15y ago
PyPy tries to move as much code as possible out of C and into (R)Python for the exact reason that this kind of optimization becomes possible/feasible/easier with JIT. So it's a packaging win sure but it's not an accidental one.
leon_ 15y ago
> However, every time I see "faster than C" almost always a bit of trickery/wordplay is involved. yeah, it's almost like those "$something in only $few lines of $programming_language" posts where you get highly obfuscated code to read.
scott_s 15y ago
But the whole point of the post was to point out that PyPy can optimize in places that the traditional C model of shared libraries cannot - or, at least, have great difficulty doing so. This is an inherent advantage to optimizing the instructions at runtime.
- burgerbrain 15y ago
  C the language doesn't have shared libraries. That's something some systems add themselves. Edit: Is this not the case? I am under the impression that it is, and is relatively new at that.
  - scott_s 15y ago
    Which is why I said "the traditional C model of shared libraries." Shared libraries are not a part of the C language itself, but most real systems make heavy use of shared libraries. Even statically linked C programs have this problem, because optimizing across object files is hard - most compilers don't even try. Not being a part of the C language itself is irrelevant. The traditional linker has been a part of the C ecosystem for decades.
    - burgerbrain 15y ago
      Statically linked programs certainly still have this problem, I'm not contending that at all. I would not however call shared libraries a "traditional model" at all. Particularly in the fields that C seems to be getting relegated to more and more these days.
      - scott_s 15y ago
        If you're running a Unix derived system, most of the programs are using shared libraries. That fits "traditional" in my mind.
        burgerbrain 15y ago
        A sufficiently modern Unix derived system, sure ;) I have quite commonly seen shared libraries not done on embedded systems however, regardless of heritage.
        scott_s 15y ago
        And I don't consider embedded systems to be traditional. Otherwise, we wouldn't have to qualify it with "embedded."
        burgerbrain 15y ago
        They are certainly a traditional stronghold of straight up C.
- old-gregg 15y ago
  Shared libraries is an operating system feature and has nothing to do with C. C just happens to be the most popular systems programming language. "Traditional C model" is just a bunch of object files, and it's up to you and your linker to package it any way you want it: a shared library, a static library or an executable. I'm not a GCC expert, but Microsoft C compilers could inline cross-module code since the beginning of time. His example may actually produce different results under msvc with /GL flag and with static linking enabled. "...Inline a function in a module even when the function is defined in another module..." http://msdn.microsoft.com/en-us/library/0zza0de8%28v=vs.80%29.aspx http://msdn.microsoft.com/en-us/library/0zza0de8%28v=vs.80%2...
  - scott_s 15y ago
    See my reply below. I'm fully aware of the relationship C has to systems programming.
  - cube13 15y ago
    Depends on their GCC options. If it's the default option, it should be using the shared library. If they changed it to statically link libc, that should produce a(possibly considerable) performance boost.
  - ori_b 15y ago
    GCC got that option recently with '-flto' (or whatever it was to enable link time optimization)
  - sausagefeet 15y ago
    Is anyone working on a JIT for object code? I'm thinking we could keep all our SO's how they are now since they are great for updating versions of libraries with bugs, but have a JIT that takes care of profiling and inlining functions from other modules.
    - fanf2 15y ago
      LLVM is designed to be able to do this.
JoachimSchipper 15y ago
Just including vprintf is not enough. Here are some timings (GCC-4.2.1, system compiler on OpenBSD-5.0-current/amd64 on a Thinkpad SL510; all timings are median-of-three): Provided program, -O4: ~5.06s Provided program, -O4 -march=native: ~5.07s (i.e. no difference) Provided program, includes sprintf and the vprintf family, -O4 -march=native: ~4.84s Of course, this is just a silly example (realistic programs don't make things that easy on the JIT). Still, quite impressive; congratulations to the PyPy guys!
haberman 15y ago
I highly doubt that the performance difference is a result of not inlining/unrolling sprintf(). The difference is most likely due to the fact that sprintf() is parsing the format string over and over, whereas PyPy is only parsing it once. The printf() family of functions is one of the rare parts of the C standard library that is essentially implementing an interpreter. The format string is a program and the library call runs that program with data that is supplied in the other arguments. So in essence this is comparing an interpreter (sprintf) with a JIT compiler (PyPy generating code for a specific format string at runtime). I agree it's not a very fair comparison: if this C code was performance critical you would call a specialized function for converting an integer to a string, and this would almost certainly beat PyPy.
- cube13 15y ago
  >I highly doubt that the performance difference is a result of not inlining/unrolling sprintf(). The difference is most likely due to the fact that sprintf() is parsing the format string over and over, whereas PyPy is only parsing it once. And the fact that it only runs twice as long is pretty impressive, actually. Sprintf is doing the parsing 999,999,999 times more than the PyPy interpreter is.
  - deleted 15y ago
    [deleted]
deleted 15y ago
[deleted]

skorgu 15y ago

PyPy tries to move as much code as possible out of C and into (R)Python for the exact reason that this kind of optimization becomes possible/feasible/easier with JIT. So it's a packaging win sure but it's not an accidental one.

leon_ 15y ago

> However, every time I see "faster than C" almost always a bit of trickery/wordplay is involved. yeah, it's almost like those "$something in only $few lines of $programming_language" posts where you get highly obfuscated code to read.

scott_s 15y ago

But the whole point of the post was to point out that PyPy can optimize in places that the traditional C model of shared libraries cannot - or, at least, have great difficulty doing so. This is an inherent advantage to optimizing the instructions at runtime.

burgerbrain 15y ago
C the language doesn't have shared libraries. That's something some systems add themselves. Edit: Is this not the case? I am under the impression that it is, and is relatively new at that.
- scott_s 15y ago
  Which is why I said "the traditional C model of shared libraries." Shared libraries are not a part of the C language itself, but most real systems make heavy use of shared libraries. Even statically linked C programs have this problem, because optimizing across object files is hard - most compilers don't even try. Not being a part of the C language itself is irrelevant. The traditional linker has been a part of the C ecosystem for decades.
  - burgerbrain 15y ago
    Statically linked programs certainly still have this problem, I'm not contending that at all. I would not however call shared libraries a "traditional model" at all. Particularly in the fields that C seems to be getting relegated to more and more these days.
    - scott_s 15y ago
      If you're running a Unix derived system, most of the programs are using shared libraries. That fits "traditional" in my mind.
      - burgerbrain 15y ago
        A sufficiently modern Unix derived system, sure ;) I have quite commonly seen shared libraries not done on embedded systems however, regardless of heritage.
        scott_s 15y ago
        And I don't consider embedded systems to be traditional. Otherwise, we wouldn't have to qualify it with "embedded."
        burgerbrain 15y ago
        They are certainly a traditional stronghold of straight up C.
old-gregg 15y ago
Shared libraries is an operating system feature and has nothing to do with C. C just happens to be the most popular systems programming language. "Traditional C model" is just a bunch of object files, and it's up to you and your linker to package it any way you want it: a shared library, a static library or an executable. I'm not a GCC expert, but Microsoft C compilers could inline cross-module code since the beginning of time. His example may actually produce different results under msvc with /GL flag and with static linking enabled. "...Inline a function in a module even when the function is defined in another module..." http://msdn.microsoft.com/en-us/library/0zza0de8%28v=vs.80%29.aspx http://msdn.microsoft.com/en-us/library/0zza0de8%28v=vs.80%2...
- scott_s 15y ago
  See my reply below. I'm fully aware of the relationship C has to systems programming.
- cube13 15y ago
  Depends on their GCC options. If it's the default option, it should be using the shared library. If they changed it to statically link libc, that should produce a(possibly considerable) performance boost.
- ori_b 15y ago
  GCC got that option recently with '-flto' (or whatever it was to enable link time optimization)
- sausagefeet 15y ago
  Is anyone working on a JIT for object code? I'm thinking we could keep all our SO's how they are now since they are great for updating versions of libraries with bugs, but have a JIT that takes care of profiling and inlining functions from other modules.
  - fanf2 15y ago
    LLVM is designed to be able to do this.

JoachimSchipper 15y ago

Just including vprintf is not enough. Here are some timings (GCC-4.2.1, system compiler on OpenBSD-5.0-current/amd64 on a Thinkpad SL510; all timings are median-of-three): Provided program, -O4: ~5.06s Provided program, -O4 -march=native: ~5.07s (i.e. no difference) Provided program, includes sprintf and the vprintf family, -O4 -march=native: ~4.84s Of course, this is just a silly example (realistic programs don't make things that easy on the JIT). Still, quite impressive; congratulations to the PyPy guys!

haberman 15y ago

I highly doubt that the performance difference is a result of not inlining/unrolling sprintf(). The difference is most likely due to the fact that sprintf() is parsing the format string over and over, whereas PyPy is only parsing it once. The printf() family of functions is one of the rare parts of the C standard library that is essentially implementing an interpreter. The format string is a program and the library call runs that program with data that is supplied in the other arguments. So in essence this is comparing an interpreter (sprintf) with a JIT compiler (PyPy generating code for a specific format string at runtime). I agree it's not a very fair comparison: if this C code was performance critical you would call a specialized function for converting an integer to a string, and this would almost certainly beat PyPy.

cube13 15y ago
>I highly doubt that the performance difference is a result of not inlining/unrolling sprintf(). The difference is most likely due to the fact that sprintf() is parsing the format string over and over, whereas PyPy is only parsing it once. And the fact that it only runs twice as long is pretty impressive, actually. Sprintf is doing the parsing 999,999,999 times more than the PyPy interpreter is.
- deleted 15y ago
  [deleted]

deleted 15y ago

[deleted]