Is ruby is faster than all Object oriented Scripting langs

[mutahhir hayat]

[Note: parts of this message were removed to make it a legal post.]

I really don't understand the extensive dicussions on such a moot point.
Running the same algorithm on two languages, and running a reasonably
complex application is different. As someone above already stated, get the
10% and optimize it all you want. The main point will still be getting the
project out of the door. Frankly, if performance is your primary
requirement, why would you EVER want a scripting language? These are
designed with ease of use in mind, and made from higher level structures. If
you want core performance, just write Assembly, or if you want (some)
portability, C code. Its been done before all these scripting languages were
developed, and it can be done now.

The moot point is, that if you can't get the project out of the door in your
deadline, would you really need performance?

Ruby is slow... so was C when it came out because everyone was used to
Assembly. But C had its advantages, it was more portable than Assembly, was
structured, and a slew of other features that just made the "developer"s
life easier, nothing more. What you can do in one language, you can do in
the other. I'm talking about the results, not the way of doing it.

As far as i see, code in the language you like to work in, know how to use
it well, far too many people don't know how to implement the proper
algorithm in the proper place anyway, so care about your tools later when
you hit a brick wall, but till you hit it, take the fastest route to your
destination. That is efficiency.

Also, a lot of the books written by a lot of the greats were done at the
time where the hardware was limited, and the common developer required
certain ninja skills to do what they wanted. Now, its a little different.
You just can't expect the philosophy of driving a moped to apply to driving
a ferrari. I'm not saying that you should just write crappy code as you
like, but just that you need to write good solid "code" and worry about the
language when it gives you a problem. As knuth said, "premature optimization
is the key to all evil (or atleast most of it) in programming". -- Have you
had a problem with performance with ruby? with python? Just pick a language
that you can actually learn, and pick a good book, take some time to use it
well, design your project well, implement the proper architecture,
datastructures and algorithms and use whatever language you are comfortable
in.

 

[M. Edward (Ed) Borasky]

Also, a lot of the books written by a lot of the greats were done at the
time where the hardware was limited, and the common developer required
certain ninja skills to do what they wanted. Now, its a little different.
You just can't expect the philosophy of driving a moped to apply to driving
a ferrari. I'm not saying that you should just write crappy code as you
like, but just that you need to write good solid "code" and worry about the
language when it gives you a problem. As knuth said, "premature optimization
is the key to all evil (or atleast most of it) in programming".

First of all, I'm not at all sure whether it was Knuth, Dijkstra, Hoare
or Wirth that first coined this "proverb". It sounds to me more like
Wirth than the other three. Second, as I've already posted, in no way
does that proverb, even if you happen to believe in it, justify lack of
attention to performance at any point in the software development cycle.
And as a working performance engineer, I think that proverb is simply
nonsense.

 

[mutahhir hayat]

[Note: parts of this message were removed to make it a legal post.]

First of all, I'm not at all sure whether it was Knuth, Dijkstra, Hoare
or Wirth that first coined this "proverb". It sounds to me more like
Wirth than the other three.

Hoare is usually attributed to saying that first, and Knuth popularized it,
in anycase, its irrelevant to the discussion.

Second, as I've already posted, in no way
does that proverb, even if you happen to believe in it, justify lack of
attention to performance at any point in the software development cycle.
And as a working performance engineer, I think that proverb is simply
nonsense.

That proverb does not relate to performance, although many relate that to
mean "no need for optimization". The operative word is "premature". I would
agree upon your considering performance in ever step of the cycle, however,
a more pragmatic approach is to fulfill the requirements, if performance is
one of them, sure, by all means, but if you're making a digital calculator
that will run on a quad core server with atmost 10 people using it at one
time, I'd hardly recommend performance as a major concern, and would rather
just fulfill the requirements as fast and economically possible. I don't
mean to trivialize the matter by giving such a simple example, but any
design principle that is valid universally should fit in every case. And in
my opinion, performance is a requirement, and should be treated as such, no
more no less.

 

[M. Edward (Ed) Borasky]

I would
agree upon your considering performance in ever step of the cycle, however,
a more pragmatic approach is to fulfill the requirements,

Yes ... as you state below, if a project is defined by requirements,
performance requirements should be specified. They fall under the
general heading of usability, and there are (and have been for decades)
rather well known rules of thumb.

