Depending on circumstances byte-codes can actually be faster than machine code.
An example.
Many years ago, Digitalk produced a Smalltalk implementation for PCs.
They continually had to answer questions about the performance of
byte-code interpretation. When they came out with a version 32-bit
PCs they decided to expand everything to x86 machine code, so that
they could say that their Smaltalk was compiled instead of
interpreted.
What they learned was that the machine code version actually ran
slower due to locality of reference and paging.
Of course tuning the performance of anything, and in particular a
dynamic language implementation, is as much of an art as a science,
and requires constant experimentation and willingness to overcome
one's assumptions.
···
On 9/27/07, Clifford Heath <no@spam.please.net> wrote:
The other performance factor (related to a different discussion) that
makes byte-code interpretation faster than AST-interpretation is that
with byte-code, you get much better locality of reference, so your
cache+memory system works much better. This is a *very* significant
factor that justifies some recent complaints.
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
Charles Oliver Nutter wrote:
Startup time does not general performance make. Just ask Java 
True, but lack of memory pressure enables you to keep the whole
working set in memory, and that does affect runtime.
Plus there is a large class of applications for which startup time
dominates, otherwise we'd be writing /bin/cat in Java :-).
Clifford Heath.
I rather strongly suspect that you are not a psychologist -- and that,
even if you were, you would not be trying to diagnose people over the
Internet. Please stick to the discussion topic rather than attempting to
assign motivations and emotions to others involved in the discussion as
an alternative to making a salient point.
···
On Fri, Sep 28, 2007 at 07:31:17PM +0900, Byung-Hee HWANG wrote:
On Fri, 2007-09-28 at 19:17 +0900, Francis Cianfrocca wrote:
> On 9/27/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
> >
> > Which is why they teach data structures in computer science class. It's
> > all about fast search, I think. That's one of the big gripes I have with
> > "lazy" interpretation. If you don't do stuff until you have to do it, it
> > only pays off if you end up *never* having to do it.
[...snip...]
> I've found in my businesses that such fleeting opportunities come up all the
> time. If you're a person who believes in proper software engineering, and
> well-controlled processes, you're probably climbing the walls and getting
> ready to throw things at me right now! But this is why I was talking about a
> value-tradeoff. If I'm right, then there are a lot of opportunities to
> create capturable business value that traditional methodologies (including
> fast-prototype-followed-by-extensive-rewrite) simply can't touch.
>
> For these cases, Ruby is uniquely valuable.
It seems like you are angry. I can feel that you like Ruby very much.
[...snip...]
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Baltasar Gracian: "A wise man gets more from his enemies than a fool from
his friends."
10-1 is no exaggeration, and may indeed be understating it. For a software
micro-effort to throw off capturable business value, the documentation is
almost more important than the program. That's precisely *because* the
analysis of fleeting value-opportunities is also fleeting. I've gotten quite
used to putting short (< 2000 lines) Ruby scripts into production and having
them run trouble free (except for slow performance and high memory
consumption). I've gotten just as used to completely (and willfully)
forgetting all the technical analysis about them after they're written. I
can do this to a very limited extent in Java, but I've never managed it in
Python.
···
On 9/28/07, Robert Dober <robert.dober@gmail.com> wrote:
On 9/28/07, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
<snip>
>
> In some respects, guilty as charged. (I deny the point about
> non-understandability. If you're going to develop like this, then
writing
> documentation and unit tests *must* dominate the development effort,
perhaps
> by 10-to-1. Otherwise, you end up with nothing usable.)
This however (although 10 might be an exaggeration) is a good thing
more often than not.
Angry? Well, no, not in particular. I reserve anger for injustice,
malfeasance, and incompetence. In short, for things that people do, not that
machines do.
···
On 9/28/07, Byung-Hee HWANG <bh@izb.knu.ac.kr> wrote:
On Fri, 2007-09-28 at 19:17 +0900, Francis Cianfrocca wrote:
> I've found in my businesses that such fleeting opportunities come up
all the
> time. If you're a person who believes in proper software engineering,
and
> well-controlled processes, you're probably climbing the walls and
getting
> ready to throw things at me right now! But this is why I was talking
about a
> value-tradeoff. If I'm right, then there are a lot of opportunities to
> create capturable business value that traditional methodologies
(including
> fast-prototype-followed-by-extensive-rewrite) simply can't touch.
>
> For these cases, Ruby is uniquely valuable.
It seems like you are angry. I can feel that you like Ruby very much.
I second the motion.
For most of what I write in Ruby, startup time is *much* more important
than long-running performance. I'd prefer to avoid having to go back to
Perl for some of that, to avoid extremely long waits (for some definition
of "extremely long") for basic sysadmin utilities.
···
On Fri, Sep 28, 2007 at 02:20:04PM +0900, Clifford Heath wrote:
Charles Oliver Nutter wrote:
>Startup time does not general performance make. Just ask Java
Plus there is a large class of applications for which startup time
dominates, otherwise we'd be writing /bin/cat in Java :-).
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
print substr("Just another Perl hacker", 0, -2);