On Wednesday, 26 September 2012 08:01:07 UTC+1, Kristopher Micinski wrote: > > On Tue, Sep 25, 2012 at 9:22 PM, Ross Bamford > <[email protected]<javascript:>> > wrote: > > Hi, > > > > On Saturday, 23 June 2012 12:27:31 UTC+1, mame82 wrote: > >> > >> A first naive approach using luajava was far to slow for a method > called > >> about 5k times per frame. I need a way to compile to Dalvik bytecode at > >> runtime. > >> > >> Has anybody done sth like this, it seems impossible without the javac > >> class? > >> A scripting language supporting compilation to Dalvik DEX code would > also > >> help. > > > > Apologies for reviving an old thread. If you've already found a solution > to > > this, please ignore me :) > > > > We open-sourced Deelang, our lightweight in-app scripting language about > a > > year ago. Recently, I've been working on a native (i.e. DEX) compiler > for > > it. The compiler runs on-device and allows you to take script code and > > compile it a runtime-generated Class. Right now it's almost > feature-complete > > but only tested to the extent that we use it in-house. It may well work > for > > your needs? And in any case, more testers are always welcome ;) > > > > So I guess my question is, what does this provide over something say > like, Groovy, would that work on Android. >
AFAIK, Groovy doesn't work on Android at the moment? But in any case, the two are targeting different people - Deelang is very lightweight, and does not aim to be a complete scripting language. It's designed purely to provide the possibility for developers to provide scriptable "extension points" in their apps. This means it can be small (in terms of Jar size). > > Also, generating native != generating Dalvik bytecode, to me :-/ ... > that would be ... generating bytecode. > > You're right - I meant to put quotes around "native" there. My intention was to draw a comparison between "native" DEX bytecode versus the custom bytecode format and VM used in the original Deelang compiler. I am by no means claiming that this thing compiles directly to machine code. > > You'll find the project at http://deelang.googlecode.com/ . To get the > > native compiler, you'll need to check the DEXCOMPILER branch out of > > subversion (a file release is planned soon, but not yet). > > Hm... > > You might be surprised that generating Dex doesn't help you as much > here as you might think. Why? Because, let's say you're comparing > this with code that you have running through an interpreter (okay, so > you've converted your scripting language to a sort of intermediate > form or something beforehand like Lua intermediate..) Now, your > interpreter will run over this code in some systematic structure, and > your wanting to use Dex is because you can translate this into Dalvik > bytecode. > > But note! You will probably find that you will get "pretty good" perf > out of this interpreter (sans bytecode generation) already, because > Dalvik's (trace based) JIT will knock out "hot paths" of code along > your bytecode generation. > > I agree with your sentiment here - I've long been a proponent of not generating code purely for performances' sake. Some years ago I wrote a bytecode generation framework for Java (a project that was lost in the java.net changeover) and included with that was a warning about the perceived "benefits" of code gen with regard to performance from a naive viewpoint. However, in this case, the compilation to DEX *does* give a considerable performance boost, and mostly for one reason - it allows us to cut out Reflection. In the custom VM, all method calls are done by reflective invocation, which as I'm sure you're aware carries a fairly heavy penalty. When compiling for DEX, method calls are instead statically linked and compile down to invokeVirtual instructions. Since everything in Deelang is a method call, getting away from reflection is a huge win here, and was the primary reason I started on the dex compiler. > Do you have any firm numbers to support this either way? > The project is still under active development, so obviously it's too early for any real benchmarking to take place, but I did run a quick and simple test so I'd have something to illustrate the kind of performance boost we're getting. This is running the script "a = foo.timesTwo(3+2)" (where timesTwo is a Java method whose implementation I'm sure you can guess) over 10000 runs, on both the original Deelang VM and as a Dex compiled script. 09-27 10:45:27.525: I/BENCHMARK(15853): Rehearsal 09-27 10:45:37.665: I/BENCHMARK(15853): DeeVM completed : 10000 runs : 10107ms (10.107 seconds) 09-27 10:45:37.725: I/BENCHMARK(15853): Dex completed : 10000 runs : 31ms (0.031 seconds) 09-27 10:45:37.725: I/BENCHMARK(15853): Real 09-27 10:45:46.695: I/BENCHMARK(15853): DeeVM completed : 10000 runs : 8938ms (8.938 seconds) 09-27 10:45:46.745: I/BENCHMARK(15853): Dex completed : 10000 runs : 25ms (0.025 seconds) (The actual benchmark code can be found at https://code.google.com/p/deelang/wiki/DeelangPerformance) > kris > Regards, Ross -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
