Smalltalk › Squeak › Squeak VM

Dalvik vs. ART: Android virtual machines and the battle for better performance | Pocketnow

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

23 messages Options

Casey Ransberger-2

Re: Dalvik vs. ART: Android virtual machines and the battle for better performance | Pocketnow

Isn't the Objective-C runtime a kind of VM? It might not be byte code based, but it does lots of other things that we need VMs for generally, like dynamic dispatch and such.

I realize the machinery is different, but if it walks like a duck…

Seems like the linked paper is another example of the "use the most popular VM" strategy, rather than an argument that "VMs are dead" to me. Feel free to fire back if I'm completely and dead wrong, but it just doesn't seem that different from Smalltalk on the JVM, etc…

Casey

On Sat, Dec 14, 2013 at 12:04 AM, Clément Bera <[hidden email]> wrote:

Hello,

2013/12/13 Eliot Miranda <[hidden email]>

On Fri, Dec 13, 2013 at 1:07 PM, askoh <[hidden email]> wrote:

I am not a VM guy. But, is the Smalltalk in a C World article compiling
Smalltalk to machine code to run without the VM?
http://www.cl.cam.ac.uk/~dc552/papers/SmalltalkInACWorld.pdf

He talks about the VM being a relic of the past. Is that true?

Is the Java VM a relic of the past? Given portable devices is compiled code a relic of the past? Is a safe development environment with fast compile times a thing of the past? Their own conclusions imply that the answer is not yet:

What do you mean by not yet ? Do you think that in a 10 or 20 years VMs will be obsolete ?

There's 1 detail I am not sure. By JIT in this article (http://m.pocketnow.com/2013/11/13/dalvik-vs-art), does he mean the bytecode to native code generator only or the native code generator + inline cache management + adaptive recompiler.

I'm wondering, even if they have their code stored as native code instead of byte code, do they have some kind of native code generator for adaptive recompilation to reach such a performance ?

And how do they manage their inline caches ? As all methods are native, some monomorphic inline caches could be promoted to PIC due to 1 very rare case and then as they always keep the same n-code this send site would be slower forever. Does this mean they would need to empty inline caches sometimes ?

"Our current approach lacks some of the advantages of Smalltalk. The most obvious of these is debugging. Our current implementation emits very sparse DWARF debugging information and so is fairly limited in terms of debugging support even in comparison to C, and therefore a long way behind the state of the art for Smalltalk circa 1980. This is currently the focus of ongoing work. Once this is done, then implementing things like thisContext making use of debug metadata become possible. In our current implementation, run-time introspection is only available for objects and variables bound to blocks, not for activation records.

Closely related is the rest of the IDE. In traditional Smalltalk implementations, the IDE is closely integrated with the execution environment. GNU Smalltalk is the major exception, and provides a model close to ours. Building a good IDE and debugger is beyond the scope of the LanguageKit project, but building these tools on top of LanguageKit is a goal of E ́toile ́."

All the best,
Aik-Siong Koh

--
View this message in context: http://forum.world.st/Dalvik-vs-ART-Android-virtual-machines-and-the-battle-for-better-performance-Pocketnow-tp4729727p4729982.html
Sent from the Squeak VM mailing list archive at Nabble.com.

--
best,
Eliot

Eliot Miranda-2

Re: Dalvik vs. ART: Android virtual machines and the battle for better performance | Pocketnow

In reply to this post by Clément Béra

Hi Clément,

On Sat, Dec 14, 2013 at 12:04 AM, Clément Bera <[hidden email]> wrote:

Hello,

2013/12/13 Eliot Miranda <[hidden email]>

On Fri, Dec 13, 2013 at 1:07 PM, askoh <[hidden email]> wrote:

I am not a VM guy. But, is the Smalltalk in a C World article compiling
Smalltalk to machine code to run without the VM?
http://www.cl.cam.ac.uk/~dc552/papers/SmalltalkInACWorld.pdf

He talks about the VM being a relic of the past. Is that true?

Is the Java VM a relic of the past? Given portable devices is compiled code a relic of the past? Is a safe development environment with fast compile times a thing of the past? Their own conclusions imply that the answer is not yet:

What do you mean by not yet ? Do you think that in a 10 or 20 years VMs will be obsolete ?

Personally no. In fact I think the trend is towards ever more virtualization, ever more language-to-language translation, ever more modelling of computation (for example reversible debuggers). The cloud actually implies that computation is better managed virtually because hardware improves, crashes, moves, etc, and if there are long-running computations tying them down to one piece of hardware seems limited. Azul systems already build java-specific server that allows for processors to evolve their ISA over time.

There's 1 detail I am not sure. By JIT in this article (http://m.pocketnow.com/2013/11/13/dalvik-vs-art), does he mean the bytecode to native code generator only or the native code generator + inline cache management + adaptive recompiler.

I don't know and I don't think the author knows enough to differentiate. It's not a well-written article. He claims AOT is a new concept; it's not. Microsoft's .Net has done this for a while. He claims "This code is mostly uncompiled. That means it’s slower than compiled code would be, but your device gets the “insulation” advantages that VMs provide" which is comparing apples to oranges (one can produce safe native code; a VM is an example of it, and there's no fundamental reason why jit code is slower than native code and in some cases it can be faster). So I don't think it's worth worrying. I'd rather read a well-written paper on KitKat than spend any more effort on this article.

I'm wondering, even if they have their code stored as native code instead of byte code, do they have some kind of native code generator for adaptive recompilation to reach such a performance ?

