R
Ruby Maniac
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.
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.
call, s