You bet, I believe that the list roughly divides into three groups
about this, just search the archives for details.
The first is: The shootout is crap, do not worry at all! Count me in
here at 50%.
The second is: The shootout is not to be taken too seriously but still
is correct in tendency, still Ruby is fast enough for almost all it is
needed for. Count me in here at 50 % too
.
The third is: OMG Ruby is too slow.
Honestly there are view of us in the third category and those who are
there admit that it is only true for some specific needs.
In that cases it is sad but...
... there is no reason YARV will not put Ruby in the same league as
Python and Perl6.
Lua might be out of reach, but Lua has a different niche and is kind
of optimized for speed by design (at least from v5.1 on, correct me
someone here if I am wrong).
I really suggest to look at Lua if Ruby really is too slow for your
needs, which I doubt.
Are there slimmer highly optimized versions that are specifically
targeted towards certain platforms?
NTMVLK
Thanks.
Cheers
Robert
···
On 5/7/07, conker <hkchao@gmail.com> wrote:
--
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw
This has been beat to death in the past. Check out the archives.
In summary -- Sure, in general, Ruby is slower than some other popular interpreted languages. But it's hardly debilitatingly slow. I've got an asynchronous logger for ruby that will, even on modest hardware do 40-50k messages per second, for example. That's pretty fast. I've got a ruby web devel framework that buries (as well as I can test, since I don't see source for the tests anyway) the django numbers seen on this benchmark:
I find no value to this list. First, I remember when the same kinds of
people tried to say that Native C++ code ran faster than Delphi, but
every test showed Delphi faster. I even remember when I was doing dBASE
for windows, that there was an arrSort() (array sort) method that
crashed when you opened too many items through it. One of the Borland
engineers wrote a sorting algorithm which not only ran without crashing
but was 150+ times faster than the native C++ code used. DBASE is an
interpreted language also.
Just having an interpreted language is not enough to say that it will be
slow. This site does not say just what the test is or how it is coded
for each language. There are ways to code that will change the speed of
execution dramatically.
There was another thread about running something that requires 10 msec
time slicing that ruby was able to do reliably. 10 millisecond delay/callback - Ruby - Ruby-Forum This shows that things can
be run fairly fast. One poster said that windows has a 15 msec time
slice. For Ruby to work at 10 msecs is fast.
Also, the bottom line is not how many times you can run
1000000.times
p (123.456 / 987.654).to_s
in a second.
If it is fast enough, and it usually is, then there are other
considerations that are far more important. Can you get it running
reliably in the time allotted? It is easily maintained? Is it
extensible and otherwise easily modified and updated? There is more to
the value of a language than running a single floating point calculation
a bazillion times. As long as it works fast enough to keep users from
getting annoyed, it is fast enough.
To put things like that in a chart is for people that do not think
further than just the pretty pictures at what lies behind. The people
that support and want Ruby have far more to consider and want far more
from their programming language than that.
Good question. This will bug the heck out of the Rubyists... But...
While Ruby looks like it is superior, sorry, IS superior to all
languages, it doesn't have the support of any major business or
scientific community that would fund and help create a complete
programming language solution that "just works" out of the box.
Ruby is fun to play with, but too many times Ruby packages are not
updated, or only get partially implimented or the implimentator gets
bored and abandons the entire code mess er. project when he finally
get's a girl friend.
When I need demonstrated faster processing speed, a clean syntax with
OOP features without resorting to obtuse "Perl-isms", usable and
CURRENT documentation, and a community of programmers that know how
to program in C/C++ so they CAN help to IMPROVE the language instead
of mindlessly beating on newbies to just STFU and live with it until
Matz gets around in one of his pending future lives to fix Ruby, I
use Python.
-- Jason.
···
On May 7, 2:55 pm, conker <hkc...@gmail.com> wrote:
I still think that this is due to the fact that ruby is a very young
language by comparison. Not to mention, most of the development on
the language has been to add functionality. Since more and more
people are hopping on the ruby bandwagon, it is only a matter of time
till the bottlenecks in the language are overcame.
Then again, if performance is the key to an application, then one
shouldn't be using a scripting/interpretive language at all.
....
All that said, I'm still a perl fanboy
···
On May 7, 3:16 pm, khai...@enigo.com wrote:
On Tue, 8 May 2007, conker wrote:
> Hi All,
> It's sad to see ruby at the bottom of this list:
> Are there slimmer highly optimized versions that are specifically
> targeted towards certain platforms?
This has been beat to death in the past. Check out the archives.
In summary -- Sure, in general, Ruby is slower than some other popular
interpreted languages. But it's hardly debilitatingly slow. I've got an
asynchronous logger for ruby that will, even on modest hardware do 40-50k
messages per second, for example. That's pretty fast. I've got a ruby
web devel framework that buries (as well as I can test, since I don't
see source for the tests anyway) the django numbers seen on this
benchmark:
Considering that I often choose to spawn children from my programs, i
would definately want to consider startup/shutdown time or 'cpu time'
into the benchmark, as it would have a direct affect on 90% of
production environments *especially websites*.
···
On May 7, 6:50 pm, igo...@yahoo.com wrote:
On May 7, 1:55 pm, conker <hkc...@gmail.com> wrote:
> Hi All,
> It's sad to see ruby at the bottom of this list:
That said, I'm a decent C programmer, and I'd probably be able to help
people clean up C code related to Ruby. I *can* program in C. I even
do it sometimes!
-s
···
In message <1178665762.150011.29830@y80g2000hsf.googlegroups.com>, Jason writes:
When I need demonstrated faster processing speed, a clean syntax with
OOP features without resorting to obtuse "Perl-isms", usable and
CURRENT documentation, and a community of programmers that know how
to program in C/C++ so they CAN help to IMPROVE the language instead
of mindlessly beating on newbies to just STFU and live with it until
Matz gets around in one of his pending future lives to fix Ruby, I
use Python.
Hey, J. I heard that attempting to program in
Python is like trying to scratch your ass while
wearing a straitjacket. Is that true? If it is, then
why do you do it? Do you enjoy that sort of thing?
Let's give you something really easy to try.
Well, o.k., it would be really easy for languages
that are designed to enable the programmer,
not to hobble him. So I guess it won't be so
easy in Python.
Let's say we're doing some intense calculations
and we want to show a simple progress indicator:
Microsoft are releasing their own Ruby implementation (IronRuby) as part of the Silverlight environment. Likewise Sun liked JRuby enough to hire Charles O Nutter, so that's two major businesses that are already putting their money into Ruby. How much money waits to be seen, but neither company is known for doing things by halves.
Assuming an appropriate add-on for Visual Studio, IronRuby will give 90%+ of PC users an out-of-the-box development solution. Likewise there's an Eclipse plug-in for Java developers and on the Mac it's a relatively painless process to install the RubyCocoa and RubyAEOSA packages, which add support for Ruby to XCode (although it'd be nice if Apple rolled support in themselves, considering their inclusion of Rails in Leopard).
Ellie
Eleanor McHugh
Games With Brains
···
On 9 May 2007, at 00:10, Jason wrote:
On May 7, 2:55 pm, conker <hkc...@gmail.com> wrote:
It's sad to see ruby at the bottom of this list:
Any thoughts on this?
Good question. This will bug the heck out of the Rubyists... But...
While Ruby looks like it is superior, sorry, IS superior to all
languages, it doesn't have the support of any major business or
scientific community that would fund and help create a complete
programming language solution that "just works" out of the box.
Considering that I often choose to spawn children from my programs, i
would definately want to consider startup/shutdown time or 'cpu time'
into the benchmark, as it would have a direct affect on 90% of
production environments *especially websites*.
Hm... I am not sure. Fast web site frameworks usually do not require spawning processes all the time because they have modules loaded into the webserver, use FastCGI or similar. The reason is of course even if the programming environment's startup overhead is low there is still the OS imposed overhead of creating processes. And that cannot be reduced easily.
On May 8, 6:09 pm, Jason <rsfr...@yahoo.com> wrote:
> I use Python.
Hey, J. I heard that attempting to program in
Python is like trying to scratch your ass while
wearing a straitjacket. Is that true? If it is, then
why do you do it? Do you enjoy that sort of thing?
Please, let's try and be civil.
Search Google for: "Ruby programming jobs"
(Don't forget the double quotes.)
Sorry about that, I meant environments that I work on. i'm a QA
automation framework designer, and more oft then not, i use cgi
interfaces to drive my automation.
···
On May 9, 2:00 am, Robert Klemme <shortcut...@googlemail.com> wrote:
Please do not top post. Thank you!
On 08.05.2007 19:28, knohr wrote:
> Considering that I often choose to spawn children from my programs, i
> would definately want to consider startup/shutdown time or 'cpu time'
> into the benchmark, as it would have a direct affect on 90% of
> production environments *especially websites*.
Hm... I am not sure. Fast web site frameworks usually do not require
spawning processes all the time because they have modules loaded into
the webserver, use FastCGI or similar. The reason is of course even if
the programming environment's startup overhead is low there is still the
OS imposed overhead of creating processes. And that cannot be reduced
easily.
Let's say we're doing some intense calculations
and we want to show a simple progress indicator:
40.times {
print "."
time_consuming_routine
}
puts "\nFinished."
And the output is
........................................
Finished.
<snip>
Can you figure out how to do this trivial task
in Python?
Not hard. Trivial, in fact.
for i in range(0,40):
You don't actually need the "0," part there. "for i in range(40):" would be more typical.
sys.stdout.write('.')
time_consuming_routine()
sys.stdout.write("\nFinished.")
Note that due to buffering of standard output, both snippets may not actually produce any output until the final puts/print. In the Ruby script, add "$stdout.flush" after the print. In Python, add "sys.stdout.flush()" after the sys.stdout.write.
Let's say we're doing some intense calculations
and we want to show a simple progress indicator:
40.times {
print "."
time_consuming_routine
}
puts "\nFinished."
And the output is
........................................
Finished.
<snip>
Can you figure out how to do this trivial task
in Python?
Not hard. Trivial, in fact.
for i in range(0,40):
You don't actually need the "0," part there. "for i in range(40):" would be more typical.
sys.stdout.write('.')
time_consuming_routine()
sys.stdout.write("\nFinished.")
Note that due to buffering of standard output, both snippets may not actually produce any output until the final puts/print. In the Ruby script, add "$stdout.flush" after the print. In Python, add "sys.stdout.flush()" after the sys.stdout.write.
I realised that - it wasn't part of the spec, though
> William James wrote:
>
> Search Google for: "Ruby programming jobs"
> (Don't forget the double quotes.)
>
> Then search for: "Python programming jobs"
>
> Then we will see who is scratching his ass
Just, and also try: "Cobol programming jobs"
and you'll guess the future (
-- Maurice
I think you meant the "new" Cobol ie "PHP Programming"... Now that is
a scary number...
More scary is the future Global Warming from the excessive power
generation caused by PHP (and Rails) burning all those extra unneeded
CPU processor cycles
But to "guess the true future", Python is behind the "Sugar" of the
OLPC project...