Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,805,635 Members 38,570 Now Online
XDA Developers Android and Mobile Development Forum

C#, VB, Ruby, F#, and Python on Android (via Mono and DLR)

Tip us?
 
Koush
Old
(Last edited by Koush; 23rd January 2009 at 11:07 AM.)
#1  
Retired Recognized Developer - OP
Thanks Meter 894
Posts: 917
Join Date: Sep 2007
Default C#, VB, Ruby, F#, and Python on Android (via Mono and DLR)

This all works on stock/nonroot phones

I got Mono running on Android.
http://www.koushikdutta.com/2008/12/...s-at-last.html

Started working on Java/C# interop and found out that DLR works on Mono:
http://www.koushikdutta.com/2009/01/...ython-and.html
As a result, you can write applications in Python and Ruby on Android too now.

Anyhow, if anyone else is interested in working on this project with me, please let me know! I've already gotten all the relevent source hosted at Google Code: http://code.google.com/p/androidmono. Basically the next bit of work involves implemeting a Java interop using the DLR.
 
jashsu
Old
(Last edited by jashsu; 31st December 2008 at 12:23 AM.)
#2  
jashsu's Avatar
Senior Member
Thanks Meter 12
Posts: 1,852
Join Date: Nov 2008
Nifty.

As for Dalvik & JIT, I think dexopt already replaces some heavy usage calls with inline native code. Hopefully dalvik vm will get full JIT in the future?
 
afbcamaro
Old
#3  
afbcamaro's Avatar
Senior Member
Thanks Meter 1
Posts: 164
Join Date: Dec 2006
This makes me very happy!!!
Thank you for your work!!
Wizard 8125, O2 Exec (Universal) 64MB and 128MB
O2 XDAiis (Blue Angel) ,MPX200
MPX220, MPX300
StarTrek, Hw6300
Hw6500, HTC Juno
HTC Tornado, HTC Apache
HTC Hermes, O2 Flame
HTC Alpine, Moto Ming A1200
Treo 750, Razor
HTC Dream, HTC Juno
HTC Excalibur,
 
Koush
Old
#4  
Retired Recognized Developer - OP
Thanks Meter 894
Posts: 917
Join Date: Sep 2007
Quote:
Originally Posted by jashsu View Post
Nifty.

As for Dalvik & JIT, I think dexopt already replaces some heavy usage calls with inline native code. Hopefully dalvik vm will get full JIT in the future?
It doesn't do any inline native replacements: dexopt optimizes the dex file. Which includes inline dex byte code replacements. There is no JIT at all, but Google said it would be something definitely on the horizon. Personally I think DEX is a pretty stupid move on Google's part; they could have just gone with CIL-- and write a Java compiler for that instead. The Mono JIT compiler works on many platforms; so V1 of Android could have been running JIT compiled native code with that route... which is an order of magnitude better in performance.
I'm going to be doing some performance comparisons of Mono vs Dalvik; Mono will obviously win, but it will be interesting to see the margin. I'll also experiment with binding Mono to the Android runtime to create Android applications in C#.

Quote:
Optimization

Virtual machine interpreters typically perform certain optimizations the first time a piece of code is used. Constant pool references are replaced with pointers to internal data structures, operations that always succeed or always work a certain way are replaced with simpler forms. Some of these require information only available at runtime, others can be inferred statically when certain assumptions are made.

The Dalvik optimizer does the following:

For virtual method calls, replace the method index with a vtable index.
For instance field get/put, replace the field index with a byte offset. Also, merge the boolean / byte / char / short variants into a single 32-bit form (less code in the interpreter means more room in the CPU I-cache).
Replace a handful of high-volume calls, like String.length(), with "inline" replacements. This skips the usual method call overhead, directly switching from the interpreter to a native implementation.
Prune empty methods. The simplest example is Object.<init>, which does nothing, but must be called whenever any object is allocated. The instruction is replaced with a new version that acts as a no-op unless a debugger is attached.
Append pre-computed data. For example, the VM wants to have a hash table for lookups on class name. Instead of computing this when the DEX file is loaded, we can compute it now, saving heap space and computation time in every VM where the DEX is loaded.
All of the instruction modifications involve replacing the opcode with one not defined by the Dalvik specification. This allows us to freely mix optimized and unoptimized instructions. The set of optimized instructions, and their exact representation, is tied closely to the VM version.

Most of the optimizations are obvious "wins". The use of raw indices and offsets not only allows us to execute more quickly, we can also skip the initial symbolic resolution. Pre-computation eats up disk space, and so must be done in moderation.