but if you're making a digital calculator
that will run on a quad core server with at most 10 people using it at one
time, I'd hardly recommend performance as a major concern, and would rather
just fulfill the requirements as fast and economically possible.

This seldom happens in the real world. Nobody can create a significant
software project in total absence of any feedback from users or the market.

 

[mutahhir hayat]

[Note: parts of this message were removed to make it a legal post.]

Yes ... as you state below, if a project is defined by requirements,
performance requirements should be specified. They fall under the
general heading of usability, and there are (and have been for decades)
rather well known rules of thumb.

Are you saying that there are projects that have no requirements? I'm
sure that you don't mean that, so please elaborate.

This seldom happens in the real world. Nobody can create a significant
software project in total absence of any feedback from users or the
market.

Agreed, but please take the example in the context it was presented, and
that was that performance is nothing more than just "A" requirement. There
are times, when it pays to consider it, other times, you just waste your
time and money after something that won't even be apparent. Hence no value
for time spent.

 

[Eleanor McHugh]

Are you saying that there are projects that have no requirements?
I'm
sure that you don't mean that, so please elaborate.

Many projects have requirements which are only loosely identified at
the time of inception, but one that tends to be there from the very
beginning is "should perform acceptably for users". Ignore that
requirement at your peril


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[M. Edward (Ed) Borasky]

Many projects have requirements which are only loosely identified at the
time of inception, but one that tends to be there from the very
beginning is "should perform acceptably for users". Ignore that
requirement at your peril

Actually, there are implicit performance requirements based on decades
of usability theory. The "prime directive", as it were, is this:

1. Define "response time" as the time it takes from the moment that a
user sends a request to the moment when the system has returned its
response. There are application-dependent definitions as to when the
response is "complete", but these are usually obvious from other UI factors.

2. The ideal case is that the response time is under one second!
Anything over 10 seconds requires that the application notify the user
that it is busy. Between 1 and 10 seconds is kind of a "gray area", but
in general, times over 1 second interrupt a user's flow process and
should be avoided.

3. Users of a business application need faster response times than what
we consumers typically "tolerate" from web applications. For example, go
to your on-line credit card payment center and time how long it takes
from when you hit the "submit" button to when you get your confirmation
number back. It might be 10 seconds -- in the "good old days" I remember
seeing times of about a minute. Times like that are "tolerable" for
someone who makes a payment once a month. But someone in a business
posting data will need that response in under a second.

 

[Eleanor McHugh]

Actually, there are implicit performance requirements based on
decades of usability theory.

I remember sitting through lectures on this stuff twenty years ago as
part of a control engineering course at uni and it's stood me in good
stead over the years: in fact when I was writing interactive cockpit
systems the one second maximum response time requirement became so
ingrained that it's now second nature.

Obviously with the web network latencies can make it difficult to
display meaningful state updates on that kind of time-scale, but it
still bugs me how many AJAX apps stall on large data transfers when
the interface could be doing something to keep users engaged. It's a
good thing for most of these systems that user expectations are so
low...

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[thufir]

In fact, Dijkstra, in _A Discipline of Programming_, explicitly calls
out that one must pay attention to the twin concerns of correctness and
efficiency. And, while the hardware is orders of magnitudes faster and
cheaper than it was when Dijkstra wrote that, throwing hardware at an
inefficient design is still not economically viable in the long run and
probably never will be.

This ignore's Moore's Law, and Java's success. Microsoft as well is
going the VM route -- which has inherent overhead.



-Thufir

 

[thufir]

* It's generally pretty easy to optimize the 10% of the code where speed
is actually critical, even if you need to drop down to something like C
for just that part

that's an interesting point.


-Thufir

 

[Marc Heiler]

I agree these discussions are moot.

Hopefully the one who started it will reply, so far it looks
suspiciously as if it only served 7stud as further opportunity for
writing some more anti-ruby propaganda.

The biggest problem here is that for any application where one chooses
Python for SPEED it is hardly a convincing issue at hand. I dare claim
that ruby fits EXACTLY the same niche in the ecosystem. Look at
Javascript - it is not a great language, but it had a huge growth -
simply because the www grew and Javascript was ubiquitous.

It never ceases to amaze me how people put speed of "scripting"
languages into the center of attraction - one should go with lua if
speed is such a concern.

Or maybe pure C if it needs to be faster!

 

