6 ms·

However, as posters in other thread said, the number and availability of libraries makes functionality of those small programs exceed that of much larger ones w

by ptero 9y ago

However, as posters in other thread said, the number and availability of libraries makes functionality of those small programs exceed that of much larger ones written in C or a similar language. If you have to write a large project from scratch in Python it will be slow, but Python has gone pretty far in the direction where for many large tasks 90% of the functionality will be obtainable through standard libraries. Doing the remaining 10% in basic Python often keeps it competitive at runtime with compiled languages but produce much simpler, shorter and easier to maintain code.

weberc2 9y ago
Python has great libraries, but the claim that you can use them and have code that competes with compiled languages is flat out wrong. CPython is at least an order of magnitude slower than Java/Go/Haskell/etc and two orders slower than C/C++/Rust/etc. PyPy closes the gap a bit, but it's still noticeably slower than the aforementioned compiled languages. Note to responders--HN won't let me respond to you, because "I'm posting too fast".
- acdha 9y ago
  Those statements are too broad to be anything other than flamebait. Which specific code did you benchmark? That’s not to say that CPython isn’t slower than a compiled language but in common usage the gaps usually end up being much smaller because most of us aren’t paid to run fib() and things like I/O dominate or code ends up being in the same C libraries (libjpeg, OpenSSL, etc.). I’ve seen multiple cases where Python beat C/Go because the app used something like dictionaries which was heavily optimized C code in the standard library. Again, compiled languages should usually win but the details matter, especially since most people don’t do the exact same work you do. Simply tossing around big numbers with no support contributes noise rather than insight to the conversation.
  - hasenj 9y ago
    > Which specific code did you benchmark? I had a csv file with ~16k entries. Each entry has a lat, lon, name and id. The task: given a (lat, lon) pair, list all entries within 5km. The simplest straight forward solution is to iterate the list, measure the distance of each item to the given point, and add it to the return list if the distance is within the desired range. No crazy optimization or anything. The results were something roughly like this: The D version runs in 2~4ms when compiled with optimizations turned on to the max, and about 6~8ms without optimizations (just default compiler settings). The Go version runs in about 6~8ms. (The Go compiler has no option to produce optimized code). The python version runs in about 50ms. That's 10x slower than Go and 20x slower than D. This is python 3. Using pypy shows absolutely no difference in performance. Obviously the time to load the data from the csv file into a list is not counted in the above results. > I’ve seen multiple cases where Python beat C/Go because the app used something like dictionaries which was heavily optimized C code in the standard library. That's exactly backwards. The Go and D versions use structs which are compact data structures that pack the data together. So the entire array fits in one contiguous block of memory. Python has no concept of structs, so you have to deal with dictionaries. In general, writing optimized code is not a good idea. You should almost always write the most plain and straight forward code. Because fast languages are fast by default, there's no optimization required. The straight forward solution is fast enough. If you are writing Python, your code will be slow by default. You will need to think about ways to optimize it if you want better performance.
    - weberc2 9y ago
      Worth noting that Python's csv library is optimized C, and it handily beats Go's so this benchmark must be dominated by non-CSV parsing.
      - hasenj 9y ago
        The csv parsing is not part of the benchmark. The only thing I measured is iterating the list and matching entries within range of the input coordinate.
    - maxerickson 9y ago
      People talk about numpy as a numerical library, another way to think of it is as an api for interacting with contiguous chunks of memory.
      - deleted 9y ago
        [deleted]
    - tychver 9y ago
      The whole Ruby VM only takes ~50ms to start, so that sounds a bit slow. I wrote a quick version in Ruby and it only takes 5ms: https://gist.github.com/jamatthews/d910a2b39c87a871264dd31d13d5db9a https://gist.github.com/jamatthews/d910a2b39c87a871264dd31d1...
      - hasenj 9y ago
        It's a bit more complicated. I'm measuring geographical distances so I'm using haversine from math import radians, cos, sin, asin, sqrt def distance(lat1: float, lon1: float, lat2: float, lon2: float) -> float: # taken from: https://stackoverflow.com/a/4913653/35364 # convert decimal degrees to radians lon1 = radians(lon1) lon2 = radians(lon2) lat1 = radians(lat1) lat2 = radians(lat2) # haversine formula dlon = lon2 - lon1 dlat = lat2 - lat1 a = sin(dlat/2)**2 + cos(lat1) * cos(lat2) * sin(dlon/2)**2 c = 2 * asin(sqrt(a)) r = 6371008 # Average radius of earth in meters return c * r
  - weberc2 9y ago
    > Those statements are too broad to be anything other than flamebait. Which specific code did you benchmark? > Simply tossing around big numbers with no support contributes noise rather than insight to the conversation. I resent that you characterize my comment as "flamebait" for lacking supporting evidence for my claim, when I was merely responding to your unsupported claim that Python competes with compiled languages. I chose to be broad because (as you point out), the range varies considerably by application and the margin for error is high, so it would be misleading to be artificially precise. It's perfectly reasonable that you want supporting evidence, but it doesn't make my post "lower quality" than yours. As for "what I benchmarked", my comment was based on a decade of experience with these languages, including translating many proprietary systems from one language to another (sometimes a faster->slower language and sometimes a slower->faster language depending on whether I was optimizing for performance or security or maintainability). > That’s not to say that CPython isn’t slower than a compiled language but in common usage the gaps usually end up being much smaller because most of us aren’t paid to run fib() and things like I/O dominate or code ends up being in the same C libraries (libjpeg, OpenSSL, etc.). > I’ve seen multiple cases where Python beat C/Go because the app used something like dictionaries which was heavily optimized C code in the standard library. I don't dispute that there are cases where Python beats naive C/Go. In particular, Python's csv lib is optimized C code, and it beats Go's CSV parser handily. If all you're doing is parsing CSVs and not actually calling into Python, you should probably stick with Python. While it's true that many applications are I/O bound, my figure was based on CPU time--it wouldn't make sense to judge languages by applications that are inherently I/O bound (although Go's async-by-default is much nicer than Python's async API). Besides, many applications are not I/O bound.
    - acdha 9y ago
      > I resent that you characterize my comment as "flamebait" for lacking supporting evidence for my claim, when I was merely responding to your unsupported claim that Python competes with compiled languages. My point was simply that while it's easy to sit around talking about microbenchmarks that's not helpful for most developers. I've seen this cycle repeat so many times over the last couple decades because we're culturally prone to focusing on very small things and ignoring the larger picture: Most developers are not employed to make a single thing as fast as possible but instead have to ship new features on a regular basis, handle a wide range of inputs correctly, etc. Most of the performance problems people notice are due to application logic rather than low-level language characteristics, and that tends to mean things like I/O (API calls, poor file access patterns, etc.) or inefficient memory access patterns rather than how fast a loop can be. I've seen slow applications in compiled languages replaced with a dynamic language and a big performance win not because of the underlying language characteristics but because writing in a lower-level (C, C++, Go) or more convoluted (Java J2EE) environment took enough longer that the development team was struggling just to complete features and the {Perl,PHP,Python,JS} team had considerably more time to optimize the core design. I've also seen developers in all of those create huge labyrinths which made it hard to reason about the code's performance characteristics, and so my main concern these days is far less caring about the language than the overall amount of complexity you're asking developers to reason about and the related questions about the project and staffing. Given unlimited time and budget, yes, a compiled language will probably win but for most projects the better question is “what tools will allow me to meet my goals with acceptable performance?” and that's a very different question.
