28 ms·

What's Going On (on "Why Python, Ruby, and Javascript are Slow")

283 points by ANTSANTS 14y ago

YesThatTom2 14y ago
Wouldn't adding goland-style slices to Python be awesome?
- kkuduk 14y ago
  well, there are memoryviews, but they could have been designed better
  - travisoliphant 14y ago
    Memoryviews are the step-child of NumPy arrays. The buffer-protocol was the real intent and the memory view the forgotten "example" until a few brave and noble Python devs rescued it from obscurity. Memory-views are not that useful to one who will always have NumPy installed.
- almost 14y ago
  It's not quite the same but some of the use cases (and a bunch of other stuff) would be covered by numpy arrays. You can create multiple views on the same in memory data with different start and end points and different strides.
  - dagw 14y ago
    Agreed. I think numpy arrays a rather overlooked by most python programmers. They allow all kinds of useful tricks like that that are quite handy even if you're not doing strictly numeric work.
RegRegReg 14y ago
The biggest confusion is seeing Python/Ruby/JS as a programming languages. They are not. They are scripting languages. Something you put on top of your core code.
- pekk 14y ago
  Does the phrase "scripting language" have any hard technical meaning or is it just another subjective label?
  - voidlogic 14y ago
    I've always informally thought of a scripting language as anything the executes by interpreting source code or bytecode (lacking JIT compilation).
- doktrin 14y ago
  This might make sense if you contrasted "scripting" to something a little more specific, like "system" development. However, creating a "programming" v. "scripting" dichotomy makes no sense IMHO. Ruby & Python are programming languages that can also be considered, informally, scripting languages.
