

Dalvik vs Mono - felixmar
http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html

======
shimi
Mono's greatest drawback is its garbage collection which wasn't sorted since
its first version, this only is a reason not to use it on mobile devices.

I must command the bloke who wrote the article but he should have provided
more details like how he performed the tests and benchmarks.

Last Dalvik was designed to work on low resources ARM devices, it can probably
be ported to run on x86 systems, but it won't take their full advantage. Mono
wasn't designed specifically for that purpose (running on a low resources
device) which makes Dalvik a better solution. I'll give an example take a
proper 4x4, an AWD SUV, and a Sedan. The 4x4 will go anywhere and will prove
to be a great instrument in exploring the off road, on the highway it will
suffer from low grip, terrible handling, a low gas mileage. An SUV can be
taken off road, but isn't capable to pass hard terain, while on the highway it
will go better then a 4x4. A sedan will do well on the highway but taking it
down to the beach can result in a misfortune.

~~~
wmf
_Dalvik was designed to work on low resources ARM devices, ... Mono wasn't
designed specifically for that purpose ... which makes Dalvik a better
solution._

Where's the evidence? The purpose of the post is that the author could not
find any.

And really, a car analogy? On HN?

~~~
shimi
Design patterns are the same across all engineering disciplines.

Mono was designed to port the .NET to other platforms

------
litewulf
I wonder if the dalvik VM is optimized for regular computer architectures or
only for the G1.

Either way, I remember reading that Dalvik (or, well, Java) was chosen for the
constraints it places on the programmer and access to verification tools?
Security or some such?

~~~
michaelneale
Dalvik is register based byte code - from what little I have looked at it - it
looks quite low level and apparently it is meant to run fast enough
"interpreted" (ie a JIT isn't practical on small devices). However JVM
bytecode (and similar) being stack based is much higher level, leaving more
room for JITs to make a faster runtime (but for some cost which is not
practical on small devices) - but slower when "interpreted". At least that is
my understanding.

~~~
wmf
This is a good summary of the conventional wisdom, but I don't know if it's
right. Phones are now about as powerful as PCs from ten years ago; IIRC we
were using JITs on those PCs. Is Dalvik really "fast enough"? If, say, 5x more
performance was available, would developers not use it?

~~~
michaelneale
hmm... 10 years ago I don't remember thinking that fondly of JITed runtimes -
sure they worked in a server context with long running apps that had time to
warm up, but not so much on the desktop.

I guess its a tradeoff - to a user a JITed app would appear a bit slow at
first, but get faster the more you use it (plus you would then need to
probably persist the JIT codes, as you close/open apps all the time in
android) which has more complexity. A fast runtime like dalvik is the same
speed pretty much all the time.

Yes, it is conventional wisdom, but I am not sure if phones are as fast as we
think yet. Sure my iphone runs at what, 450Mhz ? which is quick, but we may
forget that JIT'ing of client side apps only recently became fast enough (at
least to my taste).

------
flashgordon
wasnt one of the non-technical reasons dalvik was chosen so as to not having
to pay royalties to sun over the JVM (and related technologies)?