- ptero 9y ago
  Can you provide some pointers / examples? This is an honest question -- I am not an expert on bare computation speed, but this (two orders of magnitude vs C++) has not been my experience.
  - whyever 9y ago
    http://benchmarksgame.alioth.debian.org/u64q/binarytrees.html http://benchmarksgame.alioth.debian.org/u64q/binarytrees.htm...
  - igouy 9y ago
    A broad range -- Python programs are "as-fast-as-C" when they are C :-) http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=python3&lang2=gpp http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
- hyperpape 9y ago
  Unless you're using order of magnitude to mean 2x, it's not the case that Java/Go/Haskell are an order of magnitude slower than C/C++/Rust. You can see that on the benchmarks game, the techempower benchmarks, or this lovely paper on optimizing Haskell and C: http://www.leafpetersen.com/leaf/publications/ifl2013/haskell-gap.pdf http://www.leafpetersen.com/leaf/publications/ifl2013/haskel....
  - weberc2 9y ago
    I agree that the average is probably around 2X, but the variance and margin for error are pretty large, so I approximated. I didn't mean to imply that there was exactly a tenfold difference.
  - whyever 9y ago
    > Unless you're using order of magnitude to mean 2x, it's not the case that Java/Go/Haskell are an order of magnitude slower than C/C++/Rust. It depends, in some benchmarks they are 10 times slower.
    - hyperpape 9y ago
      And you can construct cases where the JVM is infinitely faster than C/C++/Rust, because the JIT optimizes through a virtual call and detects dead code. Should we say that "it depends, in some cases, Java is infinitely faster than C/C++/Rust"? Not unless we want to deliberately obscure the issue (or we want to warn someone about strange results). Benchmarks are about finding representative results across a variety of tasks. If you think there are good benchmarks that show these languages are 10x slower in realistic cases, then you should share them, rather than just asserting that they're out there.
      - weberc2 9y ago
        This is kind of my point; the variance and error margin are pretty wide. Specifying "2x" implies a precision I can't vouch for, so I settled for "an order of magnitude" as the general ballpark. If the 2x figure is important to you, I'm happy to make that concession.

