4 ms·

>It's been around 2x faster than Python in most of my uses You must have some very unusual uses for that to be true. The computer language shootout isn't perf

• dnu 14y ago
  That benchmark is for algorithms implemented in pure Python and in pure Go. But for real projects, a Python programmer might use several libraries which are written in C.
  • papsosouid 14y ago
    I think programs that are 90% C and 10% python do constitute "unusual use cases".
    • benaiah 14y ago
      That would be unusual, but 80% of a program's performance is generally tied up in 20% of its code. If you can replace the 20% with a couple widely-used C libraries, then you get vastly improved performance without actually having to write much C. In most cases in Python, the part that one would consider the application proper is entirely written in Python, which use Python libraries that wrap around C libraries to do the intensive stuff. Your comment was a non sequitur from what dnu said. Please refrain from attacking arguments with straw men - they add nothing to the discussion Edited for tone: s/Quit with the straw man arguments/Please refrain from attacking arguments with straw men/
      • papsosouid 14y ago
        >80% of a program's performance is generally tied up in 20% of its code I've never seen any evidence to support this truthy sounding statement. In fact, my experience has been that it only holds true occasionally, and only for the very first initial profiling, seeing that some huge performance no-no was made. Once that is fixed, you have a pretty flat profile, with "the language is just slow" as your explanation, and no recourse. >Your comment was a non sequitur from what dnu said. No it wasn't. He responded to what I said. How could re-iterating what I said be a non-sequitur? Read the thread, I said python being only twice as slow as go "for my uses" would indicate some very unusual uses. >In most cases in Python, the part that one would consider the application proper is entirely written in Python, which use Python libraries that wrap around C libraries to do the intensive stuff. No, in the cases you want to put forth as representative because they support your belief that slow languages are good enough. Most applications don't have a convenient "intensive stuff" to do in C. Most applications are like django, just generally slow all over because they are written in a slow language. >Quit with the straw man arguments - they add nothing to the discussion. Neither do unwarranted accusations of straw man arguments.
        • benaiah 14y ago
          It was a non sequitur, and a straw man - you said that python was 5 times slower than C at best and 30-50 times slower than C at worst on some benchmarks. dnu pointed out that the benchmarks did not represent real-world Python code, since real-world code uses C libraries for performance-intensive stuff. You responded by saying that programs that are 90% C and 10% Python are unrealistic. Nobody ever suggested using programs that were 90% C and 10% Python, or said that that kind of usage was common. That didn't follow what dnu said at all. You weren't "reiterating" anything - you never said anything about "your uses", coldtea did, much farther up the thread. (If you're coldtea, then I understand your point, but if that's the case, you should have made that clear, as it vastly changes the context of what you were saying). You just brought up some benchmarks, which are not representative of how Python is used in the real world. I see how you could have intended to imply that this was "your uses" by saying that coldtea must have unusual uses if he got go/2 performance out of Python, but this was hardly clear, if it is the case. Regardless, you totally misrepresented dnu's point. As for your arguments against my points, the 80/20 rule, while obviously impossible to definitively prove, has far more authoritative supporters than it does detractors. If you haven't experienced that being the case, then that's good and well for you, but the experience of many others suggests that it usually is (in fact, it's usually stated as being closer to 90/10 than 80/20). Your Django argument falls flat if you look at it more closely. Sure, Django might introduce some slowness, but the vast majority of web performance is in the networking and database layers, not the application layer. Your choice of language has little to no bearing on the networking aspect of things, but what do you think the database drivers are written in? C, or an equivalent. 10% of the code that has 90% of the performance impact - sound familiar? And you interact with database drivers most of the time exactly how I said - by using a Python library that wraps around a C library to run the database. >>Quit with the straw man arguments - they add nothing to the discussion. >Neither do unwarranted accusations of straw man arguments. I apologize if I come across as insulting - it is not my intention. My phrasing in the grandparent comment was overly antagonistic, and I'm about to edit it to fix that. But my accusations of straw man arguments were correct.
  • igouy 14y ago
    >> That benchmark is for algorithms implemented in pure Python and in pure Go << Note that papsosouid needed to add the restriction "on benchmarks actually written in python instead of C" to avoid mentioning the 2 tasks where Python is shown as faster than Go ;-)