# This is why Ruby 1.8.6 can never be made to run anywhere near as fast as Python 2.5.1 **URL:** \ **Category:** ruby-talk\ **Created:** [24 September 2007 02:55 UTC](https://rubytalk.org/t/this-is-why-ruby-1-8-6-can-never-be-made-to-run-anywhere-near-as-fast-as-python-2-5-1/40861 "2007-09-24T02:55:05Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Ruby\_Maniac](https://avatars.discourse-cdn.com/v4/letter/r/b487fb/32.png) [@Ruby\_Maniac](https://rubytalk.org/u/Ruby_Maniac)\ **Post date:** [24 September 2007 02:55 UTC](https://rubytalk.org/t/this-is-why-ruby-1-8-6-can-never-be-made-to-run-anywhere-near-as-fast-as-python-2-5-1/40861/1 "2007-09-24T02:55:05Z")
I welcome any corrections anyone might be able to make since I am new to Ruby with less than 3 months experience under my belt. Ruby 1.8.6 is an interpreted langauge that does not have a byte-code driven VM at this time. Python 2.5.1 is an interpreted language that does have a byte-code driven VM. I have been able to make Ruby code run 5% faster or more simply by removing nothing but comments - the more comments I remove the faster the code runs up to no more than 6% or 7%. Ruby syntax seems to favor the notion that fewer characters is better than more characters. Lexically interpreted langauges would want this to be the case since it takes more effort to lex more characters. Python runtimes are not affected by the number of characters one uses such as extra whitespace or comments - removing comments does not make Python code run faster simply because the comments have been removed. Python has a very powerful JIT (Just In Time compiler) known as Psyco with which certain Python expressions such as LC (List Comprehensions) and others can be made to run 20x to 100x faster at runtime. Recently as a test I wrote a rather simple Python program that processed all characters of a 20 MB file by setting the MSB to 1. The original Python code I began with executed in 65 seconds before I began to optimize the code. After the code was fully optimized it ran in just under 3 secs. After Psyco was used the runtime for the same problem was less than 1 second. The Ruby code I wrote before any optimizations were applied ran in about 65 seconds or no faster than Python with no optimizations. The most optimized Ruby code I could find for this problem was able to execute in just under 22 seconds using techniques that were not necessary when optimizing the Python code. Given the best Ruby is capable of doing versus the best Python is capable of doing Ruby ends up being more than 20x slower than Python and I think I know why. It is just not possible to make Ruby 1.8.6 execute any faster than the Ruby interpreter is capable of executing the code due to the lack of a byte-code driven VM. Maybe someday YARV will make Ruby code run 2x faster than Ruby 1.8.6 but that day has not arrived yet and may never arrived. Even if YARV proves to be 2x faster than Ruby 1.8.6 the resulting Ruby code will still be 10x slower than the fastest Python code. The only way YARV will get faster than Python is whenever someone codes a JIT compiler for YARV that provides the same performance boost to Ruby that Psyco provides to Python. As far as I can tell nobody is working on any such JIT for YARV and since YARV has been under development for at least the last 14 to 18 months one can only surmise a JIT for YARV would take a significant amount of time to produce and release to the Ruby community. The bottom line is that Python can be made to run as fast as machine code but Ruby cannot. I know some people want to try to use Ruby for every single problem they are faced with but doing so would be less than wise since there are no tools that work for all problems. Some problems lend themselves nicely to Ruby such as Open Source products where giving away the source code is not a business problem. Python is useful for problems that require fast runtimes such as 3D modelling or video game programming. Ruby would not be fast enough for the kinds of problems where people are using Python. I have not been able to find any references to Ruby being used for 3D realtime video game programming but I have been able to find many references to Python being used for 3D realtime video game programming. I don't expect those who read this to applaud my efforts to discuss this in this forum however I feel we need to discuss this so that some may choose to take actions to make Ruby run faster at runtime just as work was done to make Python run faster at runtime. Believe it or not I actually like Ruby 1.8.6 but I would hesitate to try to use Ruby for situations where runtime performance was an issue or whenever I did not want to release the source code. When I write code I want to know I am using tools that give me the best performance for the effort that I can possibly get as opposed to tools that guarantee no matter how hard I work performance will always be lacking. The same comments could be made about Rails. Rails emits SQL statements that have a lot of "\*" characters. Those of us who have been coding SQL long enough know the use of "\*" characters makes SQL statements run slower than when fully qualified column names are used rather than the "\*". I coded a simple benchmark that demonstrated this very clearly; whenever "\*" was used rather than a list of column names the resulting SQL statements ran 10% to 880% slower than when the "\*" was replaced with a list of column names even when the list of column names was quite long. Oddly enough I quite easily found more powerful Database Frameworks for Python that did not emit SQL code that used "\*" characters and I was even able to find some interfaces for those SQL Frameworks that would allow seasonsed Rails developers use Rails statements when describing their database relationships. I know of some Ruby developers who rejected the idea that the use of "\*" in SQL statements would be slower than long lists of column names. From the perspective of a Ruby on Rails developer who has not coded anything but Rails or Ruby it might seem logical that fewer characters is better than more characters and so the use of "\*" in SQL statements must be optimial because this is how Ruby works, right ?!? Wrong ! Even when some RoR developers are faced with benchmarks that demonstrate the use of "\*" in SQL statements can be 10% to 880% slower than not using "\*" characters they still chose to reject the benchmarks and deny the benefits of not using Rails because Rails is not able to automatically replace "\*" with lists of column names, apparently. When people choose to make their choices of languages a religious issue they can become rather short-sighted in how they choose to resolve programming problems. I prefer to be agnostic about programming languages. I choose those that perform the best and I ignore the rest. Ruby is a cute language that may someday become useful but this won't happen unless the Ruby community becomes interested in making Ruby perform better at runtime. In the meantime, I will use Ruby only when I must as for the rest I will most-likely use Python unless the problem suggests another language may be more useful. ---
**Author:** ![M\_Edward\_Ed\_Borasky1](https://avatars.discourse-cdn.com/v4/letter/m/e9c0ed/32.png) [@M\_Edward\_Ed\_Borasky1](https://rubytalk.org/u/M_Edward_Ed_Borasky1)\ **Post date:** [24 September 2007 03:01 UTC](https://rubytalk.org/t/this-is-why-ruby-1-8-6-can-never-be-made-to-run-anywhere-near-as-fast-as-python-2-5-1/40861/2 "2007-09-24T03:01:06Z")
Ruby Maniac wrote: > Even if YARV proves to be 2x faster than Ruby 1.8.6 the resulting Ruby > code will still be 10x slower than the fastest Python code. Care to bet on that? I just benchmarked "YARV" at something like 5X Ruby 1.8.6, with some bursts as high as 72X! ---
**Author:** ![Wilson\_Bilkovich](https://yyz1.discourse-cdn.com/flex029/user_avatar/rubytalk.org/wilson_bilkovich/32/8247_2.png) [@Wilson\_Bilkovich](https://rubytalk.org/u/Wilson_Bilkovich)\ **Post date:** [24 September 2007 03:10 UTC](https://rubytalk.org/t/this-is-why-ruby-1-8-6-can-never-be-made-to-run-anywhere-near-as-fast-as-python-2-5-1/40861/3 "2007-09-24T03:10:01Z")
I'm not going to address any of your Rails comments, because they have nothing to do with Ruby. Rails is just a library. Python is not faster than Ruby due to language design, but because skilled people got together and made it faster. Nothing is stopping people from doing the same for Ruby. Some corrections: 1. YARV is 'out', in the form of Ruby 1.9. A stable release is coming in a matter of months. 2. JIT is nice, but it is not a panacea. C and C++ are plenty fast, and use AOT compilation, not JIT. Java has shown that a combination of AOT and JIT can yield impressive performance, but Psyco is merely one approach out of many. 3. YARV has some (unfinished) competition with significantly varying approaches: \* JRuby: The trunk version offers compilation as well as interpretation. At some point it will almost certainly support fancy JIT tricks, given its architecture. [http://jruby.codehaus.org/](http://jruby.codehaus.org/) \* Rubinius: Currently supports 'only' AOT compilation to bytecode. When it is done, we will be doing much more sophisticated things, a la Pepsi/Coke/J3. [http://rubini.us/](http://rubini.us/) \* IronRuby: I don't know enough about their architecture to say, but they will probably bring some impressive performance to the table as well. Please don't judge Ruby the language by looking at the current 1.8 implementation. They are not the same thing, and the limitations of 1.8 are not necessarily invariant constraints. On the other hand, I'm probably wasting my time with this reply. Calling Ruby a "cute" language means you are almost certainly a troll. Please forgive me if I am wrong about this. > **···** > > On 9/23/07, Ruby Maniac \ wrote: > > > I welcome any corrections anyone might be able to make since I am new > > to Ruby with less than 3 months experience under my belt. ---
**Author:** ![Bill\_Kelly](https://avatars.discourse-cdn.com/v4/letter/b/cc9497/32.png) [@Bill\_Kelly](https://rubytalk.org/u/Bill_Kelly)\ **Post date:** [24 September 2007 03:37 UTC](https://rubytalk.org/t/this-is-why-ruby-1-8-6-can-never-be-made-to-run-anywhere-near-as-fast-as-python-2-5-1/40861/4 "2007-09-24T03:37:22Z")
> I prefer to be agnostic about programming languages. I choose those > that perform the best and I ignore the rest. That's agnosticism? Sounds like a sermon from the Church of Premature Optimization. \ Kidding aside, that's great that you know what you want from a programming language. Many of us know what we want, too. I accept that Ruby is slow to execute (although getting faster). It's more important to me that Ruby is fun and productive to program in, and that Ruby is merely \_fast enough\_ for the task at hand. I've dabbled in a number of languages, but I've written actual production code in assembler, Forth, C, C++, Objective-C, Java, Perl, Python, Ruby, and (kill me now) VB6. If one took your "choose those that perform the best and ignore the rest" razor literally, one would assume you would choose to write only hand-tuned assembly. Have you written much hand-tuned assembler lately? No? Neither have I. Fifteen to twenty years ago, it was still common for many video games to be coded entirely in assembler. Myself, I preferred to write as much as possible in C, and drop down to assembler only when necessary. Today, it's really the same equation. I write as much in Ruby as possible, but drop down to C when needed. Obviously, the faster Ruby gets, the better. But again, many of us have been programming in Ruby for years, not because we don't know half a dozen faster languages, but because we like programming in Ruby, and find it fast enough for most of our needs. And if some method needs to go way faster, there's always C. Regards, Bill > **···** > > From: "Ruby Maniac" \ ---
**Author:** ![Gavin\_Kistner3](https://avatars.discourse-cdn.com/v4/letter/g/dfb087/32.png) [@Gavin\_Kistner3](https://rubytalk.org/u/Gavin_Kistner3)\ **Post date:** [24 September 2007 04:15 UTC](https://rubytalk.org/t/this-is-why-ruby-1-8-6-can-never-be-made-to-run-anywhere-near-as-fast-as-python-2-5-1/40861/5 "2007-09-24T04:15:03Z")
> Ruby is a cute language that may someday become useful but this won't > happen unless the Ruby community becomes interested in making Ruby > perform better at runtime. To be clear, it may someday become useful \*to you\*; it's already useful to me. > In the meantime, I will use Ruby only when > I must as for the rest I will most-likely use Python unless the > problem suggests another language may be more useful. I'd be interested to know under what circumstance(s) you expect to be, or already are, forced to use Ruby. (Developing RoR sites in a team environment?) > **···** > > On Sep 23, 8:50 pm, Ruby Maniac \ wrote: ---
**Author:** ![Michael\_T\_Richter](https://avatars.discourse-cdn.com/v4/letter/m/9d8465/32.png) [@Michael\_T\_Richter](https://rubytalk.org/u/Michael_T_Richter)\ **Post date:** [24 September 2007 05:12 UTC](https://rubytalk.org/t/this-is-why-ruby-1-8-6-can-never-be-made-to-run-anywhere-near-as-fast-as-python-2-5-1/40861/6 "2007-09-24T05:12:32Z")
Can I ask why \*ANYBODY\* took a message by someone calling themselves "Ruby Maniac" and using expressions like "cute language" as anything but a troll? Anybody? Anybody? Bueller? Don't dignify these kinds of things with responses, peeps. > **···** > > -- > Michael T. Richter \<[ttmrichter@gmail.com](mailto:ttmrichter@gmail.com)\> (GoogleTalk: > [ttmrichter@gmail.com](mailto:ttmrichter@gmail.com)) > Never, ever, ever let systems-level engineers do human interaction > design unless they have displayed a proven secondary talent in that > area. Their opinion of what represents good human-computer interaction > tends to be a bit off-track. (Bruce Tognazzini) ---
**Author:** ![Eric\_Hodel1](https://avatars.discourse-cdn.com/v4/letter/e/a9adbd/32.png) [@Eric\_Hodel1](https://rubytalk.org/u/Eric_Hodel1)\ **Post date:** [24 September 2007 05:59 UTC](https://rubytalk.org/t/this-is-why-ruby-1-8-6-can-never-be-made-to-run-anywhere-near-as-fast-as-python-2-5-1/40861/7 "2007-09-24T05:59:30Z")
> I welcome any corrections anyone might be able to make since I am new > to Ruby with less than 3 months experience under my belt. > > Ruby 1.8.6 is an interpreted langauge that does not have a byte-code > driven VM at this time. > > Python 2.5.1 is an interpreted language that does have a byte-code > driven VM. > > I have been able to make Ruby code run 5% faster or more simply by > removing nothing but comments - the more comments I remove the faster > the code runs up to no more than 6% or 7%. Then you aren't benchmarking with enough iterations. Comments are skipped and thrown away. They aren't part of the AST. > [...] Lexically interpreted langauges would want this > to be the case since it takes more effort to lex more characters. And you only lex a file once in Ruby. As a proportion of runtime, turning a source file into an AST is small. > Python runtimes are not affected by the number of characters one uses > such as extra whitespace or comments Nor are Ruby's. > - removing comments does not make Python code run faster simply because the comments have been removed. $ echo '5 + 6 # and a comment, which is not in the AST' | parse\_tree\_show -f s(:call, s(:lit, 5), :+, s(:array, s(:lit, 6))) No, really, they aren't there. I stopped reading your email here. I scanned the rest and you didn't provide any code to back up your assertion that removing comments improves ruby performance. I'd be happy to look at it if you can post it. > **···** > > On Sep 23, 2007, at 19:55 , Ruby Maniac wrote: ---
**Author:** ![W\_James](https://avatars.discourse-cdn.com/v4/letter/w/e274bd/32.png) [@W\_James](https://rubytalk.org/u/W_James)\ **Post date:** [24 September 2007 11:30 UTC](https://rubytalk.org/t/this-is-why-ruby-1-8-6-can-never-be-made-to-run-anywhere-near-as-fast-as-python-2-5-1/40861/8 "2007-09-24T11:30:03Z")
Someday when you are a more experienced programmer, you may realize that doing bitwise operations on each byte of a 2-megabyte file is not an appropriate task for a "scripting language". That calls for a lower-level language. Ruby is excellent for processing text a word, a line, or a paragraph at a time. I do almost all of my programming at home in Ruby. It doesn't matter to me whether the program runs in 0.05 sec. or 0.2 sec. I can't use Ruby quite as much as I would like at work, since I have to control the mainframe terminal emulator with a dialect of Basic that's similar to FreeBasic and QuickBasic. > **···** > > On Sep 23, 9:50 pm, Ruby Maniac \ wrote: > > > Ruby is a cute language that may someday become useful ---
**Author:** ![Chad\_Perrin1](https://avatars.discourse-cdn.com/v4/letter/c/977dab/32.png) [@Chad\_Perrin1](https://rubytalk.org/u/Chad_Perrin1)\ **Post date:** [24 September 2007 14:38 UTC](https://rubytalk.org/t/this-is-why-ruby-1-8-6-can-never-be-made-to-run-anywhere-near-as-fast-as-python-2-5-1/40861/9 "2007-09-24T14:38:37Z")
Some others have addressed many of your points admirably. For the most part, I didn't really see much point in responding to what you had to say. On the other hand, a couple of items just bothered me so much I can't really help myself. > Given the best Ruby is capable of doing versus the best Python is > capable of doing Ruby ends up being more than 20x slower than Python > and I think I know why. > > It is just not possible to make Ruby 1.8.6 execute any faster than the > Ruby interpreter is capable of executing the code due to the lack of a > byte-code driven VM. Maybe someday YARV will make Ruby code run 2x > faster than Ruby 1.8.6 but that day has not arrived yet and may never > arrived. > > Even if YARV proves to be 2x faster than Ruby 1.8.6 the resulting Ruby > code will still be 10x slower than the fastest Python code. I guess you haven't been watching the recent thread that revealed how much of a performance boost you can get moving from 1.8.6 to 1.9 (among other means of reducing execution time). > The bottom line is that Python can be made to run as fast as machine > code but Ruby cannot. Sure it can. A language does not, in and of itself, dictate the form of the implementation. There could conceivably one day be an optimizing binary compiler implementated for Ruby while Python might not progress much beyond where it is now (or vice-versa). You'd suddenly find that Python does \*not\* actually execute as fast as "machine code" (meaning binary executables, as opposed to VM bytecode). The fact that Ruby uses an interpreter right now doesn't mean that things won't change in the future. On the other hand, for many types of development projects, programmer time is a lot more valuable than CPU time. In such circumstances, Ruby is one of the best choices around for development language. > Python is useful for problems that require fast runtimes such as 3D > modelling or video game programming. > > Ruby would not be fast enough for the kinds of problems where people > are using Python. Not so much -- not much more so than Ruby, at any rate. People write "serious" games in C++ for the most part, these days. Python doesn't even begin to compare in that realm. In cases where speed matters enough that Ruby isn't even an option, people are generally avoiding Python, too. Only in cases where people like to \*think\* speed matters, but it doesn't really, do people choose something like Python over something like Ruby on performance grounds. > When I write code I want to know I am using tools that give me the > best performance for the effort that I can possibly get as opposed to > tools that guarantee no matter how hard I work performance will always > be lacking. You might want to move from Python to Perl, then. Maybe you should then move from Perl to C++. Of course, then perhaps you should consider moving from C++ to Objective Caml. At that point, you might consider moving on to C. Once you get to C, you might consider moving on up to assembly language. While you're playing around in assembly language, you could even choose your architecture (and thus your specific flavor of assembly language) based on the CPU instruction set. Let me know when you get to the point that you're writing the equivalent of shell scripts in assembly on the architecture with the most efficient CPU instruction set. At that point, I'll believe what you say about putting all your eggs in the performance basket. > When people choose to make their choices of languages a religious > issue they can become rather short-sighted in how they choose to > resolve programming problems. Yes, you can certainly do that when you religiously attach yourself to single-issue arguments for one language over another. > I prefer to be agnostic about programming languages. I choose those > that perform the best and I ignore the rest. These are contradictory statements. I'm sure pretty much everyone here can see the faults in your arguments for what they are. As such, you're not really doing a lot of damage to the reputation of Ruby -- and any attemps to chalk all this up to an attempt to get Ruby core developers to change their focus to performance are self-evident nonsense, considering I'm sure they know far better than you (and me) the key issues they face. On the other hand, you're positioning yourself as a representative of Python on a Ruby list. I'm not a fan of Python. I don't personally like it. On the other hand, I can step back and (somewhat) objectively recognize Python's advantages as a language. It really is a great language in purely technical terms, as are Ruby, Perl, Objective Caml, and a host of other languages, regardless of whether it's a great language \*for me\*. If you're doing any damage to any language community, however, it's to the Python community, by giving people one more data point in their statistical comparisons of the attitudes of Pythonistas. That's not very fair to the Python community. You'd be doing us a favor if you stopped contributing to the Noise:Signal ratio, but you'd be doing Python's community a bigger favor by ceasing to pretend to advocate for Python. I really only comment on this in hopes that it may forestall any knee-jerk reactions to you that may lead to others judging Python more harshly because of this one self-appointed representative. In other words, I may be addressing you, but you're not my audience. > **···** > > On Mon, Sep 24, 2007 at 11:55:05AM +0900, Ruby Maniac wrote: > > -- > CCD CopyWrite Chad Perrin [[http://ccd.apotheon.org](http://ccd.apotheon.org) ] > Kent Beck: "I always knew that one day Smalltalk would replace Java. I > just didn't know it would be called Ruby." ---
**Author:** ![Ron\_Fox](https://avatars.discourse-cdn.com/v4/letter/r/e8c25b/32.png) [@Ron\_Fox](https://rubytalk.org/u/Ron_Fox)\ **Post date:** [25 September 2007 12:20 UTC](https://rubytalk.org/t/this-is-why-ruby-1-8-6-can-never-be-made-to-run-anywhere-near-as-fast-as-python-2-5-1/40861/10 "2007-09-25T12:20:09Z")
I'm new to this newsgroup, having come here from many years with another scripting language (Tcl/Tk; in fact in about 2hrs I'll be on my way to New Orleans for Tcl 2007). I'm going to spout a slightly different belief than most of the respondents. There are cases where speed is almost completely irrelevant. What is important is completion of a functioning application that satisfies the customer (internal or external). For many many applications this can be done, on modern computers without any attention to the speed of the application. If my program takes 100ms to execute and yours takes 1usec, I contend that most users will not notice, or care about the difference. I also contend that while there \>are\< cases where performance is important (much of my work is doing soft real-time data taking systems for a national nuclear physics research lab... performance for the data taking parts of those systems is critical), for a great deal of software it is not. For responsiveness to a GUI element, you can pretty well work in the 100-500ms range of performance...for all but graphically intensive games where you have to get down to about 16ms. Whatever language works in that performance range for your application is suitable. So what I would say is rather closed minded is the statement: \> I prefer to be agnostic about programming languages. I choose those \> that perform the best and I ignore the rest. If that's true, start learning assembly. That's going to give you the absolute best performance...for a specific machine. And that points to the real issues. For me, choosing a programming language is a set of engineering compromises. The compromises are usually a result of the dynamic tension between the need to hit specific performance goals, the portability of software written in the language, the expressive power of the language in the problem domain in which I'm working, and the availability of mature, low defect libraries in the problem domain in which I'm working. What drove me to Ruby, for example, is a new project to do laboratory administrative data processing that requires us to show a specification of the underlying business process and demonstrate that the code faithfully executes it, and the existence of John Metraux's OpenWfeRu and the densha example of how to host it on rails, as a tool to solve this problem....and about 2-3 weeks evaluating this tool for suitability as a partial solution to this problem. I \_am\_ programming language agnostic. As such I write and have written in Assembler, Forth, Fortran, C, C++, Tcl/Tk, Ruby, Perl, Python, Pascal.. I've even developed application specific languages and then used them. None of these languages is a silver bullet. Each has advantages and disadvantages, and the wise programmer will weigh them carefully when selecting which ones to use to solve any given problem. Ron Fox National Superconducting Cyclotron Lab Michigan State University East Lansing, MI 48824-1321 Ruby Maniac wrote: > **···** > > > I welcome any corrections anyone might be able to make since I am new > > to Ruby with less than 3 months experience under my belt. > > > > Ruby 1.8.6 is an interpreted langauge that does not have a byte-code > > driven VM at this time. > > > > Python 2.5.1 is an interpreted language that does have a byte-code > > driven VM. > > > > I have been able to make Ruby code run 5% faster or more simply by > > removing nothing but comments - the more comments I remove the faster > > the code runs up to no more than 6% or 7%. > > > > Ruby syntax seems to favor the notion that fewer characters is better > > than more characters. Lexically interpreted langauges would want this > > to be the case since it takes more effort to lex more characters. > > > > Python runtimes are not affected by the number of characters one uses > > such as extra whitespace or comments - removing comments does not make > > Python code run faster simply because the comments have been removed. > > > > Python has a very powerful JIT (Just In Time compiler) known as Psyco > > with which certain Python expressions such as LC (List Comprehensions) > > and others can be made to run 20x to 100x faster at runtime. > > > > Recently as a test I wrote a rather simple Python program that > > processed all characters of a 20 MB file by setting the MSB to 1. The > > original Python code I began with executed in 65 seconds before I > > began to optimize the code. After the code was fully optimized it ran > > in just under 3 secs. After Psyco was used the runtime for the same > > problem was less than 1 second. > > > > The Ruby code I wrote before any optimizations were applied ran in > > about 65 seconds or no faster than Python with no optimizations. The > > most optimized Ruby code I could find for this problem was able to > > execute in just under 22 seconds using techniques that were not > > necessary when optimizing the Python code. > > > > Given the best Ruby is capable of doing versus the best Python is > > capable of doing Ruby ends up being more than 20x slower than Python > > and I think I know why. > > > > It is just not possible to make Ruby 1.8.6 execute any faster than the > > Ruby interpreter is capable of executing the code due to the lack of a > > byte-code driven VM. Maybe someday YARV will make Ruby code run 2x > > faster than Ruby 1.8.6 but that day has not arrived yet and may never > > arrived. > > > > Even if YARV proves to be 2x faster than Ruby 1.8.6 the resulting Ruby > > code will still be 10x slower than the fastest Python code. > > > > The only way YARV will get faster than Python is whenever someone > > codes a JIT compiler for YARV that provides the same performance boost > > to Ruby that Psyco provides to Python. As far as I can tell nobody is > > working on any such JIT for YARV and since YARV has been under > > development for at least the last 14 to 18 months one can only surmise > > a JIT for YARV would take a significant amount of time to produce and > > release to the Ruby community. > > > > The bottom line is that Python can be made to run as fast as machine > > code but Ruby cannot. > > > > I know some people want to try to use Ruby for every single problem > > they are faced with but doing so would be less than wise since there > > are no tools that work for all problems. > > > > Some problems lend themselves nicely to Ruby such as Open Source > > products where giving away the source code is not a business > > problem. > > > > Python is useful for problems that require fast runtimes such as 3D > > modelling or video game programming. > > > > Ruby would not be fast enough for the kinds of problems where people > > are using Python. > > > > I have not been able to find any references to Ruby being used for 3D > > realtime video game programming but I have been able to find many > > references to Python being used for 3D realtime video game > > programming. > > > > I don't expect those who read this to applaud my efforts to discuss > > this in this forum however I feel we need to discuss this so that some > > may choose to take actions to make Ruby run faster at runtime just as > > work was done to make Python run faster at runtime. > > > > Believe it or not I actually like Ruby 1.8.6 but I would hesitate to > > try to use Ruby for situations where runtime performance was an issue > > or whenever I did not want to release the source code. > > > > When I write code I want to know I am using tools that give me the > > best performance for the effort that I can possibly get as opposed to > > tools that guarantee no matter how hard I work performance will always > > be lacking. > > > > The same comments could be made about Rails. Rails emits SQL > > statements that have a lot of "\*" characters. Those of us who have > > been coding SQL long enough know the use of "\*" characters makes SQL > > statements run slower than when fully qualified column names are used > > rather than the "\*". I coded a simple benchmark that demonstrated > > this very clearly; whenever "\*" was used rather than a list of column > > names the resulting SQL statements ran 10% to 880% slower than when > > the "\*" was replaced with a list of column names even when the list of > > column names was quite long. > > > > Oddly enough I quite easily found more powerful Database Frameworks > > for Python that did not emit SQL code that used "\*" characters and I > > was even able to find some interfaces for those SQL Frameworks that > > would allow seasonsed Rails developers use Rails statements when > > describing their database relationships. > > > > I know of some Ruby developers who rejected the idea that the use of > > "\*" in SQL statements would be slower than long lists of column > > names. From the perspective of a Ruby on Rails developer who has not > > coded anything but Rails or Ruby it might seem logical that fewer > > characters is better than more characters and so the use of "\*" in SQL > > statements must be optimial because this is how Ruby works, right ?!? > > Wrong ! > > > > Even when some RoR developers are faced with benchmarks that > > demonstrate the use of "\*" in SQL statements can be 10% to 880% slower > > than not using "\*" characters they still chose to reject the > > benchmarks and deny the benefits of not using Rails because Rails is > > not able to automatically replace "\*" with lists of column names, > > apparently. > > > > When people choose to make their choices of languages a religious > > issue they can become rather short-sighted in how they choose to > > resolve programming problems. > > > > I prefer to be agnostic about programming languages. I choose those > > that perform the best and I ignore the rest. > > > > Ruby is a cute language that may someday become useful but this won't > > happen unless the Ruby community becomes interested in making Ruby > > perform better at runtime. In the meantime, I will use Ruby only when > > I must as for the rest I will most-likely use Python unless the > > problem suggests another language may be more useful. ---
**Author:** ![James\_Britt](https://avatars.discourse-cdn.com/v4/letter/j/22d042/32.png) [@James\_Britt](https://rubytalk.org/u/James_Britt)\ **Post date:** [24 September 2007 05:05 UTC](https://rubytalk.org/t/this-is-why-ruby-1-8-6-can-never-be-made-to-run-anywhere-near-as-fast-as-python-2-5-1/40861/11 "2007-09-24T05:05:46Z")
Why do people troll? What pleasure could it bring? ---
**Author:** ![M\_Edward\_Ed\_Borasky1](https://avatars.discourse-cdn.com/v4/letter/m/e9c0ed/32.png) [@M\_Edward\_Ed\_Borasky1](https://rubytalk.org/u/M_Edward_Ed_Borasky1)\ **Post date:** [24 September 2007 05:26 UTC](https://rubytalk.org/t/this-is-why-ruby-1-8-6-can-never-be-made-to-run-anywhere-near-as-fast-as-python-2-5-1/40861/12 "2007-09-24T05:26:58Z")
Michael T. Richter wrote: > Can I ask why \*ANYBODY\* took a message by someone calling themselves > "Ruby Maniac" and using expressions like "cute language" as anything but > a troll? Anybody? Anybody? Bueller? > > Don't dignify these kinds of things with responses, peeps. Well ... yes ... I suppose if I hadn't just run the benchmarks and posted the results, I wouldn't have responded. But I am so thrilled to see that 5X number for "YARV". Is there anyone here who thinks they can get a 5X boost for Python 2.5? Perl 5.8.8? PHP 5? ---
**Author:** ![M\_Edward\_Ed\_Borasky1](https://avatars.discourse-cdn.com/v4/letter/m/e9c0ed/32.png) [@M\_Edward\_Ed\_Borasky1](https://rubytalk.org/u/M_Edward_Ed_Borasky1)\ **Post date:** [24 September 2007 13:01 UTC](https://rubytalk.org/t/this-is-why-ruby-1-8-6-can-never-be-made-to-run-anywhere-near-as-fast-as-python-2-5-1/40861/13 "2007-09-24T13:01:16Z")
William James wrote: > **···** > > > On Sep 23, 9:50 pm, Ruby Maniac \ wrote: > > > > > Ruby is a cute language that may someday become useful > > > > Someday when you are a more experienced programmer, you > > may realize that doing bitwise operations on each byte > > of a 2-megabyte file is not an appropriate task for a > > "scripting language". That calls for a lower-level language. > > Well ... if the bitwise operations are built into the "scripting > language", why \*shouldn't\* they be used? It's not like you have to make > them up by converting the bytes to floating point values, converting > them to an array of floating point ones and zeroes and doing ANDs and > ORs on them with floating point equality tests in IF statements! ---
**Author:** ![W\_James](https://avatars.discourse-cdn.com/v4/letter/w/e274bd/32.png) [@W\_James](https://rubytalk.org/u/W_James)\ **Post date:** [24 September 2007 16:15 UTC](https://rubytalk.org/t/this-is-why-ruby-1-8-6-can-never-be-made-to-run-anywhere-near-as-fast-as-python-2-5-1/40861/14 "2007-09-24T16:15:05Z")
I think the o.p. isn't exactly a troll. I think he is simply young, naive, inexperienced, and presumptuous. There seems to be some honesty in his posts. > **···** > > On Sep 24, 12:12 am, "Michael T. Richter" \ wrote: > > > Can I ask why \*ANYBODY\* took a message by someone calling themselves > > "Ruby Maniac" and using expressions like "cute language" as anything but > > a troll? Anybody? Anybody? Bueller? > > > > Don't dignify these kinds of things with responses, peeps. ---
**Author:** ![7stud1](https://avatars.discourse-cdn.com/v4/letter/7/59ef9b/32.png) [@7stud1](https://rubytalk.org/u/7stud1)\ **Post date:** [25 September 2007 03:53 UTC](https://rubytalk.org/t/this-is-why-ruby-1-8-6-can-never-be-made-to-run-anywhere-near-as-fast-as-python-2-5-1/40861/15 "2007-09-25T03:53:48Z")
Bill Kelly wrote: > I've dabbled in a number of languages, but I've written actual > production code in assembler, Forth, C, C++, Objective-C, Java, > Perl, Python, Ruby, and (kill me now) VB6. Hi, Thanks for the well written post. Can you give a little more insight into how you came to be using ruby as your programming language of choice instead of any of the other languages you mentioned. I know why you might choose ruby over C/C++ or Java, but what lead you to choose ruby over python, which as far as I can tell is ruby's closest neighbor. Thanks. > **···** > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). ---
**Author:** ![Charles\_Oliver\_Nutte](https://avatars.discourse-cdn.com/v4/letter/c/71e660/32.png) [@Charles\_Oliver\_Nutte](https://rubytalk.org/u/Charles_Oliver_Nutte)\ **Post date:** [25 September 2007 08:26 UTC](https://rubytalk.org/t/this-is-why-ruby-1-8-6-can-never-be-made-to-run-anywhere-near-as-fast-as-python-2-5-1/40861/16 "2007-09-25T08:26:31Z")
Wilson Bilkovich wrote: > Some corrections: > 1. YARV is 'out', in the form of Ruby 1.9. A stable release is coming > in a matter of months. A stable development release. As I understand it, 1.9.1 will still be considered "unstable" as far as release cycles go... - Charlie ---
**Author:** ![John\_Mettraux](https://avatars.discourse-cdn.com/v4/letter/j/f1d935/32.png) [@John\_Mettraux](https://rubytalk.org/u/John_Mettraux)\ **Post date:** [25 September 2007 12:43 UTC](https://rubytalk.org/t/this-is-why-ruby-1-8-6-can-never-be-made-to-run-anywhere-near-as-fast-as-python-2-5-1/40861/17 "2007-09-25T12:43:18Z")
Hi Ron, my name is "Mettraux". Thanks again for your contributions to OpenWFEru. And thanks for the ad here. Best regards, > **···** > > On 9/25/07, Ron Fox \ wrote: > > > What drove me to Ruby, for > > example, is a new project to do laboratory administrative data > > processing that requires us to show a specification of the underlying > > business process and demonstrate that the code faithfully executes it, > > and the existence of John Metraux's OpenWfeRu and the densha example of > > how to host it on rails, as a tool to solve this problem....and about > > 2-3 weeks evaluating this tool for suitability as a partial solution to > > this problem. > > -- > John Mettraux -///- [http://jmettraux.openwfe.org](http://jmettraux.openwfe.org) ---
**Author:** ![Shai\_Rosenfeld1](https://avatars.discourse-cdn.com/v4/letter/s/977dab/32.png) [@Shai\_Rosenfeld1](https://rubytalk.org/u/Shai_Rosenfeld1)\ **Post date:** [25 September 2007 12:47 UTC](https://rubytalk.org/t/this-is-why-ruby-1-8-6-can-never-be-made-to-run-anywhere-near-as-fast-as-python-2-5-1/40861/18 "2007-09-25T12:47:34Z")
Ron Fox wrote: > There are cases where speed is almost completely irrelevant. > What is important is completion of a functioning application that > satisfies the customer (internal or external). For many many > applications this can be done, on modern computers without any > attention to the speed of the application. If my program takes > 100ms to execute and yours takes 1usec, I contend that most users > will not notice, or care about the difference. > > I \_am\_ programming language agnostic. As such I write and have written > in Assembler, Forth, Fortran, C, C++, Tcl/Tk, Ruby, Perl, Python, > Pascal.. I've even developed application specific languages and then > used them. None of these languages is a silver bullet. Each has > advantages and disadvantages, and the wise programmer will weigh them > carefully when selecting which ones to use to solve any given problem. > > Ron Fox > National Superconducting Cyclotron Lab > Michigan State University > East Lansing, MI 48824-1321 there we go. 🙂 > **···** > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). ---
**Author:** ![Mohit\_Sindhwani1](https://avatars.discourse-cdn.com/v4/letter/m/dbc845/32.png) [@Mohit\_Sindhwani1](https://rubytalk.org/u/Mohit_Sindhwani1)\ **Post date:** [24 September 2007 05:25 UTC](https://rubytalk.org/t/this-is-why-ruby-1-8-6-can-never-be-made-to-run-anywhere-near-as-fast-as-python-2-5-1/40861/19 "2007-09-24T05:25:19Z")
John Joyce wrote: > Why do people troll? > What pleasure could it bring? Fear, uncertainty and doubt - that's what drives people! Cheers, Mohit. 9/24/2007 | 1:25 PM. ---
**Author:** ![Michael\_T\_Richter](https://avatars.discourse-cdn.com/v4/letter/m/9d8465/32.png) [@Michael\_T\_Richter](https://rubytalk.org/u/Michael_T_Richter)\ **Post date:** [24 September 2007 05:44 UTC](https://rubytalk.org/t/this-is-why-ruby-1-8-6-can-never-be-made-to-run-anywhere-near-as-fast-as-python-2-5-1/40861/20 "2007-09-24T05:44:27Z")
Control. People whose daily lives have little in the way of things they have control over like the illusion that upsetting other people and having them react is like controlling their own lives. > **···** > > On Mon, 2007-24-09 at 14:05 +0900, John Joyce wrote: > > > Why do people troll? > > What pleasure could it bring? > > -- > Michael T. Richter \ (GoogleTalk: > ttmrichter@gmail.com) > We should sell bloat credits, the way the government sells pollution > credits. Everybody's assigned a certain amount of bloat, and if they go > over, they have to purchase bloat credits from some other group that's > been more careful. (Bent Hagemark) [Next page](https://rubytalk.org/t/this-is-why-ruby-1-8-6-can-never-be-made-to-run-anywhere-near-as-fast-as-python-2-5-1/40861.md?page=2)