by ptero 9y ago

weberc2 9y ago

Python has great libraries, but the claim that you can use them and have code that competes with compiled languages is flat out wrong. CPython is at least an order of magnitude slower than Java/Go/Haskell/etc and two orders slower than C/C++/Rust/etc. PyPy closes the gap a bit, but it's still noticeably slower than the aforementioned compiled languages. Note to responders--HN won't let me respond to you, because "I'm posting too fast".

acdha 9y ago
Those statements are too broad to be anything other than flamebait. Which specific code did you benchmark? That’s not to say that CPython isn’t slower than a compiled language but in common usage the gaps usually end up being much smaller because most of us aren’t paid to run fib() and things like I/O dominate or code ends up being in the same C libraries (libjpeg, OpenSSL, etc.). I’ve seen multiple cases where Python beat C/Go because the app used something like dictionaries which was heavily optimized C code in the standard library. Again, compiled languages should usually win but the details matter, especially since most people don’t do the exact same work you do. Simply tossing around big numbers with no support contributes noise rather than insight to the conversation.
- hasenj 9y ago
  > Which specific code did you benchmark? I had a csv file with ~16k entries. Each entry has a lat, lon, name and id. The task: given a (lat, lon) pair, list all entries within 5km. The simplest straight forward solution is to iterate the list, measure the distance of each item to the given point, and add it to the return list if the distance is within the desired range. No crazy optimization or anything. The results were something roughly like this: The D version runs in 2~4ms when compiled with optimizations turned on to the max, and about 6~8ms without optimizations (just default compiler settings). The Go version runs in about 6~8ms. (The Go compiler has no option to produce optimized code). The python version runs in about 50ms. That's 10x slower than Go and 20x slower than D. This is python 3. Using pypy shows absolutely no difference in performance. Obviously the time to load the data from the csv file into a list is not counted in the above results. > I’ve seen multiple cases where Python beat C/Go because the app used something like dictionaries which was heavily optimized C code in the standard library. That's exactly backwards. The Go and D versions use structs which are compact data structures that pack the data together. So the entire array fits in one contiguous block of memory. Python has no concept of structs, so you have to deal with dictionaries. In general, writing optimized code is not a good idea. You should almost always write the most plain and straight forward code. Because fast languages are fast by default, there's no optimization required. The straight forward solution is fast enough. If you are writing Python, your code will be slow by default. You will need to think about ways to optimize it if you want better performance.
  - weberc2 9y ago
    Worth noting that Python's csv library is optimized C, and it handily beats Go's so this benchmark must be dominated by non-CSV parsing.
    - hasenj 9y ago
      The csv parsing is not part of the benchmark. The only thing I measured is iterating the list and matching entries within range of the input coordinate.
  - maxerickson 9y ago
    People talk about numpy as a numerical library, another way to think of it is as an api for interacting with contiguous chunks of memory.
    - deleted 9y ago
      [deleted]
  - tychver 9y ago
    The whole Ruby VM only takes ~50ms to start, so that sounds a bit slow. I wrote a quick version in Ruby and it only takes 5ms: https://gist.github.com/jamatthews/d910a2b39c87a871264dd31d13d5db9a https://gist.github.com/jamatthews/d910a2b39c87a871264dd31d1...
    - hasenj 9y ago
      It's a bit more complicated. I'm measuring geographical distances so I'm using haversine from math import radians, cos, sin, asin, sqrt def distance(lat1: float, lon1: float, lat2: float, lon2: float) -> float: # taken from: https://stackoverflow.com/a/4913653/35364 # convert decimal degrees to radians lon1 = radians(lon1) lon2 = radians(lon2) lat1 = radians(lat1) lat2 = radians(lat2) # haversine formula dlon = lon2 - lon1 dlat = lat2 - lat1 a = sin(dlat/2)**2 + cos(lat1) * cos(lat2) * sin(dlon/2)**2 c = 2 * asin(sqrt(a)) r = 6371008 # Average radius of earth in meters return c * r