martinced 14y ago
The reason JavaScript is dog slow is single-threading. That's quite a huge handicap on today's hardware and it's only gonna get worse and worse until JavaScript engines becomes multi-threaded. Besides that, I don't disagree with TFA when it says: "Garbage collection means cleaner APIs which can intelligently allocate their own buffers and can therefore relieve the user of what can be a tiresome or error-prone burden." But that's certainly not an explanation as to why GC languages are not slow. (and I'm not saying GC languages are slow: all I'm saying is that saying that GC leads to cleaner code has nothing to do with performances of the runtime)
cjh_ 14y ago
Very interesting read. I have only written a small amount of Go, I have been through tour.golang.org, just waiting for the right project for me to use it on. Currently whenever a new project comes along I reach for C or Perl, hoping to find a niche between them for Go.
- berntb 14y ago
  The feature with scripting languages compared with system languages (C, Java, etc) is that they are fast -- not to run code, but to develop functionality. The article argued that idiomatic Go gave at least as good runtime speedup as a normal scripting language (Perl, Ruby, etc) with the (small) time critical parts rewritten in C. But it didn't touch the important question -- is the development time for Go faster than for scripting languages with critical sections in C? Go looks fun, but I'd personally want information on that metric before trying it on a project. [Edit: Yeah, as the article noted, Go excels re parallelization etc. I might Go for it in those use cases.] (What I'd really want is to find a place which use Lisp, since development speed is roughly as fast as for scripting languages and there has been good compilers for decades.) Edit: Spelling, must start going over the room for the keyboard when using the iPad.
  - voidlogic 14y ago
    "But he didn't touch the important question -- is the development time for Go faster than for scripting languages + C?" That is a good question, but- Isn't that going to vary a lot by the person/team involved? Calculating "effort" is far more difficult than run-time or complexity characteristics. Doesn't that question also assume that people writing in the scripting language can write (correct/decent/secure) C. Ironically, I have a strong feeling that many more Go developers can write C than say Ruby or PHP devs.
    - berntb 14y ago
      >>Calculating "effort" is far more difficult than run-time or complexity characteristics. If it really was impossible to measure development/support speed, then we'd still use hex code with switches on a console. :-) And yeah, kids today often don't learn C at school, it is a pity.
voidlogic 14y ago
Since the author uses Go as a basis of comparison. I thought these benchmarks from The Computer Language Benchmarks Game might be interesting: Go vs. Ruby: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=yarv http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te... Go vs. Python: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=python3 http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te... Note: These results are from the 64-bit single core machine since it has already been updated to Go 1.1 beta 1. There is also a faster Go regex program (#7) that hopefully can be made to work again after 1.1 is released (in place of #1). Although still using Go 1.0.X ,the recent TechEmpower benchmarks might be interesting if you have not seen them: http://www.techempower.com/blog/2013/03/28/framework-benchmarks/ http://www.techempower.com/blog/2013/03/28/framework-benchma... (It looks like Go 1.1 might be 3x faster: https://gist.github.com/errnoh/5320784 https://gist.github.com/errnoh/5320784) P.S. As always your own program is always the best benchmark to use, your millage may very, take your gain of salt, etc etc.
- yew 14y ago
  Probably worth noting that the presentation that the author is discussing is less about 'which language is faster' and more about what sort of abstractions different types of languages encourage. The presenter explicitly takes the position that Go and Python (actually PyPy) should be equally fast given the same sort of operations. Just that Python's idioms tend to be less efficient. He's a PyPy developer too, so I would think he would know something about what's going on under the hood. (He also talks a bit about why the VM doesn't/shouldn't try to optimize these cases automatically. Worth a look, it isn't long.)
  - ealloc 14y ago
    Good summary. But I disagree with the author that immutable strings and ubiquitous hashes are merely unfortunate idioms of python - to me python is about simplicity, and those things are what make python conceptually simple. I don't have to worry about clobbered buffers, nor about datastructure semantics besides simple hashes.
joe_the_user 14y ago
"Programmers of elegant scripting languages desire similarly elegant looking code with flexible data structures even where no flexibility is in play. Some who know better will understand that technical limitations make the difference between hashes and other types of named lookups essentially nil for many popular language runtimes." OK, if no flexibility is in play in many usages of hashmaps, should not an intelligent interpreter/compiler be able to detect this and modify the use of the hashmap accordingly? Maybe even use a different lookup system in those cases? It seems like that would be ... elegant. The reason VMs don't need to be slow is that you don't need to treat an eval call literally, you don't always need to create a full environment to parse a twenty character string, right? But if you can get around that, should you not be able to get around hash-map's problems? Am I missing something.
- cjh_ 14y ago
  This question is partially address in the articles linked to at the start [1] I linked to the slide that begins to mention it, rather short though. The answer is that we can add heuristics, but that we should also be able to solve this somewhat on a language/library level rather than only at a vm level. [1] https://speakerdeck.com/alex/why-python-ruby-and-javascript-are-slow?slide=34 https://speakerdeck.com/alex/why-python-ruby-and-javascript-...
  - joe_the_user 14y ago
    Yeah, Perhaps if I saw/heard the talk I would get more out of it than "data-structure heuristics are the worst". It would be nice to know why they are the worst.
  - makomk 14y ago
    Python already has a feature called __slots__ which replaces the dictionary normally used to store object attributes with fixed, well, slots.
- jes5199 14y ago
  Doesn't the V8 javascript engine do something like this? Where it builds C-structs instead of hashmaps if it can detect that your objects are being built in a consistent way
d0m 14y ago
Time of "Getting that shit done" and cost of long-term maintenance are two of the main reasons why people use Ruby/Python, not for the raw performance. I thought that was an old debate. And anyway, from my experience, Python has never been the cause of the slowness.. It's more about tweaking that DB query, smartly packaging the assets or using a better algorithm. (I know it's not always the case. I.e. If my program has to run in the space where bits could be randomly shifted, some additional thoughts would be needed, obviously.)
- jacobmarble 14y ago
  True, the author doesn't really address "effort to get shit done", but Others have commented on this and there seems to be consensus around "Go is a very human readable/writable language". Anyone know of a human read/write-ability comparison of programming languages?
  - zachrose 14y ago
    Depends on the human! (One end of the spectrum is a DSL customized to the concepts and patterns of domain experts.)
  - antiterra 14y ago
    Isn't that a useless comparison? Chinese, Tamil and Estonian are all extremely human read/writeable, so much that children can write them. However, it's likely at least one of them is indecipherable to you. Perhaps the metric you're more interested in is the difficulty in learning to read/write decent code in a particular language. Of course, this difficulty can vary based on what other languages the learner is already familiar with.
    - jesstaa 14y ago
      Chinese is often even indecipherable to the Chinese and because of this there have been many attempts to simplify it. There is a subset that people actually use and the rest is avoided. This is a similar case with languages like C++, Ruby and Python. The languages are terrifyingly complex, but the subset that most people use is reasonably usable. If you stray outside this subset there be dragons.
alexchamberlain 14y ago
On the to garbage collect or not issue briefly mentioned at the end, the best reason to use an unmanaged language is predictability of performance. You know the GC won't step in at a critical moment. I regularly get frustrated by Eclipse becoming unresponsive for several seconds.
- pjmlp 14y ago
  There are real time GCs for many languages that compile to native code. The way Eclipse is coded is not a good example of GC performance.
losethos 14y ago
I have a JIT C compiler. I thought you were picking a fight. I'm glad you are not.
pjmlp 14y ago
Overall nice article, it just looses a bit by focusing too much on Go vs Python issue. 1 - The are quite quite a few strong type languages with native code implementations since the mid-80's, even GC enabled, Go is not the only one. 2 - There are dynamic languages like Self, Dylan, Lisp even the young Julia that have implementations which achieve C like speeds when compiled to native code, especially when the developers make use of type annotations and use the right data structures. Self is specially important given that the research work, in a dynamic language, ended up being the heart of Sun's JIT compiler.
- batgaijin 14y ago
  Yeah I don't sympathize with ruby/python/go people. CL can be interpreted & compiled. Why the fuck is it okay to literally choose the worst options just because people don't like seeing an explicit AST?
  - pekk 14y ago
    Why specifically are these "literally the worst" options?
  - mratzloff 14y ago
    Because you can hire for those languages, but good luck hiring for CL.
