Ruby is faster than Python, PHP, and Perl(unlimitednovelty.com)
unlimitednovelty.com
Ruby is faster than Python, PHP, and Perl
http://www.unlimitednovelty.com/2012/06/ruby-is-faster-than-python-php-and-perl.html
6 comments
Did anyone else find it strange that Ruby only beat Python and PHP in the median range? On both ends Python and PHP are both quite faster. I don't really know how to read this thing, but I feel like this title is probably misleading?
This post is a rhetorical rant, so it's best not to take the core premise too seriously. Even though the title is "Ruby is faster than Python, PHP, and Perl", I don't think it's the author's intention to make that broad claim. Rather, the intention is to beat out of everyone's head that Ruby is "slow".
When speaking about languages in the same ballpark (Ruby, Python, Perl, etc), it's difficult to make blanket statements about which one is "faster", because they each have their warts. Depending upon what your application needs to do, you may run in to those warts.
When speaking about languages in the same ballpark (Ruby, Python, Perl, etc), it's difficult to make blanket statements about which one is "faster", because they each have their warts. Depending upon what your application needs to do, you may run in to those warts.
Yes, I'd be far more interested if the author spent any time analyzing the data rather than dancing gleefully for a dozen paragraphs.
The author seems very excited to rub this in anyone's face he can. The data seems much more murky than he makes it out to be.
Not another one of these...
Doesn't matter... Dynamic languages are slow by design!
Caching and JIT compilers to the rescue!
Caching and JIT compilers to the rescue!
Does this really matter?
I mean,seriously, if speed is what you want, you'd write it in C. These days, with virtually unlimited CPU, we choose our languages based on suitability for the task, readability and community support (at least I do).
Other than assembler for games, I have never chosen a language based on speed of execution. Anyone else?
Can't we also just compile Ruby (or PHP or Python) to C and then let the C compiler optimize it these days? I think we can.
Additionally, the fact that Javascript kicks the crap out of the vast majority of languages is surprising to me.
I mean,seriously, if speed is what you want, you'd write it in C. These days, with virtually unlimited CPU, we choose our languages based on suitability for the task, readability and community support (at least I do).
Other than assembler for games, I have never chosen a language based on speed of execution. Anyone else?
Can't we also just compile Ruby (or PHP or Python) to C and then let the C compiler optimize it these days? I think we can.
Additionally, the fact that Javascript kicks the crap out of the vast majority of languages is surprising to me.
Other than assembler for games, I have never chosen a language based on speed of execution. Anyone else?
I once moved a major processing step from the database to C++. Execution time went from an estimated 1 week to a measured 5 minutes.
Why was the difference that big?
The fastest path to get a piece of data in the database is to do a binary search on an index that tells you what row in the table has your data, and what page of memory it is in. You then go to that page in memory, locate the row, parse it, and pull out the information of interest. All of this is controlled by instructions in some sort of microcode.
The equivalent data path is C++ was, "follow a pointer". Furthermore the C++ representation of the data was so much more compact that I was frequently managing to stay inside of CPU caches, versus the database approach where I was fighting to stay within RAM limitations.
Sometimes performance really, really does matter. (This is a rare circumstance.)
As for JavaScript, the reason that it beats everything else is that there is serious corporate muscle (eg Google and Apple) behind optimizing it as much as possible.
I once moved a major processing step from the database to C++. Execution time went from an estimated 1 week to a measured 5 minutes.
Why was the difference that big?
The fastest path to get a piece of data in the database is to do a binary search on an index that tells you what row in the table has your data, and what page of memory it is in. You then go to that page in memory, locate the row, parse it, and pull out the information of interest. All of this is controlled by instructions in some sort of microcode.
The equivalent data path is C++ was, "follow a pointer". Furthermore the C++ representation of the data was so much more compact that I was frequently managing to stay inside of CPU caches, versus the database approach where I was fighting to stay within RAM limitations.
Sometimes performance really, really does matter. (This is a rare circumstance.)
As for JavaScript, the reason that it beats everything else is that there is serious corporate muscle (eg Google and Apple) behind optimizing it as much as possible.
You can compile PHP to C++ using HipHop (https://github.com/facebook/hiphop-php)
In my opinion each language is a tool and all have their place. Knowing what each can and cannot do is more important than which is faster. It also comes down to preference as well. If you are use to using PHP, then continue to use it. Would you use PHP for system admin tasks? No, you would use python or ruby.
Can't we all just get along and agree to stop bashing languages when comparing them to each other?
In my opinion each language is a tool and all have their place. Knowing what each can and cannot do is more important than which is faster. It also comes down to preference as well. If you are use to using PHP, then continue to use it. Would you use PHP for system admin tasks? No, you would use python or ruby.
Can't we all just get along and agree to stop bashing languages when comparing them to each other?
> Does this really matter?
Sometimes. If your app is network/memory/disk bound, no. If it is CPU bound, yes. That's why web apps are in Python/Ruby, and games are in C++/C#.
Also, Ruby/Python/interpreted language performances are within a magnitude of each other so they're effectively equivalent.
Sometimes. If your app is network/memory/disk bound, no. If it is CPU bound, yes. That's why web apps are in Python/Ruby, and games are in C++/C#.
Also, Ruby/Python/interpreted language performances are within a magnitude of each other so they're effectively equivalent.
Does it matter, nope.
I think this is just leftover annoyances from pre 1.9 mri perfomance is all.
As to compiling ruby to c, maybe, as long as its not eval()'ing ruby code. But rubinius+llvm+its jit would be the closest to what you're talking about. That or jruby too.
I think this is just leftover annoyances from pre 1.9 mri perfomance is all.
As to compiling ruby to c, maybe, as long as its not eval()'ing ruby code. But rubinius+llvm+its jit would be the closest to what you're talking about. That or jruby too.
Most JavaScript implementations are faster just due to the amount of R&D dollars poured into them due to browser competition. Ruby, Python, and PHP could (and should) have runtimes competitive with, say, V8, it's just that nobody has built them yet.
I imagine Javascript's advantage is because V8 is a JIT compiler. It's unfortunate LuaJIT is not shown since it would probably be around the same level or higher than V8.
I'd also be interested to see Pypy's experimental JIT compared here (or pypy at all, for that matter).
I love ruby and I would like to support any effort to dispel the myth that Ruby is slow.