Skip to main content

Poor performance of jwc 1.1.3, who can tell me why?

8 replies [Last post]
zhuzhiwei
Offline
Joined: 2007-04-24
Points: 0

JBenchmark JBenchmark2
jwc 1.1.3 + cldc 1.1.3 310 12
midp 2.0 ri + cldc 1.1 380 27

Generally, the first pair should earn a higher mark than the last one.But actually it dosen't, who can tell me why?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
strim
Offline
Joined: 2006-10-20
Points: 0

Hi Zhuzhiwei,

Please let us more details on the platform you have used to measure the
performance. The information about all JB, JB2 subsuite scores for RI
and MR1 correspondingly is very welcome as well, since it will help to
understand what particular functionality is involved.

A quick guess on possible slowdown reasons:

- JWC 1.1.3 could be built with options non-optimal for your platform,
many optimizations for one platform turn to be a pessimization for
another one
- RI has no UI skins, so UI suites of JB2 could work faster in RI
- ...

So, please get us more context for your comparison!
Thank you,
Regards,
Strim

zhuzhiwei
Offline
Joined: 2007-04-24
Points: 0

Test Result:
jbenchmark RI Platform JWC 1.1.3&CLDC 1.1.3
Text 89 80
2D Shapes 107 94
3D Shapes 73 49
Fill Rate 15 4
Animation 103 76
Total Score 387 310

jbenchmark2 RI Platform JWC 1.1.3&CLDC 1.1.3
Image manipulation 15 6
Text 48 33
Sprites 45 37
3D Transform 8 4
User interface 38 14
Total Score 26 15

In the above table we can see that no matter which item the socre we get on the jwc platform is smaller than that we get on the RI platform, it's confusing.

The equipment that we run javaME on is a STB(CPU=MIPS, OS=LINUX, Display resolution=640*526, CPU frequency = 200MHZ, RAM = 32M, Flash = 16M).The graphic and image system we all base on microwindow.

When compile the cldc1.1.3, we have:
export ENABLE_C_INTERPRETER = true
export ENABLE_INTERPRETER_GENERATOR = false
export ENABLE_COMPILER = false
export ENABLE_SOFT_FLOAT = true
export ENABLE_TIMER_THREAD = true
export BUILD_ANI_LIB := true
MERGE_SOURCE_FILES = true
SOURCE_MERGER_SIZE = 35

In the department of mobile of my company, they also encounter the same problem of poor performance, although their poting target is mobile.They have Sun's engineer helping their porting,but the performance is still not ideal.

Sorry for my poor English.

Many thanks for your repaly.

a_pangin
Offline
Joined: 2006-10-20
Points: 0

Hi Zhuzhiwei,

The results you see are quite expected though they do look depressing.
It is because you are using pure Java bytecode interpreter written in C language (ENABLE_C_INTERPRETER = true).
C interpreter in JWC 1.1.3 is not intended for production anyhow,
it was initially designed only for build system purposes (to run ROM generator on various platforms, e.g. SPARC). Although C interpreter is fully functional and TCK-compliant, it was never optimized for performance.
JWC (and phoneME Feature) is highly optimized for ARM processor families (including StrongARM, XScale etc.). It has fast interpreter loop written in assembler as well as
dynamic adaptive compiler (DAC) which makes the execution up to 5x times faster comparing to KVM.
Unfortunately phoneME Feature does not have either assembler interpreter nor DAC for MIPS platforms. The C interpreter can be used as a starting point for incremental porting of the whole VM infrastructure to a new platform.

zhuzhiwei
Offline
Joined: 2007-04-24
Points: 0

To a_pangin :

Really, we use the pure Java bytecode interpreter written in C language, because we haven't done the CPU porting.Is it the key of the problem?
If we want a better performance, we must complete the CPU porting and have a bytecode interpreter written in assembler, is it true?

According to you, byte interpreter written in assembler and dynamic adaptive complier seem to be the key improvements of the phoneME Feature, partly I aggree with you, but in the cldc porting guide, these aspects are just two comparing with the many improvements of the phoneME Feature.

Theoretically, byte interpreter written in assembler and dynamic adaptive complier are just parts of the improvements of JWC and phoneME Feature,so even if we don't complete these two parts we should still acquire a better performance, but actually we don't, that is what confusing me.

I appreciate your reply, many thanks.

a_pangin
Offline
Joined: 2006-10-20
Points: 0

Right, the bytecode compiler (DAC) is the key aspect of the phoneME Feature from VM side when comparing to Reference Implementation. It helps to achieve up to 500% run-time performance improvement on benchmarks.
At the same time phoneME Feature is not optimized for non-ARM devices at all from performance point of view

zhuzhiwei
Offline
Joined: 2007-04-24
Points: 0

To a_pangin:

Many thanks for your patient explanation.

Have you verified the up to 500% run-time performance improvement on benchmarks useing phoneME Feature?

May I have your MSN?If so, I will be very thankful.
Mine is zte-zhuzhu@hotmail.com

a_pangin
Offline
Joined: 2006-10-20
Points: 0

Right. You can find me in ICQ # 29309631

zhuzhiwei
Offline
Joined: 2007-04-24
Points: 0

Oh,it's a pity that I can only use msn in my office.