- mwcampbell 14y ago
  Yes, there have been many other languages with ahead-of-time compilation and garbage-collected runtimes, but Go is one of the few that might be considered popular today. At this point, one might invoke the old chestnut, "If you make technology choices based on popularity, you might as well go with (Windows|PHP)." But there are degrees of popularity, and there are advantages in choosing something that's at least moderately popular, e.g. a large selection of ready-to-use libraries and a pool of developers who don't need to learn a new language on the job.
Moto7451 14y ago
I've noticed this in some code I've been refactoring at work recently (a feed generation system). It's easy in Perl to suck in a large amount of data into one array and map/grep it into another array of hashes and output filtered/formatted data in a few lines. The problem of course is that your business'/project's own growth overwhelms the algorithm as the data structure balloons. This is further compounded by libraries which are designed to accept an array as input (reinforcing the idiom causing the first problem) since you end up with thousands of additional iterations. I refactored the code to lazy load each item in the collection and map/filter/generate the XML at the end of each node's iteration. The end result is a nice flat memory space (save for the odd leak here and there) that's about 1/10th of the original program's, at the 'expense' of only a few more lines of code.
corresation 14y ago
Both the submission and the target of the submission dismiss dynamic typing as a source of slowdowns (in the unfortunately haughty, completely unsupported manner that is too common in the industry. It is, in effect, the head-in-the-sand approach: If you don't want something to be true, simply keep saying it isn't and somehow that will become reality), yet I guess we need to define what "slow" is then, using as an example an empirical test (ASM.JS) that certainly serves better than some people waving their hands about innovations in JIT compilers. The primary optimization that ASM.JS brings is its static type system. With that, and the obvious benefits to the code path, intensive activities can be run at 1/2 native speed, versus the 1/12th of so native speed available with dynamic typing. Is 1/12th native speed "slow"? In most cases -- where the code is the duct-tape that glues together native code (which is the case on web servers, admin scripts, etc), no, it isn't slow at all. But from a basic optimization perspective, asm.js sure seems to indict dynamic typing if you really care about squeezing every cycle's maximal output.
- gsnedders 14y ago
  No, the primary optimization asm.js brings (at least in OdinMonkey) is AOT compilation. Fully typed code should produce the same code from IonMonkey without OdinMonkey: the problem is you have to get up to 10k calls (at least last I looked!) of a function before you get there; but once you are there it is just as good. It's the build-up, through the interpreter and the less efficient code-generators (in terms of code generated, that is; they're more efficient in terms of their own runtime), which really hurts.
  - corresation 14y ago
    No, the primary optimization asm.js brings (at least in OdinMonkey) is AOT compilation. But it can do that precisely because of the static typing, which loops back to exactly what I said. Looser, more dynamic language always have a cost associated with that flexibility.
    - gsnedders 14y ago
      Arbitrary JS can be as statically typed as asm.js is (because, well, asm.js is just a subset). There's no reason why one couldn't compile AOT something like: function add_and_double(a, b) { a = a | 0; b = b | 0; var sum = (a + b) | 0; return (sum + sum) | 0; } Yes, it'd be trivial to fall off the AOT-compilation path (esp. without a defined subset that got AOT compilation and hence likely would differ between implementations), so static verification that you're on the AOT-compilation path is valuable (which asm.js provides), but it doesn't fundamentally alter the semantics of the language.
NateDad 14y ago
Everyone keeps saying "Use Python and write the slow parts in C"..... except that writing GOOD (secure, correct, safe) C is really hard. That's actually the main reason why the Go authors came up with Go. Not to replace Python etc, but to replace C/C++. I'm kind of surprised that all the "Python: let's get stuff done" people are suggesting writing a whole bunch of code in C, one of the least "Getting stuff done" languages there is. For those who have asked what the productivity of Go is like vs. Python + C: Go is very productive. When newbies to Go say it's "verbose" they mean "I have to write out some 3 line loops that in other languages are one line". If that's the major cause of slowness in my development cycle, I'd be ecstatic. Go is also very easy to write "correct" code in... no buffer overflows, no memory leaks, no access of random memory, no unnecessary allocations, and a very clear and defined behavior from clear, concise code.
- pekk 14y ago
  Nobody said you have to write any C. If you are freaking out about performance, the option to write some parts in C is valuable.
