[ruby-talk:19392] Re: Perl/Python/Ruby common backend (Parrot, can Ruby play too?)

"Mathieu Bouchard" <[e-mail]> wrote in message
news:N%6c7.21330$[e-mail]...
>
>
> (2-in-1 reply)
>
>
> On Wed, 8 Aug 2001, A Bull in the China Shop of Life wrote:
> > All this debate about Python vs Ruby is of questionable value IMO,
they're
>
> This is not a Python vs Ruby debate, it's a comparison of features for the
> sole purpose of knowing better what would need to be in a multi-language
> VM to support Ruby.

Since this is the topic, I've included a posting (for reference) that I made
to the "language-dev" group at netthink.co.uk.

<POST-BEGIN>
Mailing-List: contact [e-mail]; run by ezmlm
Precedence: bulk
Delivered-To: mailing list [e-mail]
Received: (qmail 2348 invoked from network); 7 Aug 2001 21:34:02 -0000
Received: from unknown (HELO qks.com) (157.22.131.5)
  by 212.135.138.134 with SMTP; 7 Aug 2001 21:34:02 -0000
Received: from ROADWARRIOR.qks.com (157.22.131.30) by qks.com
 with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 7 Aug 2001
14:42:31 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Tue, 07 Aug 2001 14:33:54 -0700
To: [e-mail]
From: David Simmons <[e-mail]>
Subject: Targetting the JVM/IL
Mime-Version: 1.0
Content-Type: multipart/alternative;
        boundary="=====================_134114666==_.ALT"

Hi All,

I'm new to this group but I have tried to review the couple hundred or so
posts that have been made so far.

A little background on me and my work...

I've been a dynamic language designer and VM architect for the last decade
or so. By training I'm actually an Electrical Engineer with specialization
in VLSI design and Digital Logic. But I long ago switched to being focused
almost exclusively on software engineering.

I've have many years of extensive experience [largely focused on Japanese]
providing globalization facilities, services, and frameworks across three
significantly different platforms [MacOS, Win32, Unix/Linux]. I served for
some time on the LI18NUX standards group.

Since 1999 I've been involved with building dynamic language services for
Microsoft's .NET platform and have pushed/pulled necessary elements from
Microsoft to make it possible to support acceptable dynamic dispatch
performance.

Of all the languages currently built for .NET my work on SmallScript
(Smalltalk) is [as far as I am aware] the only language to employ a complete
dynamic language MOP and dispatching system. It is also of note that I was a
speaker at last years PDC on .NET, and I regularly meet with and talk to
most of the other 3rd party .NET language implementors.

I've been focused on dynamic languages for a very long time. I built my
first [from scratch] scripting language implementation as an onboard
[downloadable/updatable from a PDP/bsd machine over the network] specialized
basic dialect in the late 70's are part of my work in designing and building
network packet switching, routing and debugging hardware for the NBS (NIST)
arpa-net facilities.

I've been involved and focused on scripting languages since the early 90's
where we [QKS] worked closely [as part of a universal virtual machine
effort] with Apple and Kaleida on numerous technologies including OpenDoc,
SK8, ScriptX, AppleScript, HyperTalk, etc, and to significantly lesser
degree with Dylan/MacLisp efforts.

Very little of my work has ever been published (by me) in academic journals
or publications because I've generally been too busy with business issues,
designs, implementation, or deployment. Some things can be found in various
books or on the web by searching for keywords like: QKS, Quasar, Agents,
AOS, SmalltalkAgents, STA, SmallScript. Much of this information was focused
in the MacOS community throughout the early to mid 90's and is hard to find
or access. Hopefully, over the next few years I'll get a chance to republish
material from our books/manuals and other materials I have.
===

That said, it has been my experience so far, that current .NET versions are
significantly lacking in technology to provide hi-performance execution of
scripting languages. The future versions of .NET are entirely different
question. However, .NET has some crucial technical facilities that make it
capable of supporting dynamically dispatched languages far better than Java.
But, it still seriously lags behind the performance and capabilities that
can be achieved in a VM designed to support dynamic dispatch and dynamic
languages. These comments are based directly on my work with Microsoft for
developing a Smalltalk implementation for .NET.

My most recent work includes the 4th generation design of the AOS Platform
[dynamic language] VM. AOS is an acronym for Agents Object System. Its
typical performance is about 1-2x faster than IBM's VisualAge VM, and 10-30%
faster than Cincom [ParcPlace] VisualWorks VM.

There is at least another generation of work to be done on the AOS VM before
I would consider it highly tuned. But as it stands it typically executes
code at speeds that are within 1-2X of C.  More global optimizations and
extended adaptive compilation and inlining are required to go beyond this
level of performance.