- weberc2 9y ago
  > Those statements are too broad to be anything other than flamebait. Which specific code did you benchmark? > Simply tossing around big numbers with no support contributes noise rather than insight to the conversation. I resent that you characterize my comment as "flamebait" for lacking supporting evidence for my claim, when I was merely responding to your unsupported claim that Python competes with compiled languages. I chose to be broad because (as you point out), the range varies considerably by application and the margin for error is high, so it would be misleading to be artificially precise. It's perfectly reasonable that you want supporting evidence, but it doesn't make my post "lower quality" than yours. As for "what I benchmarked", my comment was based on a decade of experience with these languages, including translating many proprietary systems from one language to another (sometimes a faster->slower language and sometimes a slower->faster language depending on whether I was optimizing for performance or security or maintainability). > That’s not to say that CPython isn’t slower than a compiled language but in common usage the gaps usually end up being much smaller because most of us aren’t paid to run fib() and things like I/O dominate or code ends up being in the same C libraries (libjpeg, OpenSSL, etc.). > I’ve seen multiple cases where Python beat C/Go because the app used something like dictionaries which was heavily optimized C code in the standard library. I don't dispute that there are cases where Python beats naive C/Go. In particular, Python's csv lib is optimized C code, and it beats Go's CSV parser handily. If all you're doing is parsing CSVs and not actually calling into Python, you should probably stick with Python. While it's true that many applications are I/O bound, my figure was based on CPU time--it wouldn't make sense to judge languages by applications that are inherently I/O bound (although Go's async-by-default is much nicer than Python's async API). Besides, many applications are not I/O bound.
  - acdha 9y ago
    > I resent that you characterize my comment as "flamebait" for lacking supporting evidence for my claim, when I was merely responding to your unsupported claim that Python competes with compiled languages. My point was simply that while it's easy to sit around talking about microbenchmarks that's not helpful for most developers. I've seen this cycle repeat so many times over the last couple decades because we're culturally prone to focusing on very small things and ignoring the larger picture: Most developers are not employed to make a single thing as fast as possible but instead have to ship new features on a regular basis, handle a wide range of inputs correctly, etc. Most of the performance problems people notice are due to application logic rather than low-level language characteristics, and that tends to mean things like I/O (API calls, poor file access patterns, etc.) or inefficient memory access patterns rather than how fast a loop can be. I've seen slow applications in compiled languages replaced with a dynamic language and a big performance win not because of the underlying language characteristics but because writing in a lower-level (C, C++, Go) or more convoluted (Java J2EE) environment took enough longer that the development team was struggling just to complete features and the {Perl,PHP,Python,JS} team had considerably more time to optimize the core design. I've also seen developers in all of those create huge labyrinths which made it hard to reason about the code's performance characteristics, and so my main concern these days is far less caring about the language than the overall amount of complexity you're asking developers to reason about and the related questions about the project and staffing. Given unlimited time and budget, yes, a compiled language will probably win but for most projects the better question is “what tools will allow me to meet my goals with acceptable performance?” and that's a very different question.
ptero 9y ago
Can you provide some pointers / examples? This is an honest question -- I am not an expert on bare computation speed, but this (two orders of magnitude vs C++) has not been my experience.
- whyever 9y ago
  http://benchmarksgame.alioth.debian.org/u64q/binarytrees.html http://benchmarksgame.alioth.debian.org/u64q/binarytrees.htm...
- igouy 9y ago
  A broad range -- Python programs are "as-fast-as-C" when they are C :-) http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=python3&lang2=gpp http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
hyperpape 9y ago
Unless you're using order of magnitude to mean 2x, it's not the case that Java/Go/Haskell are an order of magnitude slower than C/C++/Rust. You can see that on the benchmarks game, the techempower benchmarks, or this lovely paper on optimizing Haskell and C: http://www.leafpetersen.com/leaf/publications/ifl2013/haskell-gap.pdf http://www.leafpetersen.com/leaf/publications/ifl2013/haskel....
- weberc2 9y ago
  I agree that the average is probably around 2X, but the variance and margin for error are pretty large, so I approximated. I didn't mean to imply that there was exactly a tenfold difference.
- whyever 9y ago
  > Unless you're using order of magnitude to mean 2x, it's not the case that Java/Go/Haskell are an order of magnitude slower than C/C++/Rust. It depends, in some benchmarks they are 10 times slower.
  - hyperpape 9y ago
    And you can construct cases where the JVM is infinitely faster than C/C++/Rust, because the JIT optimizes through a virtual call and detects dead code. Should we say that "it depends, in some cases, Java is infinitely faster than C/C++/Rust"? Not unless we want to deliberately obscure the issue (or we want to warn someone about strange results). Benchmarks are about finding representative results across a variety of tasks. If you think there are good benchmarks that show these languages are 10x slower in realistic cases, then you should share them, rather than just asserting that they're out there.
    - weberc2 9y ago
      This is kind of my point; the variance and error margin are pretty wide. Specifying "2x" implies a precision I can't vouch for, so I settled for "an order of magnitude" as the general ballpark. If the 2x figure is important to you, I'm happy to make that concession.