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

Hi Sean,

Sean Russell <[e-mail]> wrote:

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

>Interestingly, the VM initialization and other code overhead only added
>about another second on my machine, according to 'time'.

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.

>I'm *really* suspicious of this.  Have you tried compiling Ruby with a
>different compiler?

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.

>I'd also consider whether or not Sun's regex package 
>is as complex or complete as the Ruby (or even org.apache or gnu.regex) 

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

>I, too, agree with this statement, although speed *is* an issue.

Sure.

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

>>[dynamic recompilation based on type feedback can beat static optimization]

>I'd be willing to debate this point.  Most C compiler optimizing
>algorithms are highly tuned.

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
languages.  Don't compare static C programs with more dynamic
object-oriented solutions.  The goal is to make these programs to run
nearly as fast - without removing the dynamic.  SELF succeeded here.
Other languages like Dylan or Cecil also reaches this goal.  Even Java
can reach it as all technology is well known.  Sun has "just" to
implement it.  Hotspot is one important step here.

>Heuristic JIT compilers typically do a
>good job at making the JIT itself efficient by determining *what* to compile,
>but don't improve much on the basic optimizing algorithms themselves.

Well, they can and the will.  The best static compiler cannot inline
virtual methods, a dynamic recompiling system will.  It is able to
remove nearly all polymorphism from a program - but just behind the
scene.  It's no option to let the programmer do this (as in C++).

>Fundamentally, Java has a lot of overhead that slows things down.

All this is unfortunately off topic, but no, this is too general as it
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.

>Object allocation, garbage collection, 

GC, done right, is faster than the typical manual malloc/free memory
management, especially if we're talking about millions of small
objects.

>With most of the time (of this program) being spent in native code on the
>Ruby side, if we can prove that your benchmarks are not the result of a
>fluke (Cygwin is anti-optimizing, Sun is cheating by having the regex
>code in a native library, or some such nonsense)

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


bye
-- 
Stefan Matthias Aust \/ Truth Until Paradox