10 ms·

Meh, MEH. I'm almost never waiting on my python code. I'm waiting on network or disk or database or joe to check in his changes or etc. I'm sure there are peo

Meh, MEH. I'm almost never waiting on my python code. I'm waiting on network or disk or database or joe to check in his changes or etc. I'm sure there are people who do wait. But that's why numpy, c extensions, all the pypy, psycho, and similar things exist. Python and more broadly "scripting" languages are for speed of development. Something else can take on speed of execution faster than 90% of people need it to be.

tptacek 14y ago
It's not an unresolved question whether idiomatic Python is slower than idiomatic C/C++ for solving comparable problems. Python is much, much slower than C.
- ynniv 14y ago
  Meh, when there's an io call or a network request in front of the computation you'll never know. EDIT: removed an additional comment about scientific computing that is now relevant as someone replied to it.
  - tptacek 14y ago
    Does that mean we can't discuss what makes languages or their implementations performant without having a detailed conversation about the relevance of performance?
    - ynniv 14y ago
      No, I'm in complete agreement with the OP, but you said Python is slower than idiomatic C/C++ for solving comparable problems And when io and especially network is involved, that is not true. Your efficient C code can't make up for time lost elsewhere in the system. No one is clamoring for curl to be rewritten in assembly.
      - tptacek 14y ago
        True, but obvious.
        ynniv 14y ago
        I hate to feed someone on a troll, but you started this off with "Python is much, much slower than C." This comment thread is sponsored by obvious.
      - cwzwarich 14y ago
        Is this really true? I have investigated a few performance / power problems caused by somebody using a bad networking API or using a networking API correctly, despite doing the same amount of I/O. It is also more likely to be possible to use efficient platform-specific APIs for things like zero-copy I/O in C than in a scripting language.
        tptacek 14y ago
        Zero-copy is often not actually a win; it's also uncommon in C code, too. The parent comment is right; I/O bound programs tend to do just as well in slow languages as in fast. It's true that language performance often doesn't matter, just like it's true that parser designs don't matter if you just use sexprs for everything.
        cwzwarich 14y ago
        I disagree. I've measured it and it matters.
        tptacek 14y ago
        For your data set.
        emn13 14y ago
        For lots of data sets, and that includes many so-called I/O-bound datasets. Don't forget that a lot of I/O is very fast nowadays: if you're reading 100's of MB from the disk a second, you can't spend much time on the CPU processing each byte before the CPU becomes the bottle - you have on the order of 10-100 of clock cycles a byte, no more. Simple things like decoding utf-8 and checksumming can take a significant portion of this time, and that's before you're parsing anything. (Hence stuff like protocol buffers...) If you're trying to make a fast program you obviously avoid too much expensive I/O. You can't avoid some latency, but you can often avoid a lot, and cache a lot, and place the rest closer to the consumer. When you say I/O dominated, are you sure you don't mean: interactive website? Because I think the real saving grace there is that's it's OK for websites to be very slow - from the perspective of a CPU. It's not that the I/O needs to take a lot of time, it's that you have 100ms (and that's before ajax and relatives, which can hide even more latency), and you just don't need a lot of optimization to get into that restriction. And once you have, the difference between 100ms and 1ns just doesn't matter nearly as much; so sure, then you start to accept very inefficient I/O setups even though much more efficient ones could be readily available.
  - timtadh 14y ago
    [Edit: the parent originally had a sentence about not understanding why people like Python for Scientific Computing. This was my response to that. The parent has now removed the sentence.] We (the people using Python for Scientific Computing) like Python for the following reasons: 1. Numpy+Scipy+matplotlib+cvxopt is a very speedy environment. Its only real competitor for what it provides is MatLab. I have a colleague who bench marked Python vs. Matlab for our workload. Python is faster. (often because some of the algorithms used are newer than the equivalents in Matlab.) 2. It is a very productive environment. We do a lot of evolutionary changes and prototyping. Doing in this in C would slow us down in dev. time. This is academic work and mostly the code isn't important the analysis is. 3. We generally know where the "hot loops" are. Which is what we focus on for optimization. This generally involves doing math on paper. Then implementing it. If you turn loops in to matrix multiplications and use a good matrix library you get a great speed up.
    - ynniv 14y ago
      Sorry, I decided that it wasn't important before you replied. I am genuinely interested in why people use python for scientific computing, tho. I have a colleague who bench marked Python vs. Matlab for our workload. Python is faster Is it also faster than C? From my limited experience, it seems that people sometimes spend a lot of time on concurrency when faster code would have been easier. This generally involves doing math on paper. Then implementing it. Ah, yes, math always wins. This reinforces your point #2. So, is #2 that much of a win? Do scientific programs spend more time in "development" than "production"?
      - pwang 14y ago
        > Is it also faster than C? From my limited experience, it seems that people sometimes spend a lot of time on concurrency when faster code would have been easier It can reach FORTRAN speeds with the right tools. With Numba (http://numba.pydata.org/ http://numba.pydata.org/), your pure Python code gets compiled down to optimized machine code at call time, if your arguments are Numpy arrays. With NumbaPro (https://store.continuum.io/cshop/numbapro https://store.continuum.io/cshop/numbapro), we automatically parallelize for multi-core CPUs, and we emit CUDA/PTX for GPUs, and automatically exploit the parallelism in your data and algorithm. The reason "higher level languages" can be faster than lower-level ones is because the compiler has more information about data parallelism. Typically "low level languages" are lower in that their type primitives are smaller, and hence the algorithms around those have turned vectorizable arrays into opaque for loops over arbitrary loop variables. I certainly agree with you that many people now reach for distributed and parallel while leaving a lot of single-core and single-node performance on the table, mostly by ignoring the realities of memory bandwidth on modern CPUs. However, that level of efficiency is well within the reach of the Scientific Python stack. (See this blog post for how we're building a persistence format that respects memory hierarchy: continuum.io/blog/blz-format)
- timtadh 14y ago
  This is completely true. It is indeed well known and common wisdom. However, I think the point the parent was trying to make is: Python is much slower than C and many other languages, however most of the time speed is unimportant. When it becomes important, there are many technologies to mitigate the problem in your "hot loops." If speed is your primary concern don't use Python et. al. If it isn't your main concern go ahead it probably won't become an issue and if it does you probably will be able to get around it.
  - tptacek 14y ago
    The deck is about the performance of the language.
    - obviouslygreen 14y ago
      And this comment thread is about why some people don't care in some applications. HN meta!
      - tptacek 14y ago
        This comment thread is isomorphic to a comment thread on Packrat parsing with comments about how "I don't parse anything I just use sexprs".
    - timtadh 14y ago
      @chadcf and @tptacek I was responding to @tptacek criticism of the parent not the deck. The deck is great and it mirrors the wisdom I have picked up from optimizing my own code over the years. I personally find it really frustrating not being able to easily pre-alloc lists in Python. I think that having better APIs would go a long way. As the deck says: "Line for line these languages are fast!" "We need better no-copy/preallocate APIs" "Take care in data structures"
      - mixmastamyk 14y ago
        Forgive the naive question, but why not: l = [object()] * 100 Perhaps the difference is stack vs. heap?
- rdtsc 14y ago
  > It's not an unresolved question whether idiomatic Python is slower than idiomatic C/C++ for solving comparable problems. Python is much, much slower than C. The real question is does it matter for a particular project. If it is a desktop GUI. Does it matter if you write it in C++ and the time from button click to status update is 5usec or 1msec? If you are receiving 10 messages per second, parsing out json and sending back a response or saving it to disk, does it always matter that it all happens in 10msec instead of 11msec. Maybe it does, I found it often doesn't.
  - Qantourisc 14y ago
    Yes battery power and general speed. On the other hand, it's hard to sacrifice more/better programs over speed; but IMO it does matter.
lucian1900 14y ago
Alex's point is that Python on PyPy is trivially comparable to those C extensions in speed. So why give up Python, ever, if JITs are this good?
- tptacek 14y ago
  What if writing performant code on modern Python implementations is only incrementally easier than writing it in C to begin with? With the right libraries, the hard parts of C probably turn out to be string processing with zero-copy string idioms, the requirement to lay out every data structure in fiddly detail, the requirement to track individual allocations, and the requirement to manage the memory lifecycle. What if performant Python only gives you an advantage on the last one of those?
  - NateDad 14y ago
    You can control the details without it having to be overly fiddly. Certainly you can do better than C. You may end up doing similar things, but your code will be way easier to write and read. Go does this quite well.
  - lucian1900 14y ago
    I would say that the difference between fast Python code and C is still quite large. - the syntax is less error-prone - ownership semantics are much clearer. You'll never segfault because you sent some memory into the wrong function - not as much detail is needed for memory layout, the JIT abstracts a lot of it away - there are high-level APIs handy - development and distribution are simpler with one less language - the barrier to optimising things is lower
    - tptacek 14y ago
      I'm interested in this discussion. Which of those issues could you dispense with using more modern APIs and idioms in C? Look at Objective C (mentally wipe off all the object goo), particular NSMutableString and NSMutableArray and NSMutableData, for examples of what I'm thinking about. The C syntax we're stuck with. But how big a deal is that syntax? Segfaults are mitigated if you don't expose pointers, except to the extent that C programmers have to think about memory lifecycle (like I said, I think this is indisputably a win for high level languages). Look at NSMutableString for an example of a C-style idiom that removes whole classes of pointer operations. I dispute that JITs abstract away details about storage; they may allow you to not think about those details for code that doesn't need to be performant, and they can help the language get out of the way when you need to care about the storage details, but the question I'm asking is limited to performant code. There is no question that nonperformant Python code is way easier to write than any kind of C code! There are better APIs available in Python than are commonly available to C or even ObjC, but that's a solvable problem. Let's stipulate better APIs, to the limit of what the language would allow (in other words, it's totally fair to say that the design of C/C++ would prohibit certain kinds of easy APIs). Development and deployment are easier in some cases for Python (for instance, building on OS X and deploying on Linux), but far easier for C in others (for instance, building code that will run in a kernel or as a plugin in the address space of another process). I dispute that the barrier to optimization is lower in Python for obvious reasons: C programmers can optimize without working around the exposed wires and ductwork of the language runtime. C programmers generally have an easier time optimizing than Python programmers; that is probably the #1 reason any Python programmer ever writes C. As a current Golang programmer I agree strongly with the commenter below that when you take this idea and apply it to a new language you wind up with something that looks a lot like Go, which does work great. But I'm not advocating Go here.
MBlume 14y ago
If you're completely satisfied with Python's performance, that's wonderful. It means the talk wasn't aimed at you. Move along.
mistercow 14y ago
Speed in Python (or Ruby, or JS) isn't a big deal... until it is. When that happens, would you rather have to switch over to C and glue the resulting binary in (assuming you're not using JS, in which case you're just SOL), or would you rather have a high performance API at your fingertips for optimization when you need it?
- pjscott 14y ago
  Well, my usual answer there is to change the file extension to .pyx and see what Cython can do with a few type annotations. Usually the results are pretty good, and sometimes they're very good.
  - mistercow 14y ago
    I think most of the gains you'd get from that would be orthogonal to the gains you would get from giving the JIT a little more information about allocations.
  - omaranto 14y ago
    Does Cython give you much better results than PyPy? I would have thought that if just a few type annotations make a big difference tracing in PyPy could figure them out.
    - pjscott 14y ago
      I don't know. We're using a bunch of C extensions that aren't trivially compatible with PyPy, so using it isn't really an option -- which is a pity, since PyPy sounds pretty amazing. Cython, on the other hand, integrates really well with CPython, and it can be as fast as C if you need it to be. I'm pretty happy with it.
coldtea 14y ago
>Meh, MEH. I'm almost never waiting on my python code. I'm waiting on network or disk or database or joe to check in his changes or etc. Meh, MEH. That's because you don't do anything involved with your Python code. >I'm sure there are people who do wait. But that's why numpy, c extensions, all the pypy, psycho, and similar things exist. That they HAVE to exist could also be considered a sad state of affairs though. With a faster language you would just use the language, not external extensions and tricks.
- slurgfest 14y ago
  Anything involved with what? What kind of specific task do you actually mean by 'involved'? If you don't mind leaving Python's advantages on the table then use C in good health. Odds are that other people will be waiting on you to produce the C code, so let's hope you actually needed to do that.

tptacek 14y ago

It's not an unresolved question whether idiomatic Python is slower than idiomatic C/C++ for solving comparable problems. Python is much, much slower than C.

ynniv 14y ago
Meh, when there's an io call or a network request in front of the computation you'll never know. EDIT: removed an additional comment about scientific computing that is now relevant as someone replied to it.
- tptacek 14y ago
  Does that mean we can't discuss what makes languages or their implementations performant without having a detailed conversation about the relevance of performance?
  - ynniv 14y ago
    No, I'm in complete agreement with the OP, but you said Python is slower than idiomatic C/C++ for solving comparable problems And when io and especially network is involved, that is not true. Your efficient C code can't make up for time lost elsewhere in the system. No one is clamoring for curl to be rewritten in assembly.
    - tptacek 14y ago
      True, but obvious.
      - ynniv 14y ago
        I hate to feed someone on a troll, but you started this off with "Python is much, much slower than C." This comment thread is sponsored by obvious.
    - cwzwarich 14y ago
      Is this really true? I have investigated a few performance / power problems caused by somebody using a bad networking API or using a networking API correctly, despite doing the same amount of I/O. It is also more likely to be possible to use efficient platform-specific APIs for things like zero-copy I/O in C than in a scripting language.
      - tptacek 14y ago
        Zero-copy is often not actually a win; it's also uncommon in C code, too. The parent comment is right; I/O bound programs tend to do just as well in slow languages as in fast. It's true that language performance often doesn't matter, just like it's true that parser designs don't matter if you just use sexprs for everything.
        cwzwarich 14y ago
        I disagree. I've measured it and it matters.
        tptacek 14y ago
        For your data set.
        emn13 14y ago
        For lots of data sets, and that includes many so-called I/O-bound datasets. Don't forget that a lot of I/O is very fast nowadays: if you're reading 100's of MB from the disk a second, you can't spend much time on the CPU processing each byte before the CPU becomes the bottle - you have on the order of 10-100 of clock cycles a byte, no more. Simple things like decoding utf-8 and checksumming can take a significant portion of this time, and that's before you're parsing anything. (Hence stuff like protocol buffers...) If you're trying to make a fast program you obviously avoid too much expensive I/O. You can't avoid some latency, but you can often avoid a lot, and cache a lot, and place the rest closer to the consumer. When you say I/O dominated, are you sure you don't mean: interactive website? Because I think the real saving grace there is that's it's OK for websites to be very slow - from the perspective of a CPU. It's not that the I/O needs to take a lot of time, it's that you have 100ms (and that's before ajax and relatives, which can hide even more latency), and you just don't need a lot of optimization to get into that restriction. And once you have, the difference between 100ms and 1ns just doesn't matter nearly as much; so sure, then you start to accept very inefficient I/O setups even though much more efficient ones could be readily available.
- timtadh 14y ago
  [Edit: the parent originally had a sentence about not understanding why people like Python for Scientific Computing. This was my response to that. The parent has now removed the sentence.] We (the people using Python for Scientific Computing) like Python for the following reasons: 1. Numpy+Scipy+matplotlib+cvxopt is a very speedy environment. Its only real competitor for what it provides is MatLab. I have a colleague who bench marked Python vs. Matlab for our workload. Python is faster. (often because some of the algorithms used are newer than the equivalents in Matlab.) 2. It is a very productive environment. We do a lot of evolutionary changes and prototyping. Doing in this in C would slow us down in dev. time. This is academic work and mostly the code isn't important the analysis is. 3. We generally know where the "hot loops" are. Which is what we focus on for optimization. This generally involves doing math on paper. Then implementing it. If you turn loops in to matrix multiplications and use a good matrix library you get a great speed up.
  - ynniv 14y ago
    Sorry, I decided that it wasn't important before you replied. I am genuinely interested in why people use python for scientific computing, tho. I have a colleague who bench marked Python vs. Matlab for our workload. Python is faster Is it also faster than C? From my limited experience, it seems that people sometimes spend a lot of time on concurrency when faster code would have been easier. This generally involves doing math on paper. Then implementing it. Ah, yes, math always wins. This reinforces your point #2. So, is #2 that much of a win? Do scientific programs spend more time in "development" than "production"?
    - pwang 14y ago
      > Is it also faster than C? From my limited experience, it seems that people sometimes spend a lot of time on concurrency when faster code would have been easier It can reach FORTRAN speeds with the right tools. With Numba (http://numba.pydata.org/ http://numba.pydata.org/), your pure Python code gets compiled down to optimized machine code at call time, if your arguments are Numpy arrays. With NumbaPro (https://store.continuum.io/cshop/numbapro https://store.continuum.io/cshop/numbapro), we automatically parallelize for multi-core CPUs, and we emit CUDA/PTX for GPUs, and automatically exploit the parallelism in your data and algorithm. The reason "higher level languages" can be faster than lower-level ones is because the compiler has more information about data parallelism. Typically "low level languages" are lower in that their type primitives are smaller, and hence the algorithms around those have turned vectorizable arrays into opaque for loops over arbitrary loop variables. I certainly agree with you that many people now reach for distributed and parallel while leaving a lot of single-core and single-node performance on the table, mostly by ignoring the realities of memory bandwidth on modern CPUs. However, that level of efficiency is well within the reach of the Scientific Python stack. (See this blog post for how we're building a persistence format that respects memory hierarchy: continuum.io/blog/blz-format)
timtadh 14y ago
This is completely true. It is indeed well known and common wisdom. However, I think the point the parent was trying to make is: Python is much slower than C and many other languages, however most of the time speed is unimportant. When it becomes important, there are many technologies to mitigate the problem in your "hot loops." If speed is your primary concern don't use Python et. al. If it isn't your main concern go ahead it probably won't become an issue and if it does you probably will be able to get around it.
- tptacek 14y ago
  The deck is about the performance of the language.
  - obviouslygreen 14y ago
    And this comment thread is about why some people don't care in some applications. HN meta!
    - tptacek 14y ago
      This comment thread is isomorphic to a comment thread on Packrat parsing with comments about how "I don't parse anything I just use sexprs".
  - timtadh 14y ago
    @chadcf and @tptacek I was responding to @tptacek criticism of the parent not the deck. The deck is great and it mirrors the wisdom I have picked up from optimizing my own code over the years. I personally find it really frustrating not being able to easily pre-alloc lists in Python. I think that having better APIs would go a long way. As the deck says: "Line for line these languages are fast!" "We need better no-copy/preallocate APIs" "Take care in data structures"
    - mixmastamyk 14y ago
      Forgive the naive question, but why not: l = [object()] * 100 Perhaps the difference is stack vs. heap?
rdtsc 14y ago
> It's not an unresolved question whether idiomatic Python is slower than idiomatic C/C++ for solving comparable problems. Python is much, much slower than C. The real question is does it matter for a particular project. If it is a desktop GUI. Does it matter if you write it in C++ and the time from button click to status update is 5usec or 1msec? If you are receiving 10 messages per second, parsing out json and sending back a response or saving it to disk, does it always matter that it all happens in 10msec instead of 11msec. Maybe it does, I found it often doesn't.
- Qantourisc 14y ago
  Yes battery power and general speed. On the other hand, it's hard to sacrifice more/better programs over speed; but IMO it does matter.

lucian1900 14y ago

Alex's point is that Python on PyPy is trivially comparable to those C extensions in speed. So why give up Python, ever, if JITs are this good?

tptacek 14y ago
What if writing performant code on modern Python implementations is only incrementally easier than writing it in C to begin with? With the right libraries, the hard parts of C probably turn out to be string processing with zero-copy string idioms, the requirement to lay out every data structure in fiddly detail, the requirement to track individual allocations, and the requirement to manage the memory lifecycle. What if performant Python only gives you an advantage on the last one of those?
- NateDad 14y ago
  You can control the details without it having to be overly fiddly. Certainly you can do better than C. You may end up doing similar things, but your code will be way easier to write and read. Go does this quite well.
- lucian1900 14y ago
  I would say that the difference between fast Python code and C is still quite large. - the syntax is less error-prone - ownership semantics are much clearer. You'll never segfault because you sent some memory into the wrong function - not as much detail is needed for memory layout, the JIT abstracts a lot of it away - there are high-level APIs handy - development and distribution are simpler with one less language - the barrier to optimising things is lower
  - tptacek 14y ago
    I'm interested in this discussion. Which of those issues could you dispense with using more modern APIs and idioms in C? Look at Objective C (mentally wipe off all the object goo), particular NSMutableString and NSMutableArray and NSMutableData, for examples of what I'm thinking about. The C syntax we're stuck with. But how big a deal is that syntax? Segfaults are mitigated if you don't expose pointers, except to the extent that C programmers have to think about memory lifecycle (like I said, I think this is indisputably a win for high level languages). Look at NSMutableString for an example of a C-style idiom that removes whole classes of pointer operations. I dispute that JITs abstract away details about storage; they may allow you to not think about those details for code that doesn't need to be performant, and they can help the language get out of the way when you need to care about the storage details, but the question I'm asking is limited to performant code. There is no question that nonperformant Python code is way easier to write than any kind of C code! There are better APIs available in Python than are commonly available to C or even ObjC, but that's a solvable problem. Let's stipulate better APIs, to the limit of what the language would allow (in other words, it's totally fair to say that the design of C/C++ would prohibit certain kinds of easy APIs). Development and deployment are easier in some cases for Python (for instance, building on OS X and deploying on Linux), but far easier for C in others (for instance, building code that will run in a kernel or as a plugin in the address space of another process). I dispute that the barrier to optimization is lower in Python for obvious reasons: C programmers can optimize without working around the exposed wires and ductwork of the language runtime. C programmers generally have an easier time optimizing than Python programmers; that is probably the #1 reason any Python programmer ever writes C. As a current Golang programmer I agree strongly with the commenter below that when you take this idea and apply it to a new language you wind up with something that looks a lot like Go, which does work great. But I'm not advocating Go here.

MBlume 14y ago

If you're completely satisfied with Python's performance, that's wonderful. It means the talk wasn't aimed at you. Move along.

mistercow 14y ago

Speed in Python (or Ruby, or JS) isn't a big deal... until it is. When that happens, would you rather have to switch over to C and glue the resulting binary in (assuming you're not using JS, in which case you're just SOL), or would you rather have a high performance API at your fingertips for optimization when you need it?

pjscott 14y ago
Well, my usual answer there is to change the file extension to .pyx and see what Cython can do with a few type annotations. Usually the results are pretty good, and sometimes they're very good.
- mistercow 14y ago
  I think most of the gains you'd get from that would be orthogonal to the gains you would get from giving the JIT a little more information about allocations.
- omaranto 14y ago
  Does Cython give you much better results than PyPy? I would have thought that if just a few type annotations make a big difference tracing in PyPy could figure them out.
  - pjscott 14y ago
    I don't know. We're using a bunch of C extensions that aren't trivially compatible with PyPy, so using it isn't really an option -- which is a pity, since PyPy sounds pretty amazing. Cython, on the other hand, integrates really well with CPython, and it can be as fast as C if you need it to be. I'm pretty happy with it.

coldtea 14y ago

>Meh, MEH. I'm almost never waiting on my python code. I'm waiting on network or disk or database or joe to check in his changes or etc. Meh, MEH. That's because you don't do anything involved with your Python code. >I'm sure there are people who do wait. But that's why numpy, c extensions, all the pypy, psycho, and similar things exist. That they HAVE to exist could also be considered a sad state of affairs though. With a faster language you would just use the language, not external extensions and tricks.

slurgfest 14y ago
Anything involved with what? What kind of specific task do you actually mean by 'involved'? If you don't mind leaving Python's advantages on the table then use C in good health. Odds are that other people will be waiting on you to produce the C code, so let's hope you actually needed to do that.