Relative speed of Ruby vs Java for a large compiled app like Freenet

I'm wondering if anyone could shed some light on whether or not it
would make sense to do a Freenet client in Ruby.

Obviously, from an elegent code standpoint, Ruby is probably more
manageable and in general a better all round experience.

What I'm curious about though, is the execution speed of compiled Ruby
code vs Java running on the virtual machine.

Can anyone shed some light on this?

Thanks,
Phil

seekingleverage@gmail.com schrieb:

I'm wondering if anyone could shed some light on whether or not it
would make sense to do a Freenet client in Ruby.

Obviously, from an elegent code standpoint, Ruby is probably more
manageable and in general a better all round experience.

What I'm curious about though, is the execution speed of compiled Ruby
code vs Java running on the virtual machine.

Java is much faster. Search for "Language Shootout".

As with everything, this depends on a lot of factors. I've personally
found java's jvm to take a little longer to load (at least the last
time I timed it), and therefore short-lived programs can be faster in
Ruby. Although, that also leads me to the fact that I can generally
put better code together in Ruby than in Java, so expertise in a
language would obviously have a lot to do with it as well (not that
I'm an expert with Ruby -- just better than I am with Java).

···

On 9/25/05, seekingleverage@gmail.com <seekingleverage@gmail.com> wrote:

I'm wondering if anyone could shed some light on whether or not it
would make sense to do a Freenet client in Ruby.

Obviously, from an elegent code standpoint, Ruby is probably more
manageable and in general a better all round experience.

What I'm curious about though, is the execution speed of compiled Ruby
code vs Java running on the virtual machine.

Can anyone shed some light on this?

Thanks,
Phil

Excerpts from seekingleverage@gmail.com's mail of 25 Sep 2005 (CDT):

Obviously, from an elegent code standpoint, Ruby is probably more
manageable and in general a better all round experience.

What I'm curious about though, is the execution speed of compiled Ruby
code vs Java running on the virtual machine.

Java will probably be faster. But programming Java is known by the State
of California to rot your brain.

Probably the best idea for this type of thing is to write a base Freenet
library in C (if one doesn't exist already!), and do the higher-level
behavior in Ruby. As long as you're smart about how you divide things,
you can have the best of both worlds: the speed of C and the
maintainability of Ruby.

···

--
William <wmorgan-ruby-talk@masanjin.net>

I'm wondering if anyone could shed some light on whether or not it
would make sense to do a Freenet client in Ruby.

Obviously, from an elegent code standpoint, Ruby is probably more
manageable and in general a better all round experience.

What I'm curious about though, is the execution speed of compiled Ruby
code vs Java running on the virtual machine.

Can anyone shed some light on this?

Java will be faster once it gets going. The load time of Java is not great. For example, on my OS/X laptop a simple hello world program in Java takes about .4 seconds to run while the ruby program takes less than 0.05 seconds, so you've got a 0.395 second head start on Java :slight_smile: And you can do quite a lot using ruby in that time. A 'real' Java program might take several seconds to load and, even then, it may not 'settle down' for many seconds after that. Once Java is running, say in a web server, Java will respond to events very quickly -- the head start only applies to a command line start-up.

Performance is rarely the primary concern. A "fast solution" these days seems to mean "deliver real soon" rather than "deliver something speedy." Anyway, if I really needed speed I wouldn't be using Java, I'd likely use Common Lisp (CL is a dynamic language that is much faster than Java -- in both senses of the word 'fast').

Cheers,
Bob

···

On Sep 25, 2005, at 10:21 AM, seekingleverage@gmail.com wrote:

Thanks,
Phil

----
Bob Hutchison -- blogs at <http://www.recursive.ca/hutch/&gt;
Recursive Design Inc. -- <http://www.recursive.ca/&gt;
Raconteur -- <http://www.raconteur.info/&gt;

Andreas Schwarz schrieb:

seekingleverage@gmail.com schrieb:

I'm wondering if anyone could shed some light on whether or not it
would make sense to do a Freenet client in Ruby.

Obviously, from an elegent code standpoint, Ruby is probably more
manageable and in general a better all round experience.

What I'm curious about though, is the execution speed of compiled Ruby
code vs Java running on the virtual machine.

Java is much faster. Search for "Language Shootout".

PS: A more important limitation is that Ruby doesn't use native threads.

Excerpts from seekingleverage@gmail.com's mail of 25 Sep 2005 (CDT):

Obviously, from an elegent code standpoint, Ruby is probably more
manageable and in general a better all round experience.

What I'm curious about though, is the execution speed of compiled
Ruby code vs Java running on the virtual machine.

Java will probably be faster. But programming Java is known by the
State of California to rot your brain.

Thanks! Now I have it officially...

Probably the best idea for this type of thing is to write a base
Freenet library in C (if one doesn't exist already!), and do the
higher-level behavior in Ruby. As long as you're smart about how you
divide things, you can have the best of both worlds: the speed of C
and the maintainability of Ruby.

And C doesn't rot your brain? C'mon...

    robert (doing Java for a living - and Ruby for fun)

···

William Morgan <wmorgan-ruby-talk@masanjin.net> wrote:

...and then ignore everything that you read on it, because the Alioth
shootout is garbage run by people who don't know what they're doing
and are dishonest (at least to themselves) about this fact.

-austin

···

On 9/25/05, Andreas Schwarz <usenet@andreas-s.net> wrote:

seekingleverage@gmail.com schrieb:
> I'm wondering if anyone could shed some light on whether or not it
> would make sense to do a Freenet client in Ruby.

> Obviously, from an elegent code standpoint, Ruby is probably more
> manageable and in general a better all round experience.

> What I'm curious about though, is the execution speed of compiled Ruby
> code vs Java running on the virtual machine.

Java is much faster. Search for "Language Shootout".

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

William Morgan wrote:

Probably the best idea for this type of thing is to write a base Freenet
library in C (if one doesn't exist already!), and do the higher-level
behavior in Ruby. As long as you're smart about how you divide things,
you can have the best of both worlds: the speed of C and the
maintainability of Ruby.

I question whether that is actually "the best idea" for this type of thing. If you don't like java or C# or whatever that's fine, but something is wrong with you if you think it is easier to write the bulk in C and just do the higher level behaviour in ruby :slight_smile:

If you want (almost) ruby power for the higher level behaviour then you could consider C# mixed with IronPython. Or Java and JRuby for that matter, I'm just not sure how mature JRuby is.

I am not a troll!

Thomas :slight_smile:

William Morgan wrote:

Probably the best idea for this type of thing is to write a base Freenet
library in C (if one doesn't exist already!), and do the higher-level
behavior in Ruby.

I disagree. I think the best idea is to write the whole thing in Ruby, then profile it, then optimize the slow bits, then measure it again, then rewrite the slow bits in C if it still isn't fast enough.

In other words, use C as a last resort, not a first resort.

The problem is that there's no guarantee that the base Freenet functionality will turn out to be the performance bottleneck; and even if the bottleneck is somewhere in there, chances are the slowness will be concentrated in one or two key functions, and there's no need to write the lot in C.

In general, humans are very bad at predicting which bits of code will be the slow bits. Hence it's a good idea to write clean, simple code, measure it, and only then decide where to optimize.

Google: "premature optimization"

mathew

···

--
<URL:http://www.pobox.com/~meta/&gt;
          WE HAVE TACOS

Could we have a c2-style shootout debate thread somewhere on the wiki,
and then just point people to it? Otherwise the *same* thread plays
itself out *every last time*.

martin

···

Austin Ziegler <halostatue@gmail.com> wrote:

> Java is much faster. Search for "Language Shootout".

..and then ignore everything that you read on it, because the Alioth
shootout is garbage run by people who don't know what they're doing
and are dishonest (at least to themselves) about this fact.

Is that a limitation or a strength? It is only a limitation is you have an SMP or Hyperthreading machine. And even if you have an SMP, Unix processor are better than threads.

Even then, have you really looked closely at the semantics of C in the presence of threading? It's very very scary stuff I tell you. The fact is Ruby is rock solid and one of the most bug free systems I have used.

There is nothing quite like native threading to ruin that... :slight_smile:

Still the rules of programming haven't been suspended for _any_ tool. Java or Ruby.

Programmer time takes many orders of magnitude more than run time.

Faster Algorithms can make two order of magnitude differences to run times.

Optimization, can, if you're really lucky, speed things up by a factor of 2.

90% of the time is spent in 10% of the code. So concentrate on that.

You really do not know which 10% that is, so profile.

Debug and maintenance, not development are the dominant costs in long lived applications.

These rules of thumb make a fool of simple speed benchmarks. So long as you can meet your real time constraints, (which can be fudged using the C language interface) they weigh very heavily in favour of ease of development, debug and maintenance.

Which is why I have no hesitation in doing large Ruby apps.

John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong later."

From this principle, all of life and physics may be deduced.

···

On Sun, 25 Sep 2005, Andreas Schwarz wrote:

Andreas Schwarz schrieb:

seekingleverage@gmail.com schrieb:

I'm wondering if anyone could shed some light on whether or not it
would make sense to do a Freenet client in Ruby.

Java is much faster. Search for "Language Shootout".

PS: A more important limitation is that Ruby doesn't use native threads.

William Morgan wrote:

> Probably the best idea for this type of thing is to write a base Freenet
> library in C (if one doesn't exist already!), and do the higher-level
> behavior in Ruby. As long as you're smart about how you divide things,
> you can have the best of both worlds: the speed of C and the
> maintainability of Ruby.

This sounds like premature optimizations. Write the whole thing in
Ruby (or whatever language you find most productive). Test it (and
write test cases), verify its correctness. Then _if_ it is too slow
profile it, locating the bottlenecks. Last step is then to speed up
that small portion of critical path code (located by profiling, not
guessing) and optimize the algorithm and/or the implementation
(possibly rewriting a portion in C).

I started programming on machines that were orders of magnitude slower
than todays PC's. It has taken me years to train myself not to
optimize while writing code, but for the vast majority of work I do
now it is rarely an issue and when it is, optimizing well designed
correct code is generally not too difficult. There are exceptions to
every rule, but try it for a while.

Patrick

Excerpts from Robert Klemme's mail of 25 Sep 2005 (CDT):

And C doesn't rot your brain? C'mon...

This has already reached the point of religious debate, but... no, I
don't think it does. At least, in my experience, writing C code may
be irritating because you have to keep track of all the details like who
frees strings and whatnot, but it doesn't actively encourage cutting and
pasting like Java does.

Like I said, just my experience.

···

--
William <wmorgan-ruby-talk@masanjin.net>

Anecdote: my company works on realtime C++ 3D rendering software with JS and Lua bindings to the runtime. Lua is not nearly as nice as Ruby. To make matters harder for the scripters, we've chosen to do certain things (for speed and memory preserving) that make the scripting even more verbose. These choices undoubtedly have had a positive effect on performance, probably in the 1-2% FPS range. I work very hard to keep the Lua I write as fast and lean as possible. I made a change yesterday which took my (simple) presentation from ~890fps to ~910fps, and I was proud.

Then, yesterday, one of the C++ programmers found a naive code branch in the C++ renderer. The net result was a 15-20x speed increase. (My complex presentation went from 15fps to over 170fps on my machine.)

All the hard work and scripter-annoying decisions we made in the name of speed have had nowhere NEAR as big an impact on speed as a single 10-minute algorithm change *in code that was already C++*.

Yet again, we discover (in real life, real world code) that choosing the faster language helps a bit, but choosing the right algorithms is gobs more important.

I would agree with what matthew says - write it all in Ruby, the find out where you're being stupid (because we all are, now and then) and fix the ruby algorithms. THEN, if it's still not fast enough, find the sticking points and rewrite them in C and see how that goes.

I think the time you save in all-ruby writing should allow for the C conversion time (and then some), yielding a shorter development than writing a whole core library in C from the start. But then that depends on how your Ruby skills are compared to your C skills.

···

On Sep 29, 2005, at 11:21 PM, mathew wrote:

In general, humans are very bad at predicting which bits of code will be the slow bits. Hence it's a good idea to write clean, simple code, measure it, and only then decide where to optimize.

Google: "premature optimization"

Martin DeMello wrote:

>
> > Java is much faster. Search for "Language Shootout".
>
> ..and then ignore everything that you read on it, because the Alioth
> shootout is garbage run by people who don't know what they're doing
> and are dishonest (at least to themselves) about this fact.

Could we have a c2-style shootout debate thread somewhere on the wiki,
and then just point people to it? Otherwise the *same* thread plays
itself out *every last time*.

Please.
Or just provide a search to past threads like Patrick Gundlach
http://groups.google.com/group/comp.lang.ruby/msg/db0cc36766c6296c?hl=en&

Having to say over and over that Ruby currently has an obviously slow
interpreter and that doesn't matter as-long-as your program doesn't
spend much time in the interpreter grows old.

(Also Mr Ziegler's abuse has become stale.)

···

Austin Ziegler <halostatue@gmail.com> wrote:

http://rubygarden.org/ruby?BenchMarks

martin

Thank you very much people :-). Seriously, you all rock. All your
comments have helped me a lot. Thanks.

Excerpts from Patrick Hurley's mail of 26 Sep 2005 (CDT):

Write the whole thing in Ruby (or whatever language you find most
productive). Test it (and write test cases), verify its correctness.
Then _if_ it is too slow profile it, locating the bottlenecks. Last
step is then to speed up that small portion of critical path code
(located by profiling, not guessing) and optimize the algorithm and/or
the implementation (possibly rewriting a portion in C).

Yeah, this is probably the best idea for from-scratch applications. I
was thinking library because I figured either there was a Freenet
library out there, or there should be. A good linkable library would be
useful to everyone.

···

--
William <wmorgan@masanjin.net>

Excerpts from Robert Klemme's mail of 25 Sep 2005 (CDT):

And C doesn't rot your brain? C'mon...

This has already reached the point of religious debate, but...

No religious debate intended. :slight_smile:

no, I
don't think it does. At least, in my experience, writing C code may
be irritating because you have to keep track of all the details like
who frees strings and whatnot, but it doesn't actively encourage
cutting and pasting like Java does.

Like I said, just my experience.

Well, I can only speak for me and I don't feel encouraged to copy and paste a lot in Java. Why do you think this is?

Kind regards

    robert

···

William Morgan <wmorgan-ruby-talk@masanjin.net> wrote:

John Carter schrieb:

···

On Sun, 25 Sep 2005, Andreas Schwarz wrote:

Andreas Schwarz schrieb:

seekingleverage@gmail.com schrieb:

I'm wondering if anyone could shed some light on whether or not it
would make sense to do a Freenet client in Ruby.

Java is much faster. Search for "Language Shootout".

PS: A more important limitation is that Ruby doesn't use native threads.

Is that a limitation or a strength? It is only a limitation is you have an SMP or Hyperthreading machine. And even if you have an SMP, Unix processor are better than threads.

When you have to use blocking library calls, the lack of OS threads is a problem in Ruby.