[M3devel] bandwith

[Daniel Alejandro Benavides D.]

Hi Rodney:
Well, I think the main issue as you point out is the architecture of the VM, as you know JVM is a Java based architecture so many of its structures are suited for that language and probably this is related to a compiler efficiency thing and thus you can say that a big language like Java needs an appropiate VM like JVM.
I think that in M3 case what could be more suitable for real use is a SPIN powered vm like itself running in bare hardware with current hardware assisted virtualization such of current leading processors that would be a plus, it would lack supoort for more real machine languages (i.e C), but as it is running in kernel mode could give a better performance. In other architectures it could be run with kernel level virtualization and thus gaining better performance or similar even if its not a complete form of virtualization in bare hardware (by writing for SPIN M3 or other VM based language too and run in kernel mode like a M3 process, like the JVM M3 hosted if so, etc).
I think having a kernel level virtual machine could be a gain in performance for some applications written for other machines or languages and or virtual machines or even the same kind of machines in M3 but in other systems (like running a DEC Unix or BSD flawor even with C libraries from inside SPIN).
In fact SPIN was ported to NT as a driver for an intelligent NIC, thus allowed to run in bare hardware and at kernel level
Thanks in advance,


--- El dom, 14/3/10, Rodney M. Bates <rodney_bates at lcwb.coop> escribió:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] bandwith
> Para: m3devel at elegosoft.com
> Fecha: domingo, 14 de marzo, 2010 10:58
> 
> 
> Dirk Muysers wrote:
> >  To make it work for all these different
> platforms seems a herculean task and rather pointless
> > endeavour. Why not use all that energy to try a
> radically disruptive strategy such as a platform
> > agnostic intermediate form targeting a JIT.
> >  
> 
> I have been a little way down this road at least three
> times, with at
> least two different languages, and it turns out not to be
> what it would
> appear at first glance, at least for the JVM.
> 
> Java is a mostly object-oriented language, meaning the
> non-object-oriented
> types and operations are very limited.  Most of the
> interesting stuff can
> be done only with full-blown heap allocated objects and
> dispatching methods.
> Even the equivalents of records and arrays are this way inb
> Java.  When you
> don't need this full generality and power, you pay big
> performance penalties
> for heap allocation, and this is worse and much deeper than
> the
> performance penalties of an interpretive implementation.
> (which, of
> course, a JIT code generator partially avoids, and a
> traditional
> source-to-machine compiler avoids altogether, all with no
> language
> changes.)
> 
> Many languages, Modula-3 included, give this generality for
> when you need
> it, but also give you lighter weight alternatives, for use
> when appropriate.
> 
> So when you try to implement some other language using JVM,
> you soon
> discover that JVM lacks a lot of operations needed for the
> not-so-
> impoverished non-object-oriented types of the language.
> 
> Whether or how badly the .net/mono virtual machine suffers
> from this, I
> don't know.  It apparently was designed to support a
> much wider range
> of languages, but I seem to recall hearing some discussions
> that suggested
> it had some of the same limitations.
> 
> Of course, we could invent our own virtual machine (M-code?
> MVM?) ;-).
> 
> This whole approach is of course, not very suitable for
> systems programming,
> one of Modula-3's strengths.
> 
> 
> 
> > d. muysers
>