From: Arno P. <ar...@pu...> - 2011-02-12 18:58:58
|
On Feb 11, 2011, at 11:40 PM, Sal <sv...@gm...> wrote: > I'm really enjoying learning about xmlvm and I think it's a fascinating project! I had a few questions for the experts here about it. > > - How is performance compared to original Java code? If slower by a factor of how much? Are there any benchmarks done yet? Can intensive things be done i.e. - realtime physics engines for video games Benchmarking is a tricky business because you easily end up comparing apples and oranges. We have not done any benchmarking. The C backend will be much more performant than the Objective-C backend for various reasons, but we don't know how this compares to a JVM. > > - Is boehm gc being used on the iPhone target(s)? If not how does xmlvm get around using reference counting in the new C target Ive read about? We use the Boehm GC for iOS devices. > > - what major tasks are left for the 'C' output target to be a usable one instead of the Obj-c++ one, in case anyone is interested to help =) Look for NOT_IMPLEMENTED in src/xmlvm2c/compat-lib/iphone > > - The idea of byte code to XML to ' XYZ' programming language via xsl is great and very flexible. But has anyone considered taking something like JavaML (http://www.badros.com/greg/JavaML/) which generates XML version of the Java program's AST (abstract syntax tree). XSL could then be used to convert this to a 'high level' target, such as C++, which is very similar to java already. Use the same GC techniques and libraries xmlvm already has - and you have maximal performance via C++ compilation of high level code rather than VM opcodes as xmlvm does today. I would imagine several orders better performance with just as much flexibility - say write c# code for win7, and JavaScript target would be more performant as well. Java byte code is also easily reversed by libraries like JAD to generate 'high level' Java from that byte code, so .class files are still processible if code is not available. Possible that you can do more optimizations on source code level, but this also requires a lot more effort. E.g., there are no bytecode instructions for generics since the Java compiler already converted them to casts from and to java.lang.Object. This makes our life much easier. All in all we found that by using Androids register based instruction set (DEX) to be ideal for creating efficient code in the target language. Arno |