Based on various Micro benchmarks or specific code examples I've seen posted
for Ruby, Python, and Perl benchmarks I can roughly rank the performance of
each of those systems for generic code operations. Ruby seems to have the
best overall performing execution, followed by Python, and then pulling in
last is Perl. Again, this is very subjective and real quantitative analysis
is lacking. Furthermore, I am sure that each language has some aspects where
that are superior ("sweet" spots) in terms of performance or expressability.

However, in the cases I've examined so far, the equivalent SmallScript code
ran at an order of magnitude (10 times) faster on my VM. Some tests were
100's or thousands of times faster on my VM. Keep in mind that Smalltalk and
hence my SmallScript examples, did not need or use any statically declared
type information.

Some of the more important samples were the collection frameworks for hashed
collections such as sets, maps (dictionaries), etc.
---

That said, my goal here is not some kind of language/vm competition/contest
[I will rapidly bow out from such situations]. The goal of my providing this
information and the point I'm trying to make is to share my knowledge and
help others understand what is possible for a dynamic language VM.

To help put some of this in perspective I need to give you a rundown of some
of the relevant features in the AOS Platform VM.

a) unified object model based on a fully dynamic MOP architecture supporting
arbitrary schema restructuring in real time. These facilities all operate
down to the per/object level. So it is efficient and straightforward to add
variables, methods, interfaces, properties to individual objects.

b) optional type system services

c) optional multi-method dispatch

d) transparent ffi marshalling [typical rates are in the 10's of millions of
calls per second].

e) first class abstract, pure, and concrete mixin interfaces.

f) first class namespace system, including dynamic selector namespaces
(scoped methods). The dynamic dispatch and binding facilities are
state-of-the-art and include many features not available in other languages.
These include many features for reflective programming,
proxy/agent/distributed techniques, aspect oriented/style programming, and
object/relational mapping.

g) first class module system to describe units of deployment, integration,
versioning, and linking [more formal than loose packages -- which are also
available]. This technology is focused on enabling dynamic modification to
complex live running systems in an engineered manner that also supports
sandbox techniques.

h) basic object property system. Allows adding/removing arbitrary groupable
sets of properties (attributes/fields) to an object.

i) pre-emptively multi-threaded with hi-performance developer definable
synchronization services and thread local state and binding mechanisms.

j) hi-performance sandbox facilities. Supporting an unlimited set of
composable sandboxes that can be designed by the developer.

k) built in object model semantics for globalization support of code-pages,
unicode, etc.

l) intrinsic language support (and jit optimization) for regular expressions
as closures.

m) the AOS Platform [VM, compilers, core frameworks] delivers/deploys as a
single shared-library file of roughly 600kb.

*) there are currently a number of language ports underway for the core AOS
Platform [which, as the website indicates, the core AOS Platform will be
free (no-licensing-fees)].

The .NET deployment mechanism is actually based on AOS Platform cross-jitter
technology which converts AOS Platform IL into .NET IL using the AOS
Platform's object model reflection services.

This means that *any* language which compiles for the AOS Platform, can have
its compiled code re-targeted for deployment, integration, or source level
debugging on .NET without ever building any DotNet specific facilities.
=====

Having said all the above, it is my observation/belief that the biggest
technical design issue for a common runtime mechanism involves the language
semantics issues of deterministic finalization. I.e., reference-counting
versus automatic-gc.

My goals are quite mixed, and I recognize that my commercial goals may be at
odds one way or another with open source views and goals of those within
this discussion group.

But, at the end of the day, I'm a hardcore fan of dynamic/scripting
languages and I have the experience/confidence to help me understand that
great strides can be achieved from where such languages are today -- i.e.,
they can be made to more than compete with the likes of Java.

I am an evangelist for pushing dynamic/scripting languages and working to
help the developer communities understand they can have all the benefits of
static languages and the flexibility, scalability, and ease of use of
dynamic languages. I believe most of you, if not all of you, share that
sentiment or desire to one degree or another?

Best Regards,

-- Dave S. [QKS]

SmallScript for the AOS & .NET Platforms
[e-mail] | http://smallscript.net
1-800-296-1339 [1-650-560-4837]

<POST-END>

>
>
> On Wed, 8 Aug 2001, Piers Cawley wrote:
> > Mathieu Bouchard <[e-mail]> writes:
> > > Ruby has this thing called "mixins" that afaik is not in Python
> (unless
> > > it's quite recent) and is not in Perl.
> > You can 'sort of' do mixins with perl
> >     BEGIN {
> >         do "Module.pm" || die "Couldn't load module";
> >     }
> > just make sure that 'Module.pm' doesn't have a package declaration. As
> > you can no doubt see from its cumbersome syntax, mixins are not
> > generally used within perl.
>
> That's way too sort-of to be called "mixins" and AFAIK offers no advantage
> over Perl's multiple inheritance. Am I right ?
>
> Anyway the issue is, in a Perl/Python/Ruby VM, mixins with Ruby-style
> inheritance is required, and so we'd have to make sure Damian's NEXT
> proposal goes through.
>
>
> matju
>
>