Replacing SM with Rhino
celso
APIs are different, of course, but we'd achieve better Java integration
and apparently speed. I read somewhere Rhino can be faster 10:1 in some
benchmark tests, using JIT compilation (not sure here if 10:1 refers
to Rhino X SM or RhinoJIT X RhinoNoJIT). What would the major issues
involved be?
Thanks for your attention,
Celso
Matthew Mondor
I'm no definitive authority about this, but I'm rather confident that
this was comparing Rhino with a JIT and without one... I would be fairly
surprised if Java performance reached that of compiled C programs
(except perhaps in cases of very bad programming).
The gap between Java and C sure decreased, but it's not yet reaching the
same speeds in most cases (and although I often saw claims that it's
starting to reach comparable performance to C++ in some cases with a
JIT, well written C programs still yield better performance than C++
ones which need more runtime checks to implement the language.
Possibly that with Jazelle and an arm processor that has Java bytecode
support, applications written in C++ and Java could run with similar
performance however... Although I couldn't test this yet personally
If Rhino with a JIT exceeds SpiderMonkey performance, I sure would like
to also know why, as well as the particular code used to test the
benchmarks
celso
I was referring to the two topics in this same newsgroup, titled:
"newbie questions about porting JS to embedded processor"
"Whats about a JIT?"
I believe this was a JIT X NoJIT comparison also.
I'm getting roughly a 3:1 SM advantage over RhinoNoJIT using
BenchPress.js (included in mozilla/js/benchmarks sources).
Does that mean RhinoJIT is about 3:1 faster than SM (if the
10:1 ratio holds true)?
How do you get Rhino to use JIT?
Thanks again,
Celso
Matthew Mondor
"celso" <celso...@hotmail.com> wrote:
> I was referring to the two topics in this same newsgroup, titled:
> "newbie questions about porting JS to embedded processor"
> "Whats about a JIT?"
Hmm I couldn't find those articles on the news server, tried MARC for an
archive but although they do have mozilla related mailing lists, they
don't have mozill...@mozilla.org one... However after I wrote the
last message I started wondering about which JIT compiler:
If you're speaking of a JIT for Java, and that Rhino runs under that,
it's unlikely to be faster... If speaking of a Rhino JIT implementation,
which then runs under a Java implementation with a JIT, that could
probably reach impressive results however... Doing this in C is
difficult since JIT code becomes hardware-dependent, and will require
architecture specific assembly and the like... However, a JS JIT could
be made in Java, outputting portable Java bytecode, which then would be
executed using the architecture specific Java JIT which already exists,
I guess
I didn't use Rhino and can't say if it has such JIT to Java bytecode,
other Rhino users here will surely help better about this than I can
Matt
Igor Bukanov
>>Has anyone tried or done this before in their embedding/application.
>>APIs are different, of course, but we'd achieve better Java
>>integration and apparently speed. I read somewhere Rhino can be faster
>>10:1 in some benchmark tests, using JIT compilation (not sure here if
>>10:1 refers to Rhino X SM or RhinoJIT X RhinoNoJIT). What would the
>>major issues involved be?
>
>
> I'm no definitive authority about this, but I'm rather confident that
> this was comparing Rhino with a JIT and without one... I would be fairly
> surprised if Java performance reached that of compiled C programs
> (except perhaps in cases of very bad programming).
Note that comparing Rhino performance vs SpiderMonkey performance is not
the same as comparing a general C program with a general Java program.
Here you compare the performance of JavaScript code compiled to a custom
bytecode and interpreted using C engine versus performance of JavaScript
compiled to JVM classes and run through modern JVM.
In general for various benchmarks SpiderMonkey runs faster then Rhino
under JDK 1.4 by a factor around 1.2 - 1.5 or so although there are
cases where Rhino beats SpiderMonkey by some margin.
Rhino can also generates a custom bytecode and directly interprets it.
This is useful to avoid problems that arise when using ClassLoader in
Java (like memory leaks etc.) and speedup loading of small scripts. In
this case Rhino lags behind SpiderMonkey by factor up to 5-10. Java
simply is not suitable for writing high performance interpreters due to
lack of necessary language constructs.
But all this is relevant only if you use JavaScript to code a lot of
calculations or complex search algorithms. If JavaScript is used to glue
native objects then you would not see those performance differences at all.
> ...
> If Rhino with a JIT exceeds SpiderMonkey performance, I sure would like
> to also know why, as well as the particular code used to test the
> benchmarks
See, for example, https://bugzilla.mozilla.org/show_bug.cgi?id=121414#c57
Regards, Igor
celso
> On 12 Jan 2005 23:54:38 -0800
> "celso" <celso...@hotmail.com> wrote:
>
> > I was referring to the two topics in this same newsgroup, titled:
> > "newbie questions about porting JS to embedded processor"
> > "Whats about a JIT?"
>
> Hmm I couldn't find those articles on the news server, tried MARC for
an
> archive but although they do have mozilla related mailing lists, they
> don't have mozill...@mozilla.org one...
Do a search in google groups and I'm sure you'll find:
http://groups-beta.google.com/group/netscape.public.mozilla.jseng
> However after I wrote the
> last message I started wondering about which JIT compiler:
>
> If you're speaking of a JIT for Java, and that Rhino runs under that,
Yes, I was referring to a JIT for Java, Sun's in particular.
> it's unlikely to be faster... If speaking of a Rhino JIT
implementation,
> which then runs under a Java implementation with a JIT, that could
> probably reach impressive results however... Doing this in C is
> difficult since JIT code becomes hardware-dependent, and will require
> architecture specific assembly and the like... However, a JS JIT
could
> be made in Java, outputting portable Java bytecode, which then would
be
> executed using the architecture specific Java JIT which already
exists,
Interesting!
celso
I got similar results to what you describe.
Below are runs for BenchPress.js, speed.js
and all_bench.js. I did 3 runs for each test
on each engine, took the average, calculated
the ratio, with SM as reference (1).
Rhino JIT beat SM in only one case (BenchPress.js)
and not in a ratio enough to warrant engine switch.
I used jdk1.5.0_01 for Rhino latest, SM also latest.
Thanks,
Celso
engine test r1 r2 r3 avg ratio
----------------------------------------------------------
SpiderMonkey BenchPress.js 562 517 531 536 1
Rhino BenchPress.js 1311 1327 1330 1322 2.466
Rhino JIT BenchPress.js 404 500 405 436 0.813
----------------------------------------------------------
SpiderMonkey speed.js 1.406 1.454 1.391 1.417 1
Rhino speed.js 4.016 3.906 3.828 3.916 2.763
Rhino JIT speed.js 2.531 2.531 2.531 2.531 2.531
----------------------------------------------------------
SpiderMonkey all_bench.js 18390 20891 25250 21510 1
Rhino all_bench.js 32718 32546 31843 32369 1.504
Rhino JIT all_bench.js 28499 28686 28484 28556 1.327
----------------------------------------------------------
celso
----------------------------------------------------------
SpiderMonkey BenchPress.js 562 517 531 536 1
Rhino BenchPress.js 1311 1327 1330 1322 2.466
Rhino JIT BenchPress.js 404 500 405 436 0.813
----------------------------------------------------------
SpiderMonkey speed.js 1.406 1.454 1.391 1.417 1
Rhino speed.js 4.016 3.906 3.828 3.916 2.763
Rhino JIT speed.js 2.531 2.531 2.531 2.531 1.786
----------------------------------------------------------
SpiderMonkey all1_bench.js 18390 20891 25250 21510 1
Rhino all1_bench.js 32718 32546 31843 32369 1.504
Rhino JIT all1_bench.js 28499 28686 28484 28556 1.327
----------------------------------------------------------
celso
is to consider % of time independently for
each test to avoid assigning weights where
they don't or should not exist. Also, some
of the tests were yielding less than 1 ms
results, which didn't mean much (they were
probably done for computers slower than what
they are today). In this case SM comes out
faster, close to what was described before
by Igor.
Thanks,
Celso
Benchpress(v3) in JavaScript...
benchmark time (ms) % time
Engines-> SM R-JIT SM R-JIT
AtAllPutBenchmark 31 78 0.284 0.715
BounceBenchmark 15 94 0.137 0.862
BubbleSortBenchmark 235 172 0.577 0.422
IncrementAllBenchmark 62 93 0.4 0.6
MMIntBenchmark 16 32 0.333 0.666
MMFloatBenchmark 15 31 0.326 0.673
NestedForLoopBenchmark 219 156 0.584 0.416
NestedWhileLoopBenchmar 250 156 0.615 0.384
PermBenchmark 125 157 0.443 0.556
QueensBenchmark 78 93 0.456 0.543
QuicksortBenchmark 78 79 0.496 0.503
RecurseBenchmark 110 156 0.413 0.586
SieveBenchmark 125 78 0.586 0.384
StorageBenchmark 62 78 0.442 0.557
SumAllBenchmark 32 47 0.405 0.594
SumFromToBenchmark 234 203 0.535 0.464
TakBenchmark 250 203 0.551 0.448
TaklBenchmark 1891 953 0.664 0.335
TowersBenchmark 421 485 0.464 0.535
TreeSortBenchmark 141 250 0.36 0.639
total 4390 3594 9.07 10.88
ratio 1 1.2