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

[Many replies to multiple emails on this thread in one easy-to-delete
 message!]

Glen> Unless we would be seeking 100% Java certification, there is 
Glen> nothing stopping us from using JNI and creating native regex 
Glen> libraries for each supported platform. It's very, very ugly, 
Glen> but certainly could be done.        

Stefan> Sure, it could be done.  But my dream would be an easy-to-deploy
Stefan> single jar distribution which could be droped on any platform we
Stefan> like...

I agree.  I think this is the most compelling reason to write a Java
Ruby interpreter, and I dislike the idea of "polluting" the Java version
with JNI; if I'm going to have to recompile the Java-based interpreter,
I might as well use the original C source.

Don't get me wrong; I have nothing against a Java implementation as an
intellectual exercise; it just wouldn't benefit *me* much ;-)

Stefan> Hi Sean,

Hi Stefan :-)

> >Hm.  I was comparing Ruby 1.6.4 against IBM's Java 1.3 on Linux.
> >My benchmarks were from my office computer (200Mhz CPU 128Mb RAM).
> 
> I was using a PII 450 with 256 MB running Windows 98.
> 
> >Java runtime: 14.794s	(Sun's JDK 1.3 w/ Hotspot)
> >Java runtime: 15.070s	(IBM's JDK 1.3)
> >Ruby runtime:  4.707s	(Ruby 1.3)
> 
> Funny, we get nearly the same time for Ruby even if my system should
> be twice as fast as yours.  I compiled my Ruby on cygwin with whatever
> "configure; make; make install" sets (-g -O2).

I apologize; I wasn't clear.  The benchmarks I had posted earlier were from
my 200MHz office machine; these benchmarks were posted from my 400MHz, 256MB
home machine.

> Please note that I was using java 1.4 which is known to be slower on
> the startup.  Whatever, I also can't really believe the measured
> result.

Well, Benoit's results match yours, although it looks as if his machine
configuration is nearly identical to yours (same CPU, same VM, etc).

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.

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

> As I wrote, I think it's based on the jakata project's (apache) regex
> package.  Just check out the hyperlink I posted.

I did (thanks for the link), but I didn't do a lot of reading about the
new package.  I'll have to do that in a year or so, when I have more free
time :-)

> >The reason that Java hasn't become the defacto application language is 
> >primarily because of the speed issue (IMO).
> 
> I'd say it's also because most people (including some developers at
> Sun) don't know how to write fast OO applications, but that's a
> different topic :-)  

Yes, and no.  Swing is comparatively slow, no matter what you do.  I do
agree that non-GUI Java apps perform really well.  I wish something could
be done about Swing, though.

> The papers about the SELF project are very interesting to read.  Don't
> get me wrong, a good static compiler can do amaizing things, but only
> for static programs.  They often fail on dynamic object-oriented

Ah.  Yes, you are completely right.

> languages.  Don't compare static C programs with more dynamic
> object-oriented solutions.  The goal is to make these programs to run

I was doing this comparison because we were talking about Java regex vs.
Ruby regex, and I was under the impression that the Ruby regex package
was written in C, not C++.  Further, the loop in the benchmark was tight,
and I expected most of the time to be spent in the regex match (IE, static
C code), not in interpreted OO Ruby code.

> could be true.  If you compare the programs with the same semantic,
> Java isn't slow.  Don't make the mistake to compare an unchecked array
> access with Java's checked access.  I always want the security to
> never get any buffer overrun error (security problem number one in the
> C-based server world!) and only the JIT is allowed to remove the check
> if it can prove that the array bounds are never violated.

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.

> 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.  Although, Benoit's results on a larger itteration, which narrows
the gap between Java 1.4 and Ruby runtimes, illustrate the garbage collection
point.  At 10,000 itterations, the Java code probably wasn't getting a chance
to invoke GC.  On the other hand, Ruby uses GC as well... is Ruby's GC
mechanism more efficient than Java's?

> I'd really like to see somebody else to try the benchmark using JDK
> 1.4 and checking whether I made a mistake.

I don't think you did, and Benoit's benchmarks prove this.

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.

Thanks for the discussion, Stefan.

--- SER