Do you really give a thought when you say "Ruby is slow or Python is slow"? Just because Twitter moved their back end messaging to JVM doesn't necessarily make Ruby any slower than it already was. If a language runtime can't handle concurrent load or long running processes it is not a limitation of the language!
This is dejavu for me as Java was considered "a slow language" back in 1.1 days when HotSpot JVM was in its poorer life and ISO/IEC C++ was hot girl in town. Now that you realized your pony implementations can't catch up with real life performance expectation you start blaming languages, are you serious?
Whether it's global interpreter lock or lack of native threads it's the runtime (re-read the runtime) and not the language that is slow. For the love of technology, Stop blaming languages for poor performance of your suboptimal reinventions!
Every language implementor should at least consider the host platform support before coming up with their "Not Invented Here" approach, sadly that's what is happening with most modern languages.
7 comments:
I disagree. There are slow languages *by design*. Look at some performance essays of Guido for example, and you'll notice the language features he has to work around just to try to fix the performance. Like storing in a local var the name of a global function before calling it multiple times (ugly as hell), because these *need* to be resolved every single time since they can indeed change any time, and this is a language feature.
Dimitris,
This is still a runtime issue which is not optimized yet. For example, when C++ introduced polymorphic invocation it was very slow because of VTable design. Over the years the runtime became smart enough to build and invalidate monomorphic and polymorphic caches on call sites (similar to JIT resolve you are referring to) to improve polymorphism. I would similarly argue that Java is slow because 'synchronized' keyword in Java is very slow not only because of the locking overhead but also a mandatory cache flush, the fact that it is a limitation of Stack based VMs doesn't necessarily make Java language any slower. It is still the runtime which is slow. YMMV with different runtimes for same languages, this was precisely the case for JRockit VM v/s Sun's slow HotSpot VM before few years.
I hate to see people blaming languages and going away from it just because an implementation is bad.
Your point is based on the assumption that somehow this particular language feature may get optimized, as different language features were optimized. I don't think though there is any evidence that *any* language feature can be optimized down to irrelevancy.
In my example, python's semantics allow a function name binding to change from anywhere, anytime. I'm not well versed in that language, but I'm pretty sure that the change can occur via a _different_ name, so a change via name X can have an arbitrary side-effect to name Y, and so on. So I don't see what sort of optimization could find out that "not another lookup of Y is needed because its value can't have changed", that would not break the language itself.
I'm pretty sure there are other examples of language features in various languages that can't possibly be optimized to about the same speed as coding the same functionality in a more performance-conscious language.
I would really, really, really surprized if Python or Ruby runtimes grew to have the same performance in ten years as the java runtime has *today* (on the same hardware of course!). If that happens, please send me an email and I can eat my words. :)
the classic victim was SNOBOL. That Andrew Koenig eventually implemented SPITBOL could not saave it - and the objections to GOTO (which we now just call exception handling)
SNOBOL4 became ICON - from which python takes generatord. ICON continues to evolve.
We saw Smalltalk rejected time and again for usng a VM and compiling to bytecode. Then JAVA became a buzzword...
You may ant to look a rebol3 at www.rebol.net when considering if some features of python doom a language to beng slow ...
Okay, I know this is likely to have a negative response, but I still cannot necessarily agree with the runtime being the culprit of slow.
Let's compare Ruby to Java, purely for argument sake. In Ruby, absolutely everything is an object, even null values (nil). This means any runtime conceivable for this language would inherently have the overhead that objects require.
Java tries to compensate by having at least some native types. Which will always be faster do you think? Raw integer arithmetic, or Fixnum object arithmetic? That's fairly a no-brainer.
I think the point here is that if a language specification has inherent overhead, then one can still consider the language itself to be slow - blaming a runtime would suggest that such an inherent problem could be overcome somehow by some other implementation. Clearly, this is not always going to be the case.
Post a Comment