6 ms·

Python is fast enough, until it isn't and then there are no simple alternatives. If your problem is numerical in nature, you can call popular C modules (numpy,

by wting 12y ago

Python is fast enough, until it isn't and then there are no simple alternatives. If your problem is numerical in nature, you can call popular C modules (numpy, etc) or write your own. If your functions and data are pickleable, you can use multiprocessing but run into Amdahl's Law. Maybe you try Celery / Gearman introducing IO bottlenecks transferring data to workers. Otherwise you might end up with PyPy (poor CPython extension module support) and still restricted by the GIL. Or you'll try Cython, a bastard of C and Python. Python has been my primary language the past few years and it's great for exploratory coding, prototypes, or smaller projects. However it's starting to lose some of the charm. Julia is filling in as a great substitute for scientific coding in a single language stack, and Go / Rust / Haskell for the other stuff. I've switched back to the static language camp after working in a multi-MLOC Python codebase.

teacup50 12y ago
If you think of CPU cycles as currency, "fast enough" shows its true colors: if you're profligate in your spending of CPU cycles, you simply don't have any left when you really so need them. Living CPU paycheck to paycheck and on occasion taking performance payday loans (breaking out to C) is not an efficient way to manage resources.
- LaurensBER 12y ago
  Given the cost of CPU cycles vs Developers I don't think this analogy works. Sure, you can hire an extra C++ developer for 150k or just give your python developer a company credit card to use for extra AWS machines. I'm quite sure the second option is a lot cheaper.
  - teacup50 12y ago
    There are actually two common fallacies here; I'll try to handle them separately. CPU Cycles vs Developers This is a common false dichotomy: that expending more CPU cycles on the language runtime makes a language more efficient in terms of developer productivity than a language that expends fewer CPU cycles on its runtime. The inherent truth of this statement isn't deductively obvious, however. If you assume, for example, that dynamic languages are more productive for developers (I don't, but it's a common argument, so we'll go with it), then this is easily disproven simply by comparing the performance of a highly optimized JIT -- such as V8's -- against Python's interpreter. Irrespective of the language, there exists differing levels of quality of runtime. V8 is faster than Python; this is simply because V8 is a better runtime JIT than Python is an interpreter. If we discard the unproven "dynamic languages are more developer efficient" hypothesis, things become even more stark. The JVM, for example, with real threads, highly optimized JIT, and the advantages of operating on a much more well-typed system, is in fact faster than V8 -- all with a "managed" language, and not C++. Taking that a step further, we've recently begun rediscovering ahead-of-time compilation of so called "managed" or "high-level" languages. The favoritism given towards JIT arose out of efforts to achieve high performance in dynamic languages were very little can be statically guaranteed. What has recently become clear is this: in more static languages, we can achieve the same level of "managed" runtime without introducing the overhead or complexity of JIT at all! All combined, I see very little argument for a dichotomous choice between "inefficient, high level language" or "efficient, low level language" -- the choices seem to simply be "inefficient" vs "efficient". Relative Value of High-Paid Developers Lastly, I wish to address the "extra C++ developer for 150K". I'll keep this one brief -- simply put, I would hypothesize that a $150K expert-level engineer is worth anywhere from 2-10 $80K non-expert engineers. This is simply due to an expert-level engineer's experience and deep knowledge of the technology stack allowing them to architect systems to achieve maximum maintenance, developer and system efficiency over time. Computing is a value multiplier: the potential gains and losses of lower multipliers can be objectively enormous. Having managed teams where I've inherited cheaper, more junior engineers, versus teams where I've hand-picked a small group of extremely experienced engineers, I've saved time, money, and headaches with the more expensive engineers every time.
    - mcguire 12y ago
      Very interesting response. I strongly agree with most of it. However, I think there's another false dichotomy there: a $150K expert-level engineer versus $80K non-expert engineers. In reality, there are only expert and non-expert engineers---pay doesn't seem to be a particularly discriminator. Further, in all respects it is difficult to tell the difference between an expert and a non-expert, hence all the fun interviewing follies. And even the best of those don't work particularly well.
      - teacup50 12y ago
        Thanks for your reply; I concur with both of your assertions. When it comes to differentiating expertise, we often have to look for secondary indicators; pay has an extremely poor correlation with competence, especially in high-demand job markets.
  - throwaway0010 12y ago
    Depends on scale. For startups with small datasets and low traffic, hardware is cheaper. When traffic and data ramp up, 150k for a guy to cut your capex by 10% sounds like a steal.
oblique63 12y ago
> Julia is filling in as a great substitute for scientific coding in a single language stack, and Go / Rust / Haskell for the other stuff. I've been wondering about why so many python devs have migrated to using Go recently instead of Julia, given that Julia is a lot closer to python and has performed as good as, if not better than, Go in some benchmarks [1]. Granted I've really only toyed with Julia and Go a few times as I've never really needed the performance much myself, but I'm curious about your preference of Go/Rust over Julia for "the other stuff". What would you say makes Julia less suitable (or Go more suitable) for nonscientific applications? Is it just the community/support aspect? Cause that seems like an easy tide to overturn by simply raising more awareness about it (we see Go/Rust/Haskell blog posts on the front page of HN every week, but not too many Julia posts). Just curious cause I'm not nearly experienced enough with any of these young languages yet to know any better, and have only recently started to consider taking at least one of them up more seriously. [1] http://julialang.org/benchmarks/ http://julialang.org/benchmarks/
- Osmium 12y ago
  You can write Julia code in an IPython notebook, which is great. And (as I recently learnt) there's a PyCall package to easily call Python functions from within Julia, so you can take advantage of Python packages too. I'm yet to try Go, but Julia is great for me: it's like all the good parts of Python + extra speed. You get the interactivity, the good documentation, the community, the packages, and all bundled into something that's easy to use and gives you code that runs many times faster than native Python with no real extra effort.
- awda 12y ago
  Just a few guesses: - It doesn't have Google / Thompson / Rsc / etc behind it - It looks more like Ruby than C (say what you will about C-like syntax, but I think the success of Java and C++ has proved that point) But you're right, I ought to look into it.
  - film42 12y ago
    I can't find the source, but I recall Rob Pike talking about how the Go language and syntax are designed to "scale". Naturally, Mr. Pike would opt for a C style syntax, but with tools like go fmt and the package manager built in to the tooling from day 1, he kind of has a point.
illumen 12y ago
Do you have any specific publicity available code which you claim is too slow in python? Otherwise, I don't believe you. For example, hg is now faster than git. Git is written by great C hackers (including Linus no less), and yet hg is faster than git. See the facebook benchmarks for evidence. Python has static checking of interfaces, and types if you want. It also has IDEs which can check a lot of things for you. It turns out that dynamic typed languages can be checked for quite a lot of things. Check out using mmap based datastructures to do shared memory between workers.
- adwn 12y ago
  > For example, hg is now faster than git. You're comparing the runtimes of two different algorithms, so your results are inevitably meaningless. > It turns out that dynamic typed languages can be checked for quite a lot of things. And yet, statically typed languages can still be checked for a lot more things.
  - illumen 12y ago
    'And yet, statically typed languages can still be checked for a lot more things.' What is your evidence? Can you provide a citation? Modern tools can statically check python for a lot of things. Here are some things you can statically check with python: * implements an interface * unused names * assigned but never used There's hundreds more things you can check for with tools like pylint and some of the IDEs. That 'implements an interface' one is important. Since with interfaces you can specify things like return types, and type arguments. There are also @param markers in doc strings, where you can specify argument and return types. These can be used by tools like IDEs (eg pycharm) and other static checkers. Full program type inference is now doable for large parts of python. See the shedskin, and Rpython restricted subsets for two implementations.
- coldtea 12y ago
  From Mercurial's website: >most of Mercurial is written in Python, with a small part in portable C for performance reasons.
vkhuc 12y ago
Besides Julia, I think another alternate language to Python for scientific computation would be Scala. Breeze (from ScalaNLP project) is an effort to bring Numpy and Matlab syntax to Scala: https://github.com/scalanlp/breeze/wiki/Breeze-Linear-Algebra https://github.com/scalanlp/breeze/wiki/Breeze-Linear-Algebr... The learning curve for Scala may be steep though.
JasonFruit 12y ago
Not a big or important point, but note that many critical bits of numpy are in Fortran, not C.
- plus 12y ago
  This is actually not true. All Fortran routines are packaged with SciPy, as one of the explicit goals of NumPy is to be installable without a Fortran compiler.

by wting 12y ago

teacup50 12y ago

If you think of CPU cycles as currency, "fast enough" shows its true colors: if you're profligate in your spending of CPU cycles, you simply don't have any left when you really so need them. Living CPU paycheck to paycheck and on occasion taking performance payday loans (breaking out to C) is not an efficient way to manage resources.

LaurensBER 12y ago
Given the cost of CPU cycles vs Developers I don't think this analogy works. Sure, you can hire an extra C++ developer for 150k or just give your python developer a company credit card to use for extra AWS machines. I'm quite sure the second option is a lot cheaper.
- teacup50 12y ago
  There are actually two common fallacies here; I'll try to handle them separately. CPU Cycles vs Developers This is a common false dichotomy: that expending more CPU cycles on the language runtime makes a language more efficient in terms of developer productivity than a language that expends fewer CPU cycles on its runtime. The inherent truth of this statement isn't deductively obvious, however. If you assume, for example, that dynamic languages are more productive for developers (I don't, but it's a common argument, so we'll go with it), then this is easily disproven simply by comparing the performance of a highly optimized JIT -- such as V8's -- against Python's interpreter. Irrespective of the language, there exists differing levels of quality of runtime. V8 is faster than Python; this is simply because V8 is a better runtime JIT than Python is an interpreter. If we discard the unproven "dynamic languages are more developer efficient" hypothesis, things become even more stark. The JVM, for example, with real threads, highly optimized JIT, and the advantages of operating on a much more well-typed system, is in fact faster than V8 -- all with a "managed" language, and not C++. Taking that a step further, we've recently begun rediscovering ahead-of-time compilation of so called "managed" or "high-level" languages. The favoritism given towards JIT arose out of efforts to achieve high performance in dynamic languages were very little can be statically guaranteed. What has recently become clear is this: in more static languages, we can achieve the same level of "managed" runtime without introducing the overhead or complexity of JIT at all! All combined, I see very little argument for a dichotomous choice between "inefficient, high level language" or "efficient, low level language" -- the choices seem to simply be "inefficient" vs "efficient". Relative Value of High-Paid Developers Lastly, I wish to address the "extra C++ developer for 150K". I'll keep this one brief -- simply put, I would hypothesize that a $150K expert-level engineer is worth anywhere from 2-10 $80K non-expert engineers. This is simply due to an expert-level engineer's experience and deep knowledge of the technology stack allowing them to architect systems to achieve maximum maintenance, developer and system efficiency over time. Computing is a value multiplier: the potential gains and losses of lower multipliers can be objectively enormous. Having managed teams where I've inherited cheaper, more junior engineers, versus teams where I've hand-picked a small group of extremely experienced engineers, I've saved time, money, and headaches with the more expensive engineers every time.
  - mcguire 12y ago
    Very interesting response. I strongly agree with most of it. However, I think there's another false dichotomy there: a $150K expert-level engineer versus $80K non-expert engineers. In reality, there are only expert and non-expert engineers---pay doesn't seem to be a particularly discriminator. Further, in all respects it is difficult to tell the difference between an expert and a non-expert, hence all the fun interviewing follies. And even the best of those don't work particularly well.
    - teacup50 12y ago
      Thanks for your reply; I concur with both of your assertions. When it comes to differentiating expertise, we often have to look for secondary indicators; pay has an extremely poor correlation with competence, especially in high-demand job markets.
- throwaway0010 12y ago
  Depends on scale. For startups with small datasets and low traffic, hardware is cheaper. When traffic and data ramp up, 150k for a guy to cut your capex by 10% sounds like a steal.

oblique63 12y ago

> Julia is filling in as a great substitute for scientific coding in a single language stack, and Go / Rust / Haskell for the other stuff. I've been wondering about why so many python devs have migrated to using Go recently instead of Julia, given that Julia is a lot closer to python and has performed as good as, if not better than, Go in some benchmarks [1]. Granted I've really only toyed with Julia and Go a few times as I've never really needed the performance much myself, but I'm curious about your preference of Go/Rust over Julia for "the other stuff". What would you say makes Julia less suitable (or Go more suitable) for nonscientific applications? Is it just the community/support aspect? Cause that seems like an easy tide to overturn by simply raising more awareness about it (we see Go/Rust/Haskell blog posts on the front page of HN every week, but not too many Julia posts). Just curious cause I'm not nearly experienced enough with any of these young languages yet to know any better, and have only recently started to consider taking at least one of them up more seriously. [1] http://julialang.org/benchmarks/ http://julialang.org/benchmarks/

Osmium 12y ago
You can write Julia code in an IPython notebook, which is great. And (as I recently learnt) there's a PyCall package to easily call Python functions from within Julia, so you can take advantage of Python packages too. I'm yet to try Go, but Julia is great for me: it's like all the good parts of Python + extra speed. You get the interactivity, the good documentation, the community, the packages, and all bundled into something that's easy to use and gives you code that runs many times faster than native Python with no real extra effort.
awda 12y ago
Just a few guesses: - It doesn't have Google / Thompson / Rsc / etc behind it - It looks more like Ruby than C (say what you will about C-like syntax, but I think the success of Java and C++ has proved that point) But you're right, I ought to look into it.
- film42 12y ago
  I can't find the source, but I recall Rob Pike talking about how the Go language and syntax are designed to "scale". Naturally, Mr. Pike would opt for a C style syntax, but with tools like go fmt and the package manager built in to the tooling from day 1, he kind of has a point.

illumen 12y ago

Do you have any specific publicity available code which you claim is too slow in python? Otherwise, I don't believe you. For example, hg is now faster than git. Git is written by great C hackers (including Linus no less), and yet hg is faster than git. See the facebook benchmarks for evidence. Python has static checking of interfaces, and types if you want. It also has IDEs which can check a lot of things for you. It turns out that dynamic typed languages can be checked for quite a lot of things. Check out using mmap based datastructures to do shared memory between workers.

adwn 12y ago
> For example, hg is now faster than git. You're comparing the runtimes of two different algorithms, so your results are inevitably meaningless. > It turns out that dynamic typed languages can be checked for quite a lot of things. And yet, statically typed languages can still be checked for a lot more things.
- illumen 12y ago
  'And yet, statically typed languages can still be checked for a lot more things.' What is your evidence? Can you provide a citation? Modern tools can statically check python for a lot of things. Here are some things you can statically check with python: * implements an interface * unused names * assigned but never used There's hundreds more things you can check for with tools like pylint and some of the IDEs. That 'implements an interface' one is important. Since with interfaces you can specify things like return types, and type arguments. There are also @param markers in doc strings, where you can specify argument and return types. These can be used by tools like IDEs (eg pycharm) and other static checkers. Full program type inference is now doable for large parts of python. See the shedskin, and Rpython restricted subsets for two implementations.
coldtea 12y ago
From Mercurial's website: >most of Mercurial is written in Python, with a small part in portable C for performance reasons.

vkhuc 12y ago

Besides Julia, I think another alternate language to Python for scientific computation would be Scala. Breeze (from ScalaNLP project) is an effort to bring Numpy and Matlab syntax to Scala: https://github.com/scalanlp/breeze/wiki/Breeze-Linear-Algebra https://github.com/scalanlp/breeze/wiki/Breeze-Linear-Algebr... The learning curve for Scala may be steep though.

JasonFruit 12y ago

Not a big or important point, but note that many critical bits of numpy are in Fortran, not C.

plus 12y ago
This is actually not true. All Fortran routines are packaged with SciPy, as one of the explicit goals of NumPy is to be installable without a Fortran compiler.