- gsnedders 14y ago
  Given the original presenter is one of the major contributors to PyPy, I'm fairly certain that wouldn't be his first advice: I'd expect it'd be to try PyPy (and file a bug if it's slower than CPython!). Also note on the last slide: "Stop writing C extensions, use something like cffi". There's two (really) good reasons you should do this: firstly, your code is no longer tied tied to CPython, so using alternative Python implementations (like PyPy) becomes viable; secondly, you don't have to use C — you can trivially use anything that exports functions using the C ABI.
- officemonkey 14y ago
  >"I have to write out some 3 line loops that in other languages are one line" I think every vim, emacs and decent IDE user would say "I has a text editor. Your argument is invalid."
  - stouset 14y ago
kalkin 14y ago
It's too bad that this discussion is ending up mostly in language wars, because Alex' talk was about how to improve the situation, not how to prove that your favored technology is always the right tool for the job and everybody else is wrong. Let's say that you're doing some NLP and you want to pre-process your strings in Ruby because its easy and elegant. Idiomatically you might write something like "my_objs.map(&:to_s).map { |s| s.gsub(/\W\S/+, '') }.reject(&:blank?)" - perhaps broken up into multiple lines - but you're allocating three arrays and re-allocating every string. And in real life you're probably doing more pre-processing steps which involve additional arrays and possibly additional string re-allocations. You could switch to gsub! which does the non-word stripping in place, but it "Performs the substitutions of String#gsub in place, returning str, or nil if no substitutions were performed", so you're adding an extra conditional. And it's going to be harder to avoid re-constructing a bunch of arrays. There's no intrinsic reason you couldn't have basic Ruby language APIs which let you write code which chains operations just as naturally and obviously, but don't wastefully re-allocate. Think of how ActiveRecord relations defer the actual SQL execution until it's unavoidable. (Haskell-style laziness might solve the main issue above, but I've run into analogous unavoidable-allocation problems with Haskell. If I'm depth-first searching a board game state-tree I shouldn't have to re-allocate the whole state representation at each step, but it's pretty hard to avoid while writing elegant Haskell since modifying memory in-place has side-effects.) I don't know Go, but maybe instead of talking about why people who still use Python or Ruby are or are not stupid, we can talk about what it gets right that other languages can adapt?
bm1362 14y ago
I'm currently hitting some performance issues trying to use Python to make a naive physics engine- does anyone have any reading recommendations on best practices for python performance?
- travisoliphant 14y ago
  I'd love to see how Numba helps you. Give it a try: http://numba.pydata.org http://numba.pydata.org Slide deck: https://speakerdeck.com/pyconslides/numba-a-dynamic-python-compiler-for-science-by-travis-e-oliphant-jon-riehl-mark-florisson-and-siu-kwan-lam https://speakerdeck.com/pyconslides/numba-a-dynamic-python-c... IPython notebook examples: https://www.wakari.io/nb/travis/numba https://www.wakari.io/nb/travis/numba https://www.wakari.io/nb/travis/Using_Numba https://www.wakari.io/nb/travis/Using_Numba
plg 14y ago
the endless debate continues... choose two: a. fast execution of the code on the machine b. fast code generation by the programmer c. fine-grained control over every aspect of the code I know which two I'd rather have, esp in the long run.
- travisoliphant 14y ago
  Numba is trying to let you make a different choice for different sections of the same program so that you can do different styles of programming in code meant to be a library than you might do in other sections of code meant to be more "ocassional programmer" facing. Some of you might find the roadmap particularly interesting. It's an open-source project eager for input from others... http://numba.pydata.org/numba-doc/dev/roadmap.html http://numba.pydata.org/numba-doc/dev/roadmap.html
Xcelerate 14y ago
This thread has got me cracking up. I'm sure all of you are very smart, yet you all treat each other as though the other person is a stupid, incompetent programmer. It's a trend I observe everywhere in online programming communities.
- teeja 14y ago
  But all the others are stupid, incompetent programmers. It started at MIT. Just kidding! (sort of). But have a look at the Jargon Appendix (http://catb.org/jargon/html/pt03.html http://catb.org/jargon/html/pt03.html) - especially The Story of Mel (http://catb.org/jargon/html/story-of-mel.html http://catb.org/jargon/html/story-of-mel.html).
g2e 14y ago
The video has been posted for anyone interested: http://vimeo.com/61044810 http://vimeo.com/61044810
ilaksh 14y ago
I am sure I am just going to have this comment buried because people don't like to have Python and Ruby compared unfavorably, but I have to try to help people out. Looks like a lot of people STILL haven't caught on to how big of a performance advantage Node.js's V8 engine gives you over Python and Ruby. Look at benchmarks like this one: http://fengmk2.github.io/blog/2011/fibonacci/nodejs-python-php-ruby-lua.html http://fengmk2.github.io/blog/2011/fibonacci/nodejs-python-p... Most of the time modern JavaScript is compiled to native code. Its much faster than you realize. The cleanest code is a new language called CoffeeScript which compiles to JavaScript. Its more Pythonic than Python. Its the closest to pseudocode that you can get (especially if you avoid a few Rubyisms). The best APIs available are in Node.js modules (see npmjs.org). Best meaning most advanced API design in that the modules are focused, decoupled, very straightforward. This is also by far the best design for package management and dependencies since it is very open and flexible. On top of that, Node.js is built from the ground up to support highly concurrent input/output. It just amazes me that people haven't figured out what a big advantage Node.js and CoffeeScript provide over Python or Ruby. I actually think that a big thing holding people back is that Node.js and CoffeeScript make things so much easier, people think its cheating, and are afraid their programmer friends will think less of them if they take advantage of something that really simplifies their jobs.
- TazeTSchnitzel 14y ago
  CoffeeScript is horribly... stabby? Its ambiguous syntax makes it easy to hurt yourself. And node.js, while great, is not magic. I would also much rather use Python's classes than do JS OOP or use CS classes. That said, I use node.js more often than Python.
  - ilaksh 14y ago
    How much time have you spent using CoffeeScript? It might take a week or two to get used to it. I think if you just stick with some basic stuff and write it like Python with less punctuation then it is pretty straightforward and CS classes are very straightforward, what's wrong with them? Just leave out the outer parenthesis and put them in after that.

283 points by ANTSANTS 14y ago

YesThatTom2 14y ago

Wouldn't adding goland-style slices to Python be awesome?

kkuduk 14y ago
well, there are memoryviews, but they could have been designed better
- travisoliphant 14y ago
  Memoryviews are the step-child of NumPy arrays. The buffer-protocol was the real intent and the memory view the forgotten "example" until a few brave and noble Python devs rescued it from obscurity. Memory-views are not that useful to one who will always have NumPy installed.
almost 14y ago
It's not quite the same but some of the use cases (and a bunch of other stuff) would be covered by numpy arrays. You can create multiple views on the same in memory data with different start and end points and different strides.
- dagw 14y ago
  Agreed. I think numpy arrays a rather overlooked by most python programmers. They allow all kinds of useful tricks like that that are quite handy even if you're not doing strictly numeric work.

RegRegReg 14y ago

The biggest confusion is seeing Python/Ruby/JS as a programming languages. They are not. They are scripting languages. Something you put on top of your core code.

pekk 14y ago
Does the phrase "scripting language" have any hard technical meaning or is it just another subjective label?
- voidlogic 14y ago
  I've always informally thought of a scripting language as anything the executes by interpreting source code or bytecode (lacking JIT compilation).
doktrin 14y ago
This might make sense if you contrasted "scripting" to something a little more specific, like "system" development. However, creating a "programming" v. "scripting" dichotomy makes no sense IMHO. Ruby & Python are programming languages that can also be considered, informally, scripting languages.

martinced 14y ago

The reason JavaScript is dog slow is single-threading. That's quite a huge handicap on today's hardware and it's only gonna get worse and worse until JavaScript engines becomes multi-threaded. Besides that, I don't disagree with TFA when it says: "Garbage collection means cleaner APIs which can intelligently allocate their own buffers and can therefore relieve the user of what can be a tiresome or error-prone burden." But that's certainly not an explanation as to why GC languages are not slow. (and I'm not saying GC languages are slow: all I'm saying is that saying that GC leads to cleaner code has nothing to do with performances of the runtime)

cjh_ 14y ago

Very interesting read. I have only written a small amount of Go, I have been through tour.golang.org, just waiting for the right project for me to use it on. Currently whenever a new project comes along I reach for C or Perl, hoping to find a niche between them for Go.

berntb 14y ago
The feature with scripting languages compared with system languages (C, Java, etc) is that they are fast -- not to run code, but to develop functionality. The article argued that idiomatic Go gave at least as good runtime speedup as a normal scripting language (Perl, Ruby, etc) with the (small) time critical parts rewritten in C. But it didn't touch the important question -- is the development time for Go faster than for scripting languages with critical sections in C? Go looks fun, but I'd personally want information on that metric before trying it on a project. [Edit: Yeah, as the article noted, Go excels re parallelization etc. I might Go for it in those use cases.] (What I'd really want is to find a place which use Lisp, since development speed is roughly as fast as for scripting languages and there has been good compilers for decades.) Edit: Spelling, must start going over the room for the keyboard when using the iPad.
- voidlogic 14y ago
  "But he didn't touch the important question -- is the development time for Go faster than for scripting languages + C?" That is a good question, but- Isn't that going to vary a lot by the person/team involved? Calculating "effort" is far more difficult than run-time or complexity characteristics. Doesn't that question also assume that people writing in the scripting language can write (correct/decent/secure) C. Ironically, I have a strong feeling that many more Go developers can write C than say Ruby or PHP devs.
  - berntb 14y ago
    >>Calculating "effort" is far more difficult than run-time or complexity characteristics. If it really was impossible to measure development/support speed, then we'd still use hex code with switches on a console. :-) And yeah, kids today often don't learn C at school, it is a pity.

voidlogic 14y ago

Since the author uses Go as a basis of comparison. I thought these benchmarks from The Computer Language Benchmarks Game might be interesting: Go vs. Ruby: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=yarv http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te... Go vs. Python: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=python3 http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te... Note: These results are from the 64-bit single core machine since it has already been updated to Go 1.1 beta 1. There is also a faster Go regex program (#7) that hopefully can be made to work again after 1.1 is released (in place of #1). Although still using Go 1.0.X ,the recent TechEmpower benchmarks might be interesting if you have not seen them: http://www.techempower.com/blog/2013/03/28/framework-benchmarks/ http://www.techempower.com/blog/2013/03/28/framework-benchma... (It looks like Go 1.1 might be 3x faster: https://gist.github.com/errnoh/5320784 https://gist.github.com/errnoh/5320784) P.S. As always your own program is always the best benchmark to use, your millage may very, take your gain of salt, etc etc.

yew 14y ago
Probably worth noting that the presentation that the author is discussing is less about 'which language is faster' and more about what sort of abstractions different types of languages encourage. The presenter explicitly takes the position that Go and Python (actually PyPy) should be equally fast given the same sort of operations. Just that Python's idioms tend to be less efficient. He's a PyPy developer too, so I would think he would know something about what's going on under the hood. (He also talks a bit about why the VM doesn't/shouldn't try to optimize these cases automatically. Worth a look, it isn't long.)
- ealloc 14y ago
  Good summary. But I disagree with the author that immutable strings and ubiquitous hashes are merely unfortunate idioms of python - to me python is about simplicity, and those things are what make python conceptually simple. I don't have to worry about clobbered buffers, nor about datastructure semantics besides simple hashes.

joe_the_user 14y ago

"Programmers of elegant scripting languages desire similarly elegant looking code with flexible data structures even where no flexibility is in play. Some who know better will understand that technical limitations make the difference between hashes and other types of named lookups essentially nil for many popular language runtimes." OK, if no flexibility is in play in many usages of hashmaps, should not an intelligent interpreter/compiler be able to detect this and modify the use of the hashmap accordingly? Maybe even use a different lookup system in those cases? It seems like that would be ... elegant. The reason VMs don't need to be slow is that you don't need to treat an eval call literally, you don't always need to create a full environment to parse a twenty character string, right? But if you can get around that, should you not be able to get around hash-map's problems? Am I missing something.

cjh_ 14y ago
This question is partially address in the articles linked to at the start [1] I linked to the slide that begins to mention it, rather short though. The answer is that we can add heuristics, but that we should also be able to solve this somewhat on a language/library level rather than only at a vm level. [1] https://speakerdeck.com/alex/why-python-ruby-and-javascript-are-slow?slide=34 https://speakerdeck.com/alex/why-python-ruby-and-javascript-...
- joe_the_user 14y ago
  Yeah, Perhaps if I saw/heard the talk I would get more out of it than "data-structure heuristics are the worst". It would be nice to know why they are the worst.
- makomk 14y ago
  Python already has a feature called __slots__ which replaces the dictionary normally used to store object attributes with fixed, well, slots.
jes5199 14y ago
Doesn't the V8 javascript engine do something like this? Where it builds C-structs instead of hashmaps if it can detect that your objects are being built in a consistent way

d0m 14y ago

Time of "Getting that shit done" and cost of long-term maintenance are two of the main reasons why people use Ruby/Python, not for the raw performance. I thought that was an old debate. And anyway, from my experience, Python has never been the cause of the slowness.. It's more about tweaking that DB query, smartly packaging the assets or using a better algorithm. (I know it's not always the case. I.e. If my program has to run in the space where bits could be randomly shifted, some additional thoughts would be needed, obviously.)

jacobmarble 14y ago
True, the author doesn't really address "effort to get shit done", but Others have commented on this and there seems to be consensus around "Go is a very human readable/writable language". Anyone know of a human read/write-ability comparison of programming languages?
- zachrose 14y ago
  Depends on the human! (One end of the spectrum is a DSL customized to the concepts and patterns of domain experts.)
- antiterra 14y ago
  Isn't that a useless comparison? Chinese, Tamil and Estonian are all extremely human read/writeable, so much that children can write them. However, it's likely at least one of them is indecipherable to you. Perhaps the metric you're more interested in is the difficulty in learning to read/write decent code in a particular language. Of course, this difficulty can vary based on what other languages the learner is already familiar with.
  - jesstaa 14y ago
    Chinese is often even indecipherable to the Chinese and because of this there have been many attempts to simplify it. There is a subset that people actually use and the rest is avoided. This is a similar case with languages like C++, Ruby and Python. The languages are terrifyingly complex, but the subset that most people use is reasonably usable. If you stray outside this subset there be dragons.

alexchamberlain 14y ago

On the to garbage collect or not issue briefly mentioned at the end, the best reason to use an unmanaged language is predictability of performance. You know the GC won't step in at a critical moment. I regularly get frustrated by Eclipse becoming unresponsive for several seconds.

pjmlp 14y ago
There are real time GCs for many languages that compile to native code. The way Eclipse is coded is not a good example of GC performance.

losethos 14y ago

I have a JIT C compiler. I thought you were picking a fight. I'm glad you are not.

pjmlp 14y ago

Overall nice article, it just looses a bit by focusing too much on Go vs Python issue. 1 - The are quite quite a few strong type languages with native code implementations since the mid-80's, even GC enabled, Go is not the only one. 2 - There are dynamic languages like Self, Dylan, Lisp even the young Julia that have implementations which achieve C like speeds when compiled to native code, especially when the developers make use of type annotations and use the right data structures. Self is specially important given that the research work, in a dynamic language, ended up being the heart of Sun's JIT compiler.

batgaijin 14y ago
Yeah I don't sympathize with ruby/python/go people. CL can be interpreted & compiled. Why the fuck is it okay to literally choose the worst options just because people don't like seeing an explicit AST?
- pekk 14y ago
  Why specifically are these "literally the worst" options?
- mratzloff 14y ago
  Because you can hire for those languages, but good luck hiring for CL.
mwcampbell 14y ago
Yes, there have been many other languages with ahead-of-time compilation and garbage-collected runtimes, but Go is one of the few that might be considered popular today. At this point, one might invoke the old chestnut, "If you make technology choices based on popularity, you might as well go with (Windows|PHP)." But there are degrees of popularity, and there are advantages in choosing something that's at least moderately popular, e.g. a large selection of ready-to-use libraries and a pool of developers who don't need to learn a new language on the job.

Moto7451 14y ago

I've noticed this in some code I've been refactoring at work recently (a feed generation system). It's easy in Perl to suck in a large amount of data into one array and map/grep it into another array of hashes and output filtered/formatted data in a few lines. The problem of course is that your business'/project's own growth overwhelms the algorithm as the data structure balloons. This is further compounded by libraries which are designed to accept an array as input (reinforcing the idiom causing the first problem) since you end up with thousands of additional iterations. I refactored the code to lazy load each item in the collection and map/filter/generate the XML at the end of each node's iteration. The end result is a nice flat memory space (save for the odd leak here and there) that's about 1/10th of the original program's, at the 'expense' of only a few more lines of code.

corresation 14y ago

Both the submission and the target of the submission dismiss dynamic typing as a source of slowdowns (in the unfortunately haughty, completely unsupported manner that is too common in the industry. It is, in effect, the head-in-the-sand approach: If you don't want something to be true, simply keep saying it isn't and somehow that will become reality), yet I guess we need to define what "slow" is then, using as an example an empirical test (ASM.JS) that certainly serves better than some people waving their hands about innovations in JIT compilers. The primary optimization that ASM.JS brings is its static type system. With that, and the obvious benefits to the code path, intensive activities can be run at 1/2 native speed, versus the 1/12th of so native speed available with dynamic typing. Is 1/12th native speed "slow"? In most cases -- where the code is the duct-tape that glues together native code (which is the case on web servers, admin scripts, etc), no, it isn't slow at all. But from a basic optimization perspective, asm.js sure seems to indict dynamic typing if you really care about squeezing every cycle's maximal output.

gsnedders 14y ago
No, the primary optimization asm.js brings (at least in OdinMonkey) is AOT compilation. Fully typed code should produce the same code from IonMonkey without OdinMonkey: the problem is you have to get up to 10k calls (at least last I looked!) of a function before you get there; but once you are there it is just as good. It's the build-up, through the interpreter and the less efficient code-generators (in terms of code generated, that is; they're more efficient in terms of their own runtime), which really hurts.
- corresation 14y ago
  No, the primary optimization asm.js brings (at least in OdinMonkey) is AOT compilation. But it can do that precisely because of the static typing, which loops back to exactly what I said. Looser, more dynamic language always have a cost associated with that flexibility.
  - gsnedders 14y ago
    Arbitrary JS can be as statically typed as asm.js is (because, well, asm.js is just a subset). There's no reason why one couldn't compile AOT something like: function add_and_double(a, b) { a = a | 0; b = b | 0; var sum = (a + b) | 0; return (sum + sum) | 0; } Yes, it'd be trivial to fall off the AOT-compilation path (esp. without a defined subset that got AOT compilation and hence likely would differ between implementations), so static verification that you're on the AOT-compilation path is valuable (which asm.js provides), but it doesn't fundamentally alter the semantics of the language.

NateDad 14y ago

Everyone keeps saying "Use Python and write the slow parts in C"..... except that writing GOOD (secure, correct, safe) C is really hard. That's actually the main reason why the Go authors came up with Go. Not to replace Python etc, but to replace C/C++. I'm kind of surprised that all the "Python: let's get stuff done" people are suggesting writing a whole bunch of code in C, one of the least "Getting stuff done" languages there is. For those who have asked what the productivity of Go is like vs. Python + C: Go is very productive. When newbies to Go say it's "verbose" they mean "I have to write out some 3 line loops that in other languages are one line". If that's the major cause of slowness in my development cycle, I'd be ecstatic. Go is also very easy to write "correct" code in... no buffer overflows, no memory leaks, no access of random memory, no unnecessary allocations, and a very clear and defined behavior from clear, concise code.

pekk 14y ago
Nobody said you have to write any C. If you are freaking out about performance, the option to write some parts in C is valuable.
gsnedders 14y ago
Given the original presenter is one of the major contributors to PyPy, I'm fairly certain that wouldn't be his first advice: I'd expect it'd be to try PyPy (and file a bug if it's slower than CPython!). Also note on the last slide: "Stop writing C extensions, use something like cffi". There's two (really) good reasons you should do this: firstly, your code is no longer tied tied to CPython, so using alternative Python implementations (like PyPy) becomes viable; secondly, you don't have to use C — you can trivially use anything that exports functions using the C ABI.
officemonkey 14y ago
>"I have to write out some 3 line loops that in other languages are one line" I think every vim, emacs and decent IDE user would say "I has a text editor. Your argument is invalid."
- stouset 14y ago

kalkin 14y ago

It's too bad that this discussion is ending up mostly in language wars, because Alex' talk was about how to improve the situation, not how to prove that your favored technology is always the right tool for the job and everybody else is wrong. Let's say that you're doing some NLP and you want to pre-process your strings in Ruby because its easy and elegant. Idiomatically you might write something like "my_objs.map(&:to_s).map { |s| s.gsub(/\W\S/+, '') }.reject(&:blank?)" - perhaps broken up into multiple lines - but you're allocating three arrays and re-allocating every string. And in real life you're probably doing more pre-processing steps which involve additional arrays and possibly additional string re-allocations. You could switch to gsub! which does the non-word stripping in place, but it "Performs the substitutions of String#gsub in place, returning str, or nil if no substitutions were performed", so you're adding an extra conditional. And it's going to be harder to avoid re-constructing a bunch of arrays. There's no intrinsic reason you couldn't have basic Ruby language APIs which let you write code which chains operations just as naturally and obviously, but don't wastefully re-allocate. Think of how ActiveRecord relations defer the actual SQL execution until it's unavoidable. (Haskell-style laziness might solve the main issue above, but I've run into analogous unavoidable-allocation problems with Haskell. If I'm depth-first searching a board game state-tree I shouldn't have to re-allocate the whole state representation at each step, but it's pretty hard to avoid while writing elegant Haskell since modifying memory in-place has side-effects.) I don't know Go, but maybe instead of talking about why people who still use Python or Ruby are or are not stupid, we can talk about what it gets right that other languages can adapt?

bm1362 14y ago

I'm currently hitting some performance issues trying to use Python to make a naive physics engine- does anyone have any reading recommendations on best practices for python performance?

travisoliphant 14y ago
I'd love to see how Numba helps you. Give it a try: http://numba.pydata.org http://numba.pydata.org Slide deck: https://speakerdeck.com/pyconslides/numba-a-dynamic-python-compiler-for-science-by-travis-e-oliphant-jon-riehl-mark-florisson-and-siu-kwan-lam https://speakerdeck.com/pyconslides/numba-a-dynamic-python-c... IPython notebook examples: https://www.wakari.io/nb/travis/numba https://www.wakari.io/nb/travis/numba https://www.wakari.io/nb/travis/Using_Numba https://www.wakari.io/nb/travis/Using_Numba

plg 14y ago

the endless debate continues... choose two: a. fast execution of the code on the machine b. fast code generation by the programmer c. fine-grained control over every aspect of the code I know which two I'd rather have, esp in the long run.

travisoliphant 14y ago
Numba is trying to let you make a different choice for different sections of the same program so that you can do different styles of programming in code meant to be a library than you might do in other sections of code meant to be more "ocassional programmer" facing. Some of you might find the roadmap particularly interesting. It's an open-source project eager for input from others... http://numba.pydata.org/numba-doc/dev/roadmap.html http://numba.pydata.org/numba-doc/dev/roadmap.html

Xcelerate 14y ago

This thread has got me cracking up. I'm sure all of you are very smart, yet you all treat each other as though the other person is a stupid, incompetent programmer. It's a trend I observe everywhere in online programming communities.

teeja 14y ago
But all the others are stupid, incompetent programmers. It started at MIT. Just kidding! (sort of). But have a look at the Jargon Appendix (http://catb.org/jargon/html/pt03.html http://catb.org/jargon/html/pt03.html) - especially The Story of Mel (http://catb.org/jargon/html/story-of-mel.html http://catb.org/jargon/html/story-of-mel.html).

g2e 14y ago

The video has been posted for anyone interested: http://vimeo.com/61044810 http://vimeo.com/61044810

ilaksh 14y ago

I am sure I am just going to have this comment buried because people don't like to have Python and Ruby compared unfavorably, but I have to try to help people out. Looks like a lot of people STILL haven't caught on to how big of a performance advantage Node.js's V8 engine gives you over Python and Ruby. Look at benchmarks like this one: http://fengmk2.github.io/blog/2011/fibonacci/nodejs-python-php-ruby-lua.html http://fengmk2.github.io/blog/2011/fibonacci/nodejs-python-p... Most of the time modern JavaScript is compiled to native code. Its much faster than you realize. The cleanest code is a new language called CoffeeScript which compiles to JavaScript. Its more Pythonic than Python. Its the closest to pseudocode that you can get (especially if you avoid a few Rubyisms). The best APIs available are in Node.js modules (see npmjs.org). Best meaning most advanced API design in that the modules are focused, decoupled, very straightforward. This is also by far the best design for package management and dependencies since it is very open and flexible. On top of that, Node.js is built from the ground up to support highly concurrent input/output. It just amazes me that people haven't figured out what a big advantage Node.js and CoffeeScript provide over Python or Ruby. I actually think that a big thing holding people back is that Node.js and CoffeeScript make things so much easier, people think its cheating, and are afraid their programmer friends will think less of them if they take advantage of something that really simplifies their jobs.

TazeTSchnitzel 14y ago
CoffeeScript is horribly... stabby? Its ambiguous syntax makes it easy to hurt yourself. And node.js, while great, is not magic. I would also much rather use Python's classes than do JS OOP or use CS classes. That said, I use node.js more often than Python.
- ilaksh 14y ago
  How much time have you spent using CoffeeScript? It might take a week or two to get used to it. I think if you just stick with some basic stuff and write it like Python with less punctuation then it is pretty straightforward and CS classes are very straightforward, what's wrong with them? Just leave out the outer parenthesis and put them in after that.