Re: How to implement dynamic typing?

"George Neuner" <gneuner2@comcast.net> wrote in message
> On Wed, 14 Apr 2010 16:07:54 -0000, "bartc" <bartc@freeuk.com> wrote:
>
>>"George Neuner" <gneuner2@comcast.net> wrote in message
>>> On Sun, 11 Apr 2010 11:46:24 -0000, "bartc" <bartc@freeuk.com> wrote:
>>>
>>> At first glance it seems that having the descriptor together with the
>>> pointer saves time, extra fetching, cache pollution, etc. for
>>> "frequent" operations like bounds checking, object length/size
>>> retrieval, etc.
>>
>>Perhaps my descriptor is different. I store:
>>
>>(tag, copy-byte, (pointer,length) or value)


> Without a lot more detail I can't speculate much on your design -
> particularly the "copy byte" whose purpose I don't know.


(It's normally 0, but set to 1 when a copy of the descriptor is made,
indicating it isn't the owner of any memory used. I'm using a slightly
different scheme now, but it's the same sort of idea. In the language,
variables never share data so the byte will be 0. Only in expressions
can it be 1.)


> WRT lengths, limits and other stuff people like to store in
> descriptors - algorithms that depend on repeatedly taking the length
> of data aren't terribly good to begin with. For index limits, your
> descriptor (as shown) only handles 1 dimensional structures - so an
> algorithm for higher dimensional data may need to access many other
> descriptors to figure out addresses and limits.


In my experience, most data is one-dimensional, sometimes two-dimensional,
and rarely three (and, with dynamic typing, quite often a mixture so that
dimensionality is meaningless)


And if the dimensions are not known until runtime, any method will
need additional data (there was a recent discussion on exactly how
much extra overhead was imposed by array-of-array vs. 2D-array in
comp.lang.misc, "how to form type descriptors")


(For bounds known at compile-time, data of any dimensions could use a
flat block of memory needing just one descriptor. Runtime bound checks
may be still be needed, but the bounds data will be implicit.)


>>I'd considered my implementation (using 16-byte descriptors) slow, but it
>>generally outperforms languages such as Ruby and Python.
>
> Most Ruby and Python implementations are bytecode interpreters - it
> doesn't take much for a compiler to outperform them 8-)


My implementation was also a byte-code interpreter. But now I'm
attempting compiled code that can deal with both static and dynamic
typing. (This way I can use just the one language for all my needs...)


> Jython and JRuby are many times faster than the languages' standard
> implementations. I understand Ruby 1.9 now has a JIT compiler but
> JRuby is still much faster.


I've just tried Jruby. It's about half the speed of my Ruby 1.9. The
last version of my project that could be called a byte-code
interpreter, seemed to be about 10-30 times faster! (This is for
simple integer benchmarks, and my code made use of dynamic types with
type hints, which roughly doubled it's speed.)


>>but it uses a method for operator dispatching (based on the types of
>>two operands) that is not easily scaleable.


> You might look at generic function dispatch mechanism in Lisp.


I think this is also known as multiple dispatch. I've had a brief look
at Lisp, but it's more about how it looks from the programmer's point
of view that the actual details of how they achieve it.. I'll try
looking harder.


--
bartc

Return to the comp.compilers page.
Search the comp.compilers archives again.