[ruby-talk:15815] Re: java based interpreter and regexes

Sean Russell <[e-mail]> wrote:

>If this true, the 1.4 VM is literally an order of magnitude faster than the
>1.3 VM, or else the Windows VM is a better implementation than the Linux
>VM.  I find this last option a bit odd, because IBM's 1.3 VM for Linux was 
>supposed to be the fastest for non-GUI apps, although I last checked this
>several months ago.
>
>How does the 1.4 VM perform memory-wise?  The 1.3 VM is a memory hog under
>Linux.

1.4 should be at least as fast as 1.3, it might include some debug
code as it's still a beta.  I've heard reports both that 1.4 is
significantly faster and slower than the 1.3.1 production release.

>> I've only GCC available.  Wait, I've also RubyWin (based on version
>> 1.6.2 I think).  It takes 3.5s for the benchmark.
>
>Wow.  25% faster.  Not bad, but this still doesn't account for the Java
>regex package being two to four times as fast as the Ruby version.

However, if the RubyWin version is faster than the GCC version, this
probably means either that VC++ is a better compiler than GCC on
Windows or that the GCC isn't using the best compiler optimization
flags.

>Yes, and no.  Swing is comparatively slow, no matter what you do.

But this isn't a problem of the Java VM but of the Swing and AWT
architecture.  Erich Gamma (of Pattern fame) used to give talks about
this topic, explaining the problems and talking about why OTI has
chosen a different strategy for their VisualAge product line.

The main reason is the way AWT interacts with the host os.  Sun is
slowly fixing this problem, but the problem is the event queue and how
damage events are propagated.

>Yes, everything you say is true.  It does get into the larger discussion of
>comparing apples to apples (OO to OO), but I'm still confused about your
>results which indicated that interpreted OO code is faster than native 
>functional code.

Java isn't interpreted.

>> GC, done right, is faster than the typical manual malloc/free memory
>> management, especially if we're talking about millions of small
>> objects.
>
>Yeah, but we aren't.  We're talking about a single, tight loop on static
>stringes.

Java is performing 28 GCs while running the benchmark (spending some
60 ms in GC), reducing the heap each time by 500 KB.  This means, if I
understand the statistics, the benchmark is generating and throwing
away objects worth of 14 MB.  I'd guess that's some 300.000 objects.

So don't assume there're no objects involved :-)

>On the other hand, Ruby uses GC as well... is Ruby's GC
>mechanism more efficient than Java's?

Definitely not!  Ruby, I think, uses a simple Mark&Sweep GC.  Hotspot
eventually uses a modern generation scavenger type of GC.  This is a
complex beast combining the best features of Stop&Copy and
Mark&Compact algorithms together with special treatment for
short-lived and long-lived objects.  I'm not sure, whether Java's GC
is also incremental (like the GCs of good Smalltalk and LISP systems).
I think, it's an optional feature for Java which still slightly
decreases performance.

>I'd like to see some other, more complete benchmarks of Ruby vs. Java,
>particularly of Ruby methods which are known to be implemented in native
>code.

Me too.

>Thanks for the discussion, Stefan.

You're welcome.  It's fun.

bye
-- 
Stefan Matthias Aust \/ Truth Until Paradox