And how do they manage their inline caches ? As all methods are native, some monomorphic inline caches could be promoted to PIC due to 1 very rare case and then as they always keep the same n-code this send site would be slower forever. Does this mean they would need to empty inline caches sometimes ?

"Our current approach lacks some of the advantages of Smalltalk. The most obvious of these is debugging. Our current implementation emits very sparse DWARF debugging information and so is fairly limited in terms of debugging support even in comparison to C, and therefore a long way behind the state of the art for Smalltalk circa 1980. This is currently the focus of ongoing work. Once this is done, then implementing things like thisContext making use of debug metadata become possible. In our current implementation, run-time introspection is only available for objects and variables bound to blocks, not for activation records.

Closely related is the rest of the IDE. In traditional Smalltalk implementations, the IDE is closely integrated with the execution environment. GNU Smalltalk is the major exception, and provides a model close to ours. Building a good IDE and debugger is beyond the scope of the LanguageKit project, but building these tools on top of LanguageKit is a goal of E ́toile ́."

All the best,
Aik-Siong Koh

--
View this message in context: http://forum.world.st/Dalvik-vs-ART-Android-virtual-machines-and-the-battle-for-better-performance-Pocketnow-tp4729727p4729982.html
Sent from the Squeak VM mailing list archive at Nabble.com.

--
best,
Eliot

--
best,

Eliot

Guido Chari

Re: Dalvik vs. ART: Android virtual machines and the battle for better performance | Pocketnow

2013/12/17 Eliot Miranda <[hidden email]>

Hi Clément,

On Sat, Dec 14, 2013 at 12:04 AM, Clément Bera <[hidden email]> wrote:

Hello,

2013/12/13 Eliot Miranda <[hidden email]>

On Fri, Dec 13, 2013 at 1:07 PM, askoh <[hidden email]> wrote:

I am not a VM guy. But, is the Smalltalk in a C World article compiling
Smalltalk to machine code to run without the VM?
http://www.cl.cam.ac.uk/~dc552/papers/SmalltalkInACWorld.pdf

He talks about the VM being a relic of the past. Is that true?

Is the Java VM a relic of the past? Given portable devices is compiled code a relic of the past? Is a safe development environment with fast compile times a thing of the past? Their own conclusions imply that the answer is not yet:

What do you mean by not yet ? Do you think that in a 10 or 20 years VMs will be obsolete ?

Personally no. In fact I think the trend is towards ever more virtualization, ever more language-to-language translation, ever more modelling of computation (for example reversible debuggers). The cloud actually implies that computation is better managed virtually because hardware improves, crashes, moves, etc, and if there are long-running computations tying them down to one piece of hardware seems limited. Azul systems already build java-specific server that allows for processors to evolve their ISA over time.

I don't think the concept of no VM is so clear or straightforward. There are some projects (like BeeSmalltalk and Mist) that are claiming that they low-level implementation produce in some way a straight executable attached to the language application and not a VM. But does that not mean to have fewer abstraction levels or no virtualization. That means that progress on compilation toolchains and moving as much as possible to language-side loadable libraries provides lot of advantages and that perhaps you don't need to have a separate concept of a VM outside your language.

There's 1 detail I am not sure. By JIT in this article (http://m.pocketnow.com/2013/11/13/dalvik-vs-art), does he mean the bytecode to native code generator only or the native code generator + inline cache management + adaptive recompiler.

I don't know and I don't think the author knows enough to differentiate. It's not a well-written article. He claims AOT is a new concept; it's not. Microsoft's .Net has done this for a while. He claims "This code is mostly uncompiled. That means it’s slower than compiled code would be, but your device gets the “insulation” advantages that VMs provide" which is comparing apples to oranges (one can produce safe native code; a VM is an example of it, and there's no fundamental reason why jit code is slower than native code and in some cases it can be faster). So I don't think it's worth worrying. I'd rather read a well-written paper on KitKat than spend any more effort on this article.

I'm wondering, even if they have their code stored as native code instead of byte code, do they have some kind of native code generator for adaptive recompilation to reach such a performance ?

And how do they manage their inline caches ? As all methods are native, some monomorphic inline caches could be promoted to PIC due to 1 very rare case and then as they always keep the same n-code this send site would be slower forever. Does this mean they would need to empty inline caches sometimes ?

"Our current approach lacks some of the advantages of Smalltalk. The most obvious of these is debugging. Our current implementation emits very sparse DWARF debugging information and so is fairly limited in terms of debugging support even in comparison to C, and therefore a long way behind the state of the art for Smalltalk circa 1980. This is currently the focus of ongoing work. Once this is done, then implementing things like thisContext making use of debug metadata become possible. In our current implementation, run-time introspection is only available for objects and variables bound to blocks, not for activation records.

Closely related is the rest of the IDE. In traditional Smalltalk implementations, the IDE is closely integrated with the execution environment. GNU Smalltalk is the major exception, and provides a model close to ours. Building a good IDE and debugger is beyond the scope of the LanguageKit project, but building these tools on top of LanguageKit is a goal of E ́toile ́."

All the best,
Aik-Siong Koh

--
View this message in context: http://forum.world.st/Dalvik-vs-ART-Android-virtual-machines-and-the-battle-for-better-performance-Pocketnow-tp4729727p4729982.html
Sent from the Squeak VM mailing list archive at Nabble.com.

--
best,
Eliot

--
best,
Eliot