Which programming language is faster - Ruby or Java?
This is one of the things that will decide whether I use Ruby or Java so
help is appreciated greatly.
Thanks.
···
--
Posted via http://www.ruby-forum.com/.
It depends what you mean by faster,
faster to learn,
faster to build a production quality application in,
faster to start up,
faster to execute
........
each will have a different answer, some quantifiable and some not.
Things like execution will depend on what you are doing, there are some
sites that benchmark languages
eg. http://shootout.alioth.debian.org/
that may help you.
Though depending on what you are doing pure execution speed may or may not
be the most important thing.
cheers
simon
···
On 8/26/07, Nick Nick <schaefer88@gmail.com> wrote:
Which programming language is faster - Ruby or Java?
This is one of the things that will decide whether I use Ruby or Java so
help is appreciated greatly.Thanks.
--
Posted via http://www.ruby-forum.com/\.
Nick el wrote:
Which programming language is faster - Ruby or Java?
This is one of the things that will decide whether I use Ruby or Java so
help is appreciated greatly.Thanks.
Development speed: Ruby, hands down
Execution speed: Java, hands down
That said, the main problem with execution speed are poor algorithms.
With ruby, you develop it, maybe in a quarter of the time you'd need in
java, then you see if it is fast enough. Most often you'll see it
already is. If not, you profile. Most often you'll then notice it is one
or two bottlenecks only. You'll see if you can make it faster using pure
ruby, if that fails, you can always write a C extension (or use a java
lib if you use jruby). In the end you spent half the time you'd spend
with java and your app runs fast enough.
Similar thing probably with java vs. c.
Regards
Stefan
···
--
Posted via http://www.ruby-forum.com/\.
Java code is definitely faster than Ruby code.
However, to solve same problem, programming in Ruby should be faster
than doing that in Java.
···
On Aug 26, 8:51 pm, Nick Nick <schaefe...@gmail.com> wrote:
Which programming language is faster - Ruby or Java?
This is one of the things that will decide whether I use Ruby or Java so
help is appreciated greatly.Thanks.
--
Posted viahttp://www.ruby-forum.com/.
Nick Nick wrote:
Which programming language is faster - Ruby or Java?
Those who tried both have learned programming Ruby is much faster. You can typically add a feature with the fewest edits. Java uses many negative systems, including static type checking and a redundant "import" command, that make you generally sit around filling out forms just to get anythig done.
Dave Thomas, an author of the Pickaxe Book for Ruby, describes the situation as "Ruby stays out of your way".
···
--
Phlip
Test Driven Ajax (on Rails) [Book]
"Test Driven Ajax (on Rails)"
assert_xpath, assert_javascript, & assert_ajax
I would use Ruby and then use C to do lower level tasks: including making use
of any Ruby bindings to things such as SDL to keep more of it in the Ruby
world. If the game is small enough you could probably do it all in Ruby or
Java without any thing to worry about. Unless of course you expect it to run
on old hardware (like 15-30 years old hardware).
A simple point being, Ruby is easier on most peoples time then C while C is
more efficient of the machines time then ours.
My experience with Java is roughly a decade out of date.... But in my opinion
Java has a good *design* on a number of things but is to verbose and annoying
to be *great* language. I've always found the common 'Hello world!' programs
most language introductions start with as a good way to see just how much
typing is expected for small tasks. I remember when I first started Java, I
thought system.out.println() was nicely arranged but so much more typing then
printf(). I learned a lot through studying Java but did my darn'st to _not_
write any Java programs.
I've found Ruby to be a very good balance for many things. While it might not
be the fastest on execution time but it makes a tremendous improvement in the
amount of time spent testing and debugging code. Even if you just chalk it off
to less lines of code needed for more complex tasks, Ruby is more efficient
for a lot of things. Things that are hard to do in Ruby or proof to much of a
bottleneck. Can be moved into a C Extension; if neccessary & you know how,
optimised at a lower level then Ruby as well. C is beautiful, Ruby is
Effective, together they are probably awesome in some ways xD
I was once told the language you find yourself using most is the one that best
suits you. That is what I usually suggest for people to use, the language that
suits them best. Why code in one language if you are better able to produce
quality code in another unless you had to?
TerryP.
···
--
Email and shopping with the feelgood factor!
55% of income to good causes. http://www.ippimail.com
If you want to understand how Ruby can be made to run fast I recommend
reading about the Strongtalk VM and reading Urs Hölzle's thesis,
"Adaptive Optimization for Self: Reconciling High
Performance with Exploratory Programming",
available on the web as
http://www.cs.ucsb.edu/labs/oocsb/papers/urs-thesis.html
http://www.cs.ucsb.edu/labs/oocsb/papers/hoelzle-thesis.pdf
Robert
···
--
I'm an atheist and that's it. I believe there's nothing we can know
except that we should be kind to each other and do what we can for
other people.
-- Katharine Hepburn
Decisions are hard... don't know what you're programming, but Java
plain sucks for web apps.
As for Ruby and web apps--it's 9 months later...had the training got
the t-shirt, still not doing Ruby or Rails...how long can one carry a
suitcase...?
I don't get paid for anything but web apps, and other enterprise
stuff. So I can't say about other types of programs.
I for one am very tired of wanting to use Ruby for webapps...can't
believe I wasted 9 months downloading all this crap...
rm -rf ~home/ruby-stuff
cd /usr/local/Zend/htdocs
HTH,
-r
···
On Aug 26, 7:51 am, Nick Nick <schaefe...@gmail.com> wrote:
Which programming language is faster - Ruby or Java?
This is one of the things that will decide whether I use Ruby or Java so
help is appreciated greatly.
I'm a bit confused about what you might mean, help me understand.
Do you mean small benchmark programs will be "much slower" when run
once rather than run 100 times? How much slower - 0.1x 10x 1000x ?
Do you mean we should not assume small program performance is a
reasonable estimate of large program performance?
Incidentally, I don't think "warm-up time" works as a description of
adaptive optimization - it makes it sound like a one-time-thing,
rather than continual profiling decompilation recompilation adapting
to the current hotspot.
···
On Aug 28, 5:59 pm, Charles Oliver Nutter <charles.nut...@sun.com> wrote:
Eliot Miranda wrote:
> Lloyd Linklater wrote:
>> Java's speed comes largely from its pre-compiling. It was quite slow
>> in the early days. Is Ruby likely to get such a boon in the
>> foreseeable future? That would certainly be something that pointy
>> haired managers could boldly hold forth in meetings for consideration.> Um, no. Java's speed comes principally from
> a) its non-object numeric types, and
> b) from sophisticated VMs that do adaptive optimization (see Sun HotSpot
> Server VM)> If by precompiling you mean compiling to bytecode then, no, this won't
> of itself give great speed. Java as always compiled to bytecode but the
> early Sun reference VM - a bytecode interpreter - was still slow. It's
> easy to write slow bytecode interpreters. YARV for Ruby is currently
> also a slow bytecode interpreter.This is precisely why we've been able to get very good performance in
JRuby. Though we still have an interpreted mode, which runs slower than
Ruby 1.8, we also have a nearly complete Ruby-to-JVM-bytecode compiler
that executes consistently faster than Ruby 1.8 and in some cases faster
than Ruby 1.9. In general, the difficult task has been structuring the
bytecode and the call pipeline in such a way as to allow HotSpot to do
its optimization.This also means that Java and JRuby and similar adaptive optimizing
runtimes require some "warm-up time". Java code will get faster as it
executes, but for short benchmarks it will usually be much slower than
its full potential. The same applies to JRuby, and as a result JRuby
will be better for longer-running processes (unless, of course, you
don't mind it being a little slow early on).
I meant faster as in executing I guess. If you see I just posted a
question relating to a 2D MMORPG game / maker. I'd like the game to be
fast and not necessarily faster coding wise. Thanks for the feedback.
···
--
Posted via http://www.ruby-forum.com/.
I remember when Tcl became popular in the early 90's. On the performance
issue, John Ousterhout, Tcl's creator, argued that its performance was
actually very good, because you would write very few lines of Tcl and most
of the work would be done by the underlying compiled-code implementation.
Indeed, Tcl scripts are very succinct.
I suspect the same could be true in Ruby. Because Ruby code tends to be more
succinct than Java code, there is potentially greater room for optimization
(ignoring other issues due to language differences...), as less time needs
to be spent in the "interpretation of characters". Just a thought...
dean
···
On 8/26/07, Terry Poulin <bigboss64@ippimail.com> wrote:
...
My experience with Java is roughly a decade out of date.... But in my
opinion
Java has a good *design* on a number of things but is to verbose and
annoying
to be *great* language. I've always found the common 'Hello world!'
programs
most language introductions start with as a good way to see just how much
typing is expected for small tasks. I remember when I first started Java,
I
thought system.out.println() was nicely arranged but so much more typing
then
printf(). I learned a lot through studying Java but did my darn'st to
_not_
write any Java programs.I've found Ruby to be a very good balance for many things. While it might
not
be the fastest on execution time but it makes a tremendous improvement in
the
amount of time spent testing and debugging code. Even if you just chalk it
off
to less lines of code needed for more complex tasks, Ruby is more
efficient
for a lot of things. Things that are hard to do in Ruby or proof to much
of a
bottleneck. Can be moved into a C Extension; if neccessary & you know how,
optimised at a lower level then Ruby as well. C is beautiful, Ruby is
Effective, together they are probably awesome in some ways xD
...
--
Dean Wampler
http://www.objectmentor.com
http://www.aspectprogramming.com
http://aquarium.rubyforge.org
http://www.contract4j.org
Isaac Gouy wrote:
I'm a bit confused about what you might mean, help me understand.
Absolutely!
Do you mean small benchmark programs will be "much slower" when run
once rather than run 100 times? How much slower - 0.1x 10x 1000x ?
A description of JRuby internals will help here.
JRuby starts running almost all code in interpreted mode right now. This is partially because the compiler is incomplete, and can't handle all syntax, but also partially because parsing + compilation + classloading costs more than just parsing, frequently so much more that performance gains during execution are outweighed.
So JRuby currently has the bytecode compiler in JIT mode. As methods are called, the number of invocations are recorded. After a certain threshold, they are compiled. We do not do any adaptive optimization in the compiler at present, though we do a few ahead-of-time optimizations by inspecting the AST. Compiled code does not (with very few exceptions) ever deoptimize.
Because of the JRuby JIT, we must balance our compilation triggers with the JVMs. Ideally, we get things compiled quickly enough for HotSpot to take over and make a big difference without compiling *too many* methods or compiling them too frequently and having a negative impact on performance.
Do you mean we should not assume small program performance is a
reasonable estimate of large program performance?
It depends how small. For example, if the top-level of a script includes a while loop of a million iterations, it will not be indicative of an app that has such loops in methods, as part of an object model, and so on, because that top-level may not ever compile to bytecode (since it's only called once) or may only execute once and never be JITed by the JVM. Soon, when the compiler is complete, we could theoretically compile scripts on load, but it remains to be seen if that will incur more overhead than it is worth. And it still wouldn't solve the problem of long-running methods or scripts that are only invoked once.
As an example, try running the two following scripts in JRuby and comparing the results:
SCRIPT1:
t = Time.now
i = 0
while i < 10_000_000
i += 1
end
puts Time.now - t
t = Time.now
i = 0
while i < 10_000_000
i += 1
end
puts Time.now - t
t = Time.now
i = 0
while i < 10_000_000
i += 1
end
puts Time.now - t
t = Time.now
i = 0
while i < 10_000_000
i += 1
end
puts Time.now - t
t = Time.now
i = 0
while i < 10_000_000
i += 1
end
puts Time.now - t
SCRIPT2:
def looper
i = 0
while i < 10_000_000
i += 1
end
end
5.times {
t = Time.now
looper
puts Time.now - t
}
My results:
SCRIPT1:
9.389
9.194
9.207
9.198
9.191
SCRIPT2:
9.128
9.012
2.001
1.822
1.823
This is fairly typical. And this also should be of interest to you for the alioth shooutout benchmarks; simply re-running the same script in a loop will not allow JRuby or HotSpot to really get moving, since each run through the script will define *new* classes and *new* methods that must "warm up" again. You must leave the methods defined and re-run only the work portion of the benchmark.
Incidentally, I don't think "warm-up time" works as a description of
adaptive optimization - it makes it sound like a one-time-thing,
rather than continual profiling decompilation recompilation adapting
to the current hotspot.
In our case, it's a bit of both. There's some warm-up time for JRuby to compile to bytecode, and then there's the adaptive optimization of HotSpot which is a bit of a black box to us. We are working to reduce JRuby's warm up time to get HotSpot in the picture sooner.
- Charlie
*shudder*
···
On Thu, Aug 30, 2007 at 03:20:11AM +0900, r wrote:
On Aug 26, 7:51 am, Nick Nick <schaefe...@gmail.com> wrote:
> Which programming language is faster - Ruby or Java?
>
> This is one of the things that will decide whether I use Ruby or Java so
> help is appreciated greatly.
>Decisions are hard... don't know what you're programming, but Java
plain sucks for web apps.As for Ruby and web apps--it's 9 months later...had the training got
the t-shirt, still not doing Ruby or Rails...how long can one carry a
suitcase...?I don't get paid for anything but web apps, and other enterprise
stuff. So I can't say about other types of programs.I for one am very tired of wanting to use Ruby for webapps...can't
believe I wasted 9 months downloading all this crap...rm -rf ~home/ruby-stuff
cd /usr/local/Zend/htdocs
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Leon Festinger: "A man with a conviction is a hard man to change. Tell him
you disagree and he turns away. Show him facts and figures and he questions
your sources. Appeal to logic and he fails to see your point."
have you considered Ada for this job? It's even faster and clearer than
Java, and it has such features like builtin Tasks.
-Thomas
···
On 26/08/07, Nick el <schaefer88@gmail.com> wrote:
I meant faster as in executing I guess. If you see I just posted a
question relating to a 2D MMORPG game / maker. I'd like the game to be
fast and not necessarily faster coding wise. Thanks for the feedback.
--
Thomas Preymesser
thopre@gmail.com
thomas@thopre.com
030- 49 78 37 06
0176 - 75 03 03 04
Assembly is faster than
C is faster than
Java is faster than
Ruby is faster than
JavaScript in a Web Browser
You could develop in any of these. You need to decide: how fast does
it really need to be?
You want it to run 'fast'.
How do you know that both Ruby and Java are not both too slow?
How do you know that both Ruby and Java are not both way fast enough?
···
On Aug 26, 6:16 am, Nick el <schaefe...@gmail.com> wrote:
I meant faster as in executing I guess. If you see I just posted a
question relating to a 2D MMORPG game / maker. I'd like the game to be
fast and not necessarily faster coding wise. Thanks for the feedback.
Nick el wrote:
I meant faster as in executing I guess.
Look up "premature optimization is the root of all evil".
When you pick a language that's repulsively hard to program, just because a newsgroup said it's faster in general, that's an example why premature optimization is the root of all evil. You will program slower, hence you will have less time in your schedule to profile and determine the real slow spots. Programmers should write clear code (in a clear language) and never try to guess what will be slow. It's easier to make clear code fast than make fast code clear.
If you see I just posted a
question relating to a 2D MMORPG game / maker. I'd like the game to be
fast and not necessarily faster coding wise. Thanks for the feedback.
Games have two layers. The lower layer, the graphics rendering engine, should be written in a C language, and it should directly access hardware. The upper layer should be in a soft language, for scripting the game events.
You probably want to write the upper layer and reuse one of the existing lower layers, such as SDL (IIRC) or OpenGL. So use Ruby for the upper layer, because it makes scripting tasks very easy. Much of Ruby development consists of building and using "Domain Specific Languages" that are easy to read and write. Your top layer could be as clear as "orc.attack(hobbit)".
Because only one line of upper layer code needs to run for every ten thousand lines of lower layer code, the performance of the upper layer is less important. If you have any further constraints, such as a small footprint, or a very big upper layer, you could split the difference and use Lua. It's harder to program than Ruby but much easier than Java, and its speed can compete with C.
···
--
Phlip
Test Driven Ajax (on Rails) [Book]
"Test Driven Ajax (on Rails)"
assert_xpath, assert_javascript, & assert_ajax
Now my impression is that I misunderstood how different JRuby
characteristics are from Java. I suspect that whenever you mention
"adaptive optimization" or HotSpot, I'll get confused about what JRuby
is actually doing (and in-any-case JRuby is going to be doing things
differently in future).
You should know better than to post code snippet timings 
What if you have:
t = Time.now
looper
puts Time.now - t
t = Time.now
looper
puts Time.now - t
...
...
...
As for the alioth shootout / benchmarks game, we don't re-run in a
loop because Clean and Haskell compilers notice that once around the
loop is enough to get the answer
(When we poked at JVM in the FAQ, the "started once" examples are just
like your SCRIPT2 - main renamed test, and called within a timing
loop.)
···
On Aug 29, 11:53 am, Charles Oliver Nutter <charles.nut...@sun.com> wrote:
Isaac Gouy wrote:
> I'm a bit confused about what you might mean, help me understand.Absolutely!
> Do you mean small benchmark programs will be "much slower" when run
> once rather than run 100 times? How much slower - 0.1x 10x 1000x ?A description of JRuby internals will help here.
JRuby starts running almost all code in interpreted mode right now. This
is partially because the compiler is incomplete, and can't handle all
syntax, but also partially because parsing + compilation + classloading
costs more than just parsing, frequently so much more that performance
gains during execution are outweighed.So JRuby currently has the bytecode compiler in JIT mode. As methods are
called, the number of invocations are recorded. After a certain
threshold, they are compiled. We do not do any adaptive optimization in
the compiler at present, though we do a few ahead-of-time optimizations
by inspecting the AST. Compiled code does not (with very few exceptions)
ever deoptimize.Because of the JRuby JIT, we must balance our compilation triggers with
the JVMs. Ideally, we get things compiled quickly enough for HotSpot to
take over and make a big difference without compiling *too many* methods
or compiling them too frequently and having a negative impact on
performance.> Do you mean we should not assume small program performance is a
> reasonable estimate of large program performance?It depends how small. For example, if the top-level of a script includes
a while loop of a million iterations, it will not be indicative of an
app that has such loops in methods, as part of an object model, and so
on, because that top-level may not ever compile to bytecode (since it's
only called once) or may only execute once and never be JITed by the
JVM. Soon, when the compiler is complete, we could theoretically compile
scripts on load, but it remains to be seen if that will incur more
overhead than it is worth. And it still wouldn't solve the problem of
long-running methods or scripts that are only invoked once.As an example, try running the two following scripts in JRuby and
comparing the results:SCRIPT1:
t = Time.now
i = 0
while i < 10_000_000
i += 1
end
puts Time.now - t
t = Time.now
i = 0
while i < 10_000_000
i += 1
end
puts Time.now - t
t = Time.now
i = 0
while i < 10_000_000
i += 1
end
puts Time.now - t
t = Time.now
i = 0
while i < 10_000_000
i += 1
end
puts Time.now - t
t = Time.now
i = 0
while i < 10_000_000
i += 1
end
puts Time.now - tSCRIPT2:
def looper
i = 0
while i < 10_000_000
i += 1
end
end5.times {
t = Time.now
looper
puts Time.now - t}
My results:
SCRIPT1:
9.389
9.194
9.207
9.198
9.191SCRIPT2:
9.128
9.012
2.001
1.822
1.823This is fairly typical. And this also should be of interest to you for
thealiothshooutout benchmarks; simply re-running the same script in a
loop will not allow JRuby or HotSpot to really get moving, since each
run through the script will define *new* classes and *new* methods that
must "warm up" again. You must leave the methods defined and re-run only
the work portion of the benchmark.> Incidentally, I don't think "warm-up time" works as a description of
> adaptive optimization - it makes it sound like a one-time-thing,
> rather than continual profiling decompilation recompilation adapting
> to the current hotspot.In our case, it's a bit of both. There's some warm-up time for JRuby to
compile to bytecode, and then there's the adaptive optimization of
HotSpot which is a bit of a black box to us. We are working to reduce
JRuby's warm up time to get HotSpot in the picture sooner.- Charlie
Remember, hardware is cheap, software is hard, and time is money.
The bulk of your system might be serverside - Go to your local computer recycling shop and get a decent computer, then trick it out.
If you find your game might not be fast enough then, start grinding the database where the data is stored - thats what they're meant for.
If you code in Ruby, you will find that troubleshooting and just plain old coding will be tons easier.
Good luck,
---------------------------------------------------------------|
~Ari
"I don't suffer from insanity. I enjoy every minute of it" --1337est man alive
···
On Aug 26, 2007, at 10:30 AM, Phrogz wrote:
On Aug 26, 6:16 am, Nick el <schaefe...@gmail.com> wrote:
I meant faster as in executing I guess. If you see I just posted a
question relating to a 2D MMORPG game / maker. I'd like the game to be
fast and not necessarily faster coding wise. Thanks for the feedback.Assembly is faster than
C is faster than
Java is faster than
Ruby is faster than
JavaScript in a Web Browser
Phrogz>
Assembly is faster than
A monk once asked ruby-talk: "Which programming language is faster -
Ruby or Java?" Ruby-talk said: "MOV".
Sorry, can't resist.
···
--
I. P. 2007-08-26T20:01
-snip-
... and use
Lua. It's harder to program than Ruby but much easier than Java, and its
speed can compete with C.
Compete and lose.
"Lua is a tiny and simple language, partly because it does not try to
do what C is already good for, such as sheer performance, low-level
operations, or interface with third-party software. Lua relies on C
for those tasks."
Preface xiii, Programming in Lua
···
On Aug 26, 7:56 am, "Phlip" <phlip2...@gmail.com> wrote: