Profiling avian emulator

[Patrick]

Hi Joel & Joshua,

I am working on a platform specializing in emulation and have run into a significant bottleneck where it runs more than 5 times as slow as native code.

I am using a port of the dosbox emulator I wrote to test the features. I have uploaded my code to https://github.com/byte4byte/ECDOS .

How should I go about profiling this, are there any tools I can use to see where I can improve performance? 

I literally have to run with CPU_CycleMax set to 500 for it to be remotely playable on my macbook air. https://github.com/byte4byte/ECDOS/blob/master/ECDOS/ECDos.java line 118.

Cycles can be adjusted during playtime with plus and minus keys for testing.

I have both OSX and Windows version of emucater for testing in the github repo. Just launch the app click "Now Playing" and ZZT will boot up.

I really need some assistance with this and hope the 2 of you can point me in the right direction.

Thanks,

Patrick

[Joel Dice .]

Hi Patrick,

I would recommend writing a simple sampling profiler that calls
Thread.getStackTrace on the emulator thread(s) every 10ms or so and
stores the results in a HashMap that maps stack traces to the number
of times they are encountered. Then you can dump the results to a
text file or standard output, ranking them by frequency to determine
where the emulator is spending most of its time. You can also process
the map to generate statistics about which methods the emulator is
spending the most time in. I wrote something like that a while ago;
I'll dig around and try to find it.

> --
> You received this message because you are subscribed to the Google Groups
> "Avian" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to avian+un...@googlegroups.com.
> To post to this group, send email to av...@googlegroups.com.
> Visit this group at https://groups.google.com/group/avian.
> For more options, visit https://groups.google.com/d/optout.

[Patrick]

Hey Joel,

I wanted to see if it was the jvm so a created a version that runs in Oracle's JVM: https://github.com/byte4byte/ECDOS_oracle and it runs smoking fast. NO difference between it and native dosbox. Simple "java -jar ECDOS.jar" in the Oracle folder to see.

It's not completely Apples to Apples comparison however since I've trimmed down the ECDK api to use Swing to display a window and display the rendered content using java.awt.image.BufferedImage.

So my question is, can I test this jar with avian.exe since it's using swing and awt to create a window and display an image?

I would like to see how the avian jvm stacks against Oracles'. If it performs the same or better it would tell me that it's the ECDK api that's causing the bottleneck as it goes into native code using JNI and uses OpenGL ES 2 to render content.

[Patrick]

Update:

I have created a headless version of dosbox: https://github.com/byte4byte/ECDOS_headless in order to test avian vs oracle vm

The results are:

Oracle:

java -jar ECDOS.jar

Rendered 10000 frames in: 142 secs

Avian:

./avian -jar ECDOS.jar

Rendered 10000 frames in: 252 secs

Avian performed significantly slower than Oracles vm. 

Joel are there any plans on increasing performance of avian? I would really like to use avian since it's so lightweight and portable but it's currently not usable in the product i'm working on.

I think oracle's vm inlines small methods that are declared  final, perhaps that is one of the places where avian could be improved?

[Steve Hannah]

Frankly, those results look pretty good.  Oracle's VM is very fast, and can use JIT to optimize frequently used code paths.  Probably your benchmark uses a few code-paths over and over again - and this will significantly skew the results in favour of a JIT.  I find it unlikely you'll find an AOT compiled solution that can compare.  1.77 times slower is not that bad of a result.

To unsubscribe from this group and stop receiving emails from it, send an email to avian+unsubscribe@googlegroups.com.

To post to this group, send email to av...@googlegroups.com.
Visit this group at https://groups.google.com/group/avian.
For more options, visit https://groups.google.com/d/optout.

--

Steve Hannah

Web Lite Solutions Corp.

[Joel Dice .]

On Wed, Jan 4, 2017 at 10:07 AM, Patrick <pat...@byte4byte.com> wrote:
> Avian performed significantly slower than Oracles vm.

Like Steve said, I'm actually surprised Avian did that well,
considering it is ten times simpler and ten times dumber than HotSpot
:)

> Joel are there any plans on increasing performance of avian? I would really
> like to use avian since it's so lightweight and portable but it's currently
> not usable in the product i'm working on.

Sorry, no. I once had ambitions to rewrite the JIT compiler to allow
more advanced optimizations, but never had enough time or incentive to
follow through with it. Also, a big part of the reason Avian is so
lightweight is that it doesn't do those advanced optimizations. I'm
sure it's possible to make it faster without making it significantly
bigger and more complicated, but I don't know of any simple,
incremental improvements.

> I think oracle's vm inlines small methods that are declared final, perhaps
> that is one of the places where avian could be improved?

ProGuard might be useful here, since it can do that kind of thing
ahead of time at the bytecode level. You could also do manual,
source-code level inlining on a hot path in your app to see if it
makes a significant difference.

BTW, I wasn't able to find the profiler I mentioned in my last email,
but this one was written by my friend Mike and is loosely based on the
quick-and-dirty one I wrote a long time ago:
https://github.com/threadly/threadly/blob/09e72cbd9b3f1a3f0264d0e8f797e3ebe23decd6/src/main/java/org/threadly/util/debug/Profiler.java.
Perhaps you'll find it useful.