Re: P-Source: A Guide to the Apple Pascal System

David Schmenk wrote:
Eric wrote:

On Nov 29, 10:45 pm, David Schmenk <dschm...@xxxxxxxxxxxxxx> wrote:

I am allocating stack space piecewise in predefined chunks from the
heap. Activation frames will be allocated from these chunks until it is
full, then allocate another chunk and link to it. Having multiple
threads and one stack wasn't a workable solution. Now they can be
allocated dynamically, managed like anything else in the heap, and even
swapped if they don't contain the current activation frame.

I will have a background thread that runs garbage collection and calls
finalize methods.


This sounds like a pretty full-featured JVM. I seriously doubt if you
can be faster than Apple Pascal with this model but I do like what
you're doing. I was alluding to the inappropriateness of this
comparison in an earlier message. It's not fair to directly compare 2
things that are quite different. It would be extremely exciting to
hear that you can even come close to the performance of Apple Pascal
with a real garbage collection and multi-threading OS, but I just
don't want you to be dismayed if that doesn't happen.

UCSD is pretty fast given what it's doing. Their primary goal seems to
have been tight code, however, so by careful design of the byte code
you might have a shot at beating them. Especially if you are willing
to slightly accept larger runtime code in order to avoid decoding so
many tightly packed fields.

But when you add garbage collection and threading you're taking a
performance hit that is probably greater than any savings you can get
by recoding the low-level p-code/bytecode. So the end result of your
work may be a little slower in a non-trivial real-world style user
program. But the features your adding may prove quite useful over the
long term. And the long-term definitely does matter here! Apple II's
have at least another 20 years of life left in them. I can't say that
about the Dell I'm working on now - It will be in the garbage heap
within another year.

Eric


My fascination for keeping old technology alive probably explains why I drive a 35 year old BMW at the racetrack :-) As for the JVM performance, time will tell. This is definitely a long-term projet i.e. don't expect an announcement next week.

My gut feel is that the actual bytecode interpreter will be right there with the p-code interpreter; I'm using almost the same architecture with slightly faster code, but 32 bit operations. It's the other aspects of the JVM having to do with constant loads, field access, and method invocations that will dictate the difference from the pascal implementation. Threading should have close to zero impact on performance. Garbage collection, I dunno. It's the one part of my current implementation I'm really not happy with.

In my experience, it's hard to know how a storage allocation/garbage
collection policy will perform until it's subjected to an actual
workload--and even then, results can be highly workload-dependent.

-michael

NadaPong: Network game demo for Apple II computers!
Home page: http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."
.

Relevant Pages

  • Re: P-Source: A Guide to the Apple Pascal System
    ... Activation frames will be allocated from these chunks until it is ... then allocate another chunk and link to it. ... allocated dynamically, managed like anything else in the heap, and even ... I will have a background thread that runs garbage collection and calls ...
    (comp.sys.apple2)
  • Re: Garbage collector and multiple threads
    ... > The only way to prevent Garbage Collection is to create no garbage. ... > additional heap objects, then no Garbage Collections will occur. ... Do AppDomains have separate heaps, ... > The only other thing I can think of is that if you allocate little enough ...
    (microsoft.public.dotnet.framework)
  • Re: P-Source: A Guide to the Apple Pascal System
    ... then allocate another chunk and link to it. ... allocated dynamically, managed like anything else in the heap, and even ... I will have a background thread that runs garbage collection and calls ... Threading should have close to zero impact on performance. ...
    (comp.sys.apple2)
  • Re: unmanaged vs managed.
    ... Optimized I/O, Threading, GC, Pinning, Heap vs Stack, etc, are what I do all ...
    (microsoft.public.dotnet.languages.csharp)