[William James]

It never ceases to amaze me how people put speed of "scripting"
languages into the center of attraction - one should go with lua if
speed is such a concern.

Or maybe pure C if it needs to be faster!

Pascal (FreePascal).
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all

 

[Julian Leviston]

Bugger that!

You gotta encode using boards of switches... pure binary man... none
of this assembler junk.

Julian.


Learn Ruby on Rails! CHECK OUT THE FREE VIDS (LIMITED TIME) NEW VIDEO
(#2) OUT 3rd APRIL
http://sensei.zenunit.com/

 

[Eleanor McHugh]

Bugger that!

You gotta encode using boards of switches... pure binary man... none =20=

of this assembler junk.

You are a Real Programmer and I claim my =A35


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Eivind Eklund]

In fact, Dijkstra, in _A Discipline of Programming_, explicitly calls out
that one must pay attention to the twin concerns of correctness and
efficiency. And, while the hardware is orders of magnitudes faster and
cheaper than it was when Dijkstra wrote that, throwing hardware at an
inefficient design is still not economically viable in the long run and
probably never will be.

In my experience, this varies with the domain.

For the business apps I presently work on, I often do things that are
10x to 100x slower than they could be - because the hardware power
required to run them is so much cheaper than my time would be, and I
still get response times that are within my requirements. I presently
run the stuff we have over a distributed cluster of about 10 machines.
This could almost certainly have been reduced to two and possibly one
- at the cost of much, much more development time. That would have
been a bad tradeoff.

For games and embedded systems development which I've done before, the
millions units that's produced has often made computer time much more
expensive than my programmer time, so optimizing made a lot of sense -
even at the cycle by cycle level.

You write that you're a performance engineer by profession; in that
profession, you'll mostly encounter the cases where performance IS an
issue, as nobody that has acceptable performance will throw a
performance engineer at the case. So, your sample will be skewed,
even though you'll have hit a lot more performance cases than I have.

Eivind.

 

[Eivind Eklund]

This ignore's Moore's Law, and Java's success. Microsoft as well is
going the VM route -- which has inherent overhead.

This is not entirely obvious. I remember one case where HP got a
significant performance increase by emulating PA RISC *on PA RISC
hardware*, because they could do branch prediction etc better in real
time - with real data - than at compile time.

Eivind.

 

[aks]

Well ... I beg to differ. If you actually read _Beautiful Code_, you
will see beautiful code in many languages ... even Fortran, IIRC.

The most beautiful piece of code, well.., it's a tie -- the two most
beautiful pieces of code I ever saw were both in assembly language.

The first, written in Univac 1108 assembler, performed a tree-
traversal over an AVL tree. It was astoundingly compact and
efficient.

The second, written in PDP-11 assembler, implemented a pattern-
matching algorithm that predated grep and regexps by several years
which was used to translate English text into IPA phonemes, then
translate IPA phonemes into Votrax phonemes, then translate Votrax
phonemes into ASCII codes. The same code with three different tables
of patterns. Efficient and beautiful.

A close third was a one-liner in APL that inserted a new item into a
doubly-linked list of them.

But, to bring this post on topic, I have to agree with some of the
others on this list that programming in Ruby makes me feel serenely
calm, and sometimes, happy. I find programming in ruby natural and
easy, once I made the jump over to the "everything is an object"
camp. This feeling exceeds any similar feelings that may
occasionally, and less frequently, occur when I program in sh, SQL,
Perl, or Python.

I like Python too, having written many thousands of lines of code in
it. Closures are very cool - I use them all the time. The lack of
explicit control structures is pretty, but the syntax causes
occasional problems with long expressions that require continuations.
And, I _still_ have to think a little bit when I do simple operations,
like joining an array. Python got it backwards. The join method
should have been an Array method, not a String method. The object to
the join method should have been the array, not the delimiter.

Ruby got this right: join is an Array method, split is a String
method. Ruby should have had a closure expression, and kind of does
if you consider Array::map {}

The _only_ problem I have with Ruby is the comparable difficulty of
finding and reading documentation from installed libraries. I have
been a Perl programmer since version 1 and think Larry made the Right
Choice when he integrated the Perl pods into the Unix "man" page
infrastructure.

How hard would it have been for Ruby and gem to publish their docs
into the "man" pages? This would have been the most Unix-compatible
way of sharing docs.