4 ms·

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

by 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)

by ynniv 14y ago

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)