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

S

seekingleverage

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
 
A

Andreas Schwarz

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".
 
M

Mike Wilson

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

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).
 
W

William Morgan

Excerpts from (e-mail address removed)'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.
 
B

Bob Hutchison

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 :) 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
 
R

Robert Klemme

William Morgan said:
Excerpts from (e-mail address removed)'s mail of 25 Sep 2005 (CDT):

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)
 
A

Austin Ziegler

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.

-austin
 
M

Martin DeMello

Austin Ziegler said:
..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*.

http://rubygarden.org/ruby?BenchMarks

martin
 
J

John Carter

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.

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... :)


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 : (e-mail address removed)
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.
 
I

Isaac Gouy

Martin said:
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.)
 
S

seekingleverage

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

Thomas Sondergaard

William said:
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 :)

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 :)
 
A

Austin Ziegler

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.)

Having to point out that you are running a dishonest "shootout" with
dishonest verbiage and aims is worse. I've told you how you can make
your little garbage site honest and shut me up. Have you done it, yet,
or do you want to keep being called on it?

If you're considering my pointing out that your shootout is garbage
and dishonest "abuse", then I must consider that the truth must really
hurt. Because it's the absolute truth.

-austin
 
P

Patrick Hurley

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
 
I

Isaac Gouy

Austin said:
Having to point out that you are running a dishonest "shootout" with
dishonest verbiage and aims is worse. I've told you how you can make
your little garbage site honest and shut me up. Have you done it, yet,
or do you want to keep being called on it?

If you're considering my pointing out that your shootout is garbage
and dishonest "abuse", then I must consider that the truth must really
hurt. Because it's the absolute truth.

-austin

Have you even looked at the website in the last 6 months?

Austin, I have no desire to shut you up - make as many abusive personal
comments as you like - abuse is not an argument.

You are completely free to regard /your opinion/ as The Truth - others
may not share that confusion.
 
A

Austin Ziegler

Have you even looked at the website in the last 6 months?

Yes. The text that makes a lie of everything you claim about the site
is still there on the front page, as of 26 September 2005 15.55 EDT.
Further, the incorrect Ackermann result for Ruby (e.g., "error") is
still there (I've shown you at least four times how to fix that
problem -- and yet you still don't fix it -- and it has nothing to do
with the correctly implemented program, it has everything to do with
the test script). The default Perl program is still improper (Perl #4
is the only one that should be on the default list), Perl, Perl#2, and
Perl#3 all belong on the "interesting alternative implementations"
only. Indeed, the Python one still has a line of code that modifies
the same stuff as what Ruby requires you modify outside of the program
(where this properly belongs!). Without this line, *none* of the
Python runs works.

I pick on Ackermann, but the same flaws I pointed out in January ...
are still there.

Obviously, neither you nor anyone else running the Bogus Computer
Language Shootout wants to fix any of this and therefore are
demonstrably dishonest.

At least as concerns this.

-austin
 
I

Isaac Gouy

Martin, perhaps you could collect this stuff and put it into your wiki
page for future use?

Austin said:
Yes. The text that makes a lie of everything you claim about the site
is still there on the front page, as of 26 September 2005 15.55 EDT.

And that text would be?

Further, the incorrect Ackermann result for Ruby (e.g., "error") is
still there (I've shown you at least four times how to fix that
problem -- and yet you still don't fix it -- and it has nothing to do
with the correctly implemented program, it has everything to do with
the test script). The default Perl program is still improper (Perl #4
is the only one that should be on the default list), Perl, Perl#2, and
Perl#3 all belong on the "interesting alternative implementations"
only. Indeed, the Python one still has a line of code that modifies
the same stuff as what Ruby requires you modify outside of the program
(where this properly belongs!). Without this line, *none* of the
Python runs works.

Complaining that it's wrong for Python to provide functionality that
allows the program to run is simply bizarre. The problem is that Ruby
doesn't provide that functionality.

Perl#2 and Perl#3 are in alternatives - you're welcome to your opinion
about the other Perl program.

I pick on Ackermann, but the same flaws I pointed out in January ...
are still there.

And the same limitations in Ruby's support for recursion are still
there - as others on this list pointed out months ago.

For variety you could pick on takfp and JavaScript
http://shootout.alioth.debian.org/s...ython-0&p3=javascript-0&p4=php-0&sort=fullcpu
 
A

Austin Ziegler

Martin, perhaps you could collect this stuff and put it into your wiki
page for future use?



And that text would be?

Assuming that you actually care, look it up on the archives. The text
has not improved since the last time we talked about the alioth
shootout.
Complaining that it's wrong for Python to provide functionality that
allows the program to run is simply bizarre. The problem is that Ruby
doesn't provide that functionality.

No, the problem is that you don't *run* the Ruby program with an
expanded stack size. Matz has chosen to not make this available within
Ruby. This is *not* a flaw. The problem is your test script, not the
Ruby script. You've been told this for nine months now.
Perl#2 and Perl#3 are in alternatives - you're welcome to your opinion
about the other Perl program.

Perl#4 is the only one that actually implements the function in a
readable and usable way. Perl (unlabeled) implements it in a way that
acknowledges that it's a cheat nearly as much as the two alternatives
(#2 and #3).
And the same limitations in Ruby's support for recursion are still
there - as others on this list pointed out months ago.

Incorrect. With a *single* shell command, I can make the Ruby
Ackermann run perfectly (and, IIRC, better than the Python equivalent,
or at least to deeper recursion depths even with the Python language
"cheat"). This isn't undocumented; this has been mentioned to you
since January. It has *nothing* to do with the implementation of the
Ruby Ackermann, but the default stack size allocated to the Ruby
process. It's more restrictive under Windows, and that is probably a
compile-time option, but again -- it's *not* a Ruby problem. It's a
problem in your methodology and your assumptions. If you've screwed up
there, where *else* have you screwed up?

-austin
 
D

Devin Mullins

Isaac said:
Complaining that it's wrong for Python to provide functionality that
allows the program to run is simply bizarre. The problem is that Ruby
doesn't provide that functionality.
I think his argument is grounded, here. (No presupposition on his other
arguments; I don't particularly care, let alone know.) Many would
consider it a flaw that Python allows programs to escape the parameters
(namely, heap size) with which they were initiated. Ruby _does_ provide
the functionality that allows it to run, but leaves it up to the
launcher, and makes the matter unchangeable at runtime.

Devin
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top