There are a couple of potential sources of trouble with these optimizations. First, vtable indices and byte offsets are subject to change if the VM is updated. Second, if a superclass is in a different DEX, and that other DEX is updated, we need to ensure that our optimized indices and offsets are updated as well. A similar but more subtle problem emerges when user-defined class loaders are employed: the class we actually call may not be the one we expected to call.

These problems are addressed with dependency lists and some limitations on what can be optimized.
 
lu_tze
Old
#5  
Junior Member
Thanks Meter 0
Posts: 5
Join Date: Nov 2008
Quote:
Originally Posted by Koush View Post
Personally I think DEX is a pretty stupid move on Google's part; they could have just gone with CIL-- and write a Java compiler for that instead. The Mono JIT compiler works on many platforms; so V1 of Android could have been running JIT compiled native code with that route... which is an order of magnitude better in performance.
I'm going to be doing some performance comparisons of Mono vs Dalvik; Mono will obviously win, but it will be interesting to see the margin. I'll also experiment with binding Mono to the Android runtime to create Android applications in C#.
Google had different objectives, they didn't go after maximum performance. Remember, that handsets have different constrains than desktops and laptops. So they went after minimizing RAM usage (byte code interpreter => maximum possible sharing of read-only memory pages among processes) and battery life. Performance had to be acceptable, not priority.

You would not be able to fit everything into RAM if you used Mono and you would get the patent problems with Net/Mono/etc as a bonus.
 
Koush
Old
(Last edited by Koush; 31st December 2008 at 01:00 PM.)
#6  
Retired Recognized Developer - OP
Thanks Meter 894
Posts: 917
Join Date: Sep 2007
Quote:
Originally Posted by lu_tze View Post
Google had different objectives, they didn't go after maximum performance. Remember, that handsets have different constrains than desktops and laptops. So they went after minimizing RAM usage (byte code interpreter => maximum possible sharing of read-only memory pages among processes) and battery life. Performance had to be acceptable, not priority.

You would not be able to fit everything into RAM if you used Mono and you would get the patent problems with Net/Mono/etc as a bonus.
.NET, C#, IL, et al are all ECMA standards. Mono is LGPL/GPL. There are no patent or licensing issues with it that is unfamiliar to the OHA. They reuse plenty of open source projects.

An interpreter is not power efficient OR performant, simply due to the fact is it doing the 10 times as much work to do the same thing as native code. In addition, Mono features an Ahead Of Time compiler (AOT) that would let you compile everything to native code before it even hits the phone (or just once, and cache it). Most of Android's power and memory optimizations currently comes from Google's application life cycle (activities can be killed and resumed at the system's whim) -- that has nothing to do with Dalvik. I'm not criticizing the API or the implementation, just the runtime.

They could have spent their time making the Mono runtime play nicely with the shared memory subsystem.

I'm rebuilding mono with a minimal configuration to check out the disk and memory footprint.
 
pic.micro23
Old
#7  
Junior Member
Thanks Meter 0
Posts: 29
Join Date: Nov 2008
Quote:
Originally Posted by Koush View Post
Not that most of you will care, but I got Mono running on Android.
I'm a noob.... how can I install this? Very good Job Kush!
 
Koush
Old
#8  
Retired Recognized Developer - OP
Thanks Meter 894
Posts: 917
Join Date: Sep 2007
Quote:
Originally Posted by pic.micro23 View Post
I'm a noob.... how can I install this? Very good Job Kush!
I haven't released anything yet. I'm trying to figure out how to statically link all it's dependencies, minimize the size, bind to the Android runtime, convert DEX to CIL and then CIL to ARM, and all sorts of other goodness. Basically a lot of experimenting to do before anything is "released". It's just in proof of concept phase right now.
 
Koush
Old
#9  
Retired Recognized Developer - OP
Thanks Meter 894
Posts: 917
Join Date: Sep 2007
Dalvik sucks
http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html
 
JesusFreke
Old
#10  
JesusFreke's Avatar
Recognized Developer
Thanks Meter 41
Posts: 736
Join Date: Oct 2008
Location: Dallas
Quote:
Originally Posted by Koush View Post
Lol. nice article Koush. It's surprising mono is that much faster
"Whether You Think You Can or Can't, You're Right"
--Henry Ford

Android Developer Phone 1 - JFv1.51 - REPRESENT!

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Google Play Services Updated to Version 6.1

In addition to Android operating system proper, Google is focusing hard on giving the developers … more

CyanogenMod 11 M10 Available for Supported Devices

Summer vacation isover for most students out there, and it’s the time to get back to … more

XDA Forums Added for the First Batch of Android One Devices!

Just yesterday, we talked about the highly anticipated launch of the first batch … more

XDA Xposed Tuesday: DonkeyGuard, Don’t Be a Donkey, Control Your Device – XDA Developer TV

Some applications ask for the world … more