Re: Java execution acceleration

Software-based optimization works very well. Hotspot etc can makes use of
run-time context, and can perform some optimizations that cannot be easily
achieved by hardware or ahead-of-time optimization. On the other hand,
ahead-of-time software optimization can perform CPU-expensive optimizations
that could not be performed by Hotspot or hardware accelerometer. A high
quality optimizer that specialises in whole program optimization can
generate significant size reduction and/or performance boost. The three
techniques are complementary - however Terrance has a good point regarding
the economics. The economy of scale favours hotspot and ahead-of-time
software based optimization, unless you happen to be ARM :-)

Our alcheMo product family automates porting of J2ME applications/games to
native platforms. Our mBooster is the de-facto standard for J2ME app
optimization. They are both widely used, and therefore we are in a unique
position to be able to compare performance and other aspects with hard data.
Terrance is right - performance bottlenecks are typically not in bytecode
level. A good run-time library implementation or a better game/app design
are more likely to yield performance improvement, although without a doubt
native apps does generally run faster than J2ME apps. (I am not knocking
J2ME/JVM - any bytecode approach etc will have a performance penalty if
however slight in a typical mobile environment and there are significant
upsides to a bytecode approach too)

- Stephen


> -----Original Message-----
> From: A mailing list for KVM discussion [mailto:[email protected]]
> On Behalf Of [email protected]
> Sent: Friday, 13 June 2008 8:33 p.m.
> To: [email protected]
> Subject: Re: Java execution acceleration
> 
> Ah, difficult question ;-)
> 
> I don't have hard numbers but I believe the majority of mobile games are
> actually written in Java. Sometimes it's hard to tell as they look like
> native apps - especially the built-in games. I've found performance on
> most of these satisfactory or even excellent. It depends a lot on how the
> game is designed, There a still quite a few mobile developers out there
> who just don't fully understand the limitations they are working under and
> make poor design choices.
> 
> Native games sometimes are necessary if you want to use platform features
> that aren't accessible through Java APIs ... this is probably the majority
> of cases why one would go native. No doubt, there *are* situations where
> just need to squeeze every ounce of performance out of the device and/or
> the Java stack is not optimized well and that's the reason you go native.
> 
> Porting is another story. Yes, fundamentally, moving Java apps from one
> platform to another should be easy - it depends a lot on the range of
> devices you target and the features your require your app to have. Best
> case is it just runs. Worst case is you have to modify a significant part
> of your app. There is just too much variation in the mobile space to have
> a "one-size-fits-all" approach - which, at the same time, is also a
> strenght.
> 
> Of course, porting from say, Symbian to Windows Mobile, is another story
> altogether ;-)
> 
> -- Terrence
> [Message sent by forum member 'terrencebarr' (terrencebarr)]
> 
> http://forums.java.net/jive/thread.jspa?messageID=280120
> 
> ==========================================================================
> =
> To unsubscribe, send email to [email protected] and include in the
> body
> of the message "signoff KVM-INTEREST".  For general help, send email to
> [email protected] and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff KVM-INTEREST".  For general help, send email to
[email protected] and include in the body of the message "help".