On Thu, Jul 17, 2003 at 09:52:35PM +0200, Leopold Toetsch wrote:
> Remaining is:
> 1) save & fill the byte_code with event handler ops.
> 2) use address relative to op_func_table
> 3) Or the "official" way: do regular checks.
> I estimate 2) to be best for prederefed code.
I'm not sure about this.
On Tue, Jun 10, 2003 at 04:00:07PM -0700, Jonathan Sillito wrote:
> > -Original Message-
> > From: Jerome Vouillon [mailto:[EMAIL PROTECTED]
> >
> > The python interpreter seems rather slow. I get these numbers with the
> > Ocaml bytecode interpreter.
&
On Tue, Jun 10, 2003 at 04:59:50PM -0700, Robert Spier wrote:
> > > mistral-jerome:/tmp > time python test.py
> > > python test.py 2,59s user 0,00s system 100% cpu 2,582 total
> > > mistral-jerome:/tmp > ocamlc -o tst test.ml; time ./tst
> > > ./tst 0,14s user 0,00s system 106% cp
On Tue, Jun 10, 2003 at 06:07:31PM +, Jonathan Sillito wrote:
> I am not satisfied with the time taken to make a call. I did some rough
> benchmarking and the parrot implementation makes us slower than python
> 2.2.1. The most expensive part of our call is the saveall/restoreall that
> wraps th
On Mon, Feb 24, 2003 at 05:29:26PM +, Piers Cawley wrote:
[Tail-call optimization]
> Under caller saves, this is easy to do. Under callee saves, b's second
> call to c() cannot simply return to Continuation A but must unwind the
> call stack via b to make sure that the right things are restored
On Tue, Feb 25, 2003 at 08:47:55AM +0100, Leopold Toetsch wrote:
> >Um... no. tail call optimization implies being able to replace *any*
> >tail call, not just a recursive one with a simple goto. Consider the
> >following calling sequence:
>
>
> > b(arg) -> Push Continuation A onto the continua
On Sat, Feb 08, 2003 at 05:36:58PM +0100, Leopold Toetsch wrote:
> Jason Gloudon wrote:
> >On Fri, Feb 07, 2003 at 05:49:35PM +0100, Leopold Toetsch wrote:
> >>I don't know yet, how multi threading will be done. But when multiple
> >>interpreters share the ->code data member (as newinterp/runinter
On Thu, Feb 06, 2003 at 01:37:42PM +0100, Leopold Toetsch wrote:
> This is one thing I allways wanted to try ;-)
>
> fast_core MOps: 11
> Prederef: 17.5
> CGoto MOps: 19.4
> CGP MOps: 27.5
> CGP -O3 MOps: 65 !!!1
>
> This runloop combines the faster dispatch of opcodes via compu
On Tue, Dec 31, 2002 at 06:32:42PM -0800, Steve Fink wrote:
> On Dec-31, Jerome Vouillon wrote:
> > The temporary objects could be stored in a stack, which is popped when
> > leaving the current function (both with normal exits and longjmp).
> > This should make it a lot less
On Mon, Dec 30, 2002 at 04:00:55PM -0800, Steve Fink wrote:
> =head1 Solution 3: Explicity root set augmentation
>
> A final possible solution is to provide a mechanism to temporarily
> anchor an otherwise unanchored object to the root set. (eg, have an
> array of objects associated with the inter
On Wed, Aug 28, 2002 at 10:36:54AM -0700, Larry Wall wrote:
> That is a worthy consideration, but expressiveness takes precedence
> over it in this case. DFAs are really only good for telling you
> *whether* and *where* a pattern matches as a whole. They are
> relatively useless for telling you
On Sat, Aug 03, 2002 at 01:42:06AM -0400, Melvin Smith wrote:
> Here is an attempt. I'm assuming the stack of pads is a singly-linked list
> of pads with children pointing to parents, and multiple children can refer
> to the same parent. If they are created on the fly, the creation of
> a Sub or C
On Fri, Aug 02, 2002 at 09:06:31PM +0100, Nicholas Clark wrote:
> On Fri, Aug 02, 2002 at 06:43:49PM +0200, Jerome Vouillon wrote:
> > Allocating a hash will certainly remain a lot more expensive than
> > allocating an array. And we are going to allocate pads pretty
> > oft
On Fri, Aug 02, 2002 at 08:50:27AM -0700, Sean O'Rourke wrote:
> On Fri, 2 Aug 2002, Jerome Vouillon wrote:
>
> > On Thu, Aug 01, 2002 at 10:57:34AM -0700, Sean O'Rourke wrote:
> > > My naive implementation would have an array of hashes for each sub, with
> >
On Tue, Jul 30, 2002 at 09:07:11PM -0700, Sean O'Rourke wrote:
> - take a look at "new" in core.ops. Creating a new continuation captures
> context, but the register holding that continuation is part of the
> context. Unfortunately, it doesn't know what register it's in until after
> it captures
On Thu, Aug 01, 2002 at 10:57:34AM -0700, Sean O'Rourke wrote:
> My naive implementation would have an array of hashes for each sub, with
> one entry for each level of scope within.
I would use an array of arrays or a linked-list of arrays. This is
hardly more difficult to implement (you just ne
On Wed, Jul 31, 2002 at 11:40:39AM -0600, Jonathan Sillito wrote:
> So here is my take on a slightly simpler example:
>
> sub foo {
> my $x = 13;
> return sub { print "$x\n"; };
> }
>
> $foo()
Melvin, I think it would really help if you could explain us how you
would compile this
On Wed, Jul 31, 2002 at 11:22:56PM -0400, Melvin Smith wrote:
> At 06:25 PM 7/31/2002 +0200, Jerome Vouillon wrote:
> >Closures
> >
> > A subroutine must have access to the scratchpads of all the
> > englobing blocks. As the scratchpads are linked, it is sufficient
&
On Wed, Jul 31, 2002 at 11:40:39AM -0600, Jonathan Sillito wrote:
> new_pad # push this on the lexical stack
> # some constant descriptor should also be passed
> # to the new_pad op which would then know about
> # the lexical variable 'x', and would
Let us think a bit about the implementation of lexical variables.
Assignement
First, let us consider how to compile a variable assignement such
as:
$x = $y
where both $x and $y are lexical variables. At first, one may think
that this can be compiled simply into a register assignme
On Fri, Jun 21, 2002 at 06:22:40PM -0400, Melvin Smith wrote:
> At 10:22 PM 6/21/2002 +0200, Jerome Vouillon wrote:
> >Ok. Then, you should do the converse to what you are mentionning in
> >your patch: instead of inlining a context in the interpreter structure
> >(Parrot_In
On Fri, Jun 21, 2002 at 02:33:33PM -0400, Melvin Smith wrote:
> Now, if you look at it and say we can do a "lightweight"
> interpreter, I think that is what I'm trying to accomplish, but I'm
> calling it Parrot_Context.
Ok. Then, you should do the converse to what you are mentionning in
your pat
On Fri, Jun 21, 2002 at 12:49:27PM -0400, Melvin Smith wrote:
> >- Each co-routine should probably have its own interpreter.
>
> I'm not sure about this one. I think we can accomplish it without
> the full overhead of a new interpreter.
I don't understand. It should not be much more expansive t
On Thu, Jun 20, 2002 at 12:26:11AM -0400, Melvin Smith wrote:
> Given that it seems capturing and restoring a context is the most
> expensive part, should we make default routines lightweight (execute
> on caller stack rather than getting their own) and only make
> continuations and co-routines ta
On Mon, Jun 17, 2002 at 04:59:05PM -0400, Melvin Smith wrote:
> The hole I see is not having a Perl6 grammar to toss about.
> You must sift through the apoc/exe pile to formulate it. Regardless of
> which approach is taken, I'd like to see a BNF style grammar floating around
> before we talk tools
On Sun, Jun 09, 2002 at 05:18:31PM -0400, Dan Sugalski wrote:
> Who says we're only using callcc to capture continuations? We can do
> it anywhere, so we potentially need the registers stored so we can
> properly restore state when we're invoked.
I don't understand what you mean. In scheme, ca
On Sat, Jun 08, 2002 at 02:29:53PM -0400, Dan Sugalski wrote:
> There's more than just exception handlers going on the control stack.
> Anything that needs rolling back or undoing (like localized variables
> or scope entry) will have an undo marker put on the control stack
> that gets called wh
On Sat, Jun 08, 2002 at 03:54:06PM -0400, Melvin Smith wrote:
> At 02:36 PM 6/8/2002 -0400, Dan Sugalski wrote:
> >At 8:15 PM +0200 6/8/02, Jerome Vouillon wrote:
> >>On Sat, Jun 08, 2002 at 12:30:36PM -0400, Melvin Smith wrote:
> >>> The Java VM does this by popping
On Sat, Jun 08, 2002 at 02:34:19PM -0400, Dan Sugalski wrote:
> Indirect function calls will take maybe 50 cycles, so I'm not worried
> about their time. Compared to perl 5, that's fast.
With a JIT compiler, this starts to be significant, though.
> >A continuation can be invoked just like any o
On Sat, Jun 08, 2002 at 02:39:33PM -0400, Dan Sugalski wrote:
> >Instead of using some space on the stack, co-routines can store all
> >their local variables into their closure. Then, there is no need to
> >swap in any context.
>
> You still need to store the stack frames created since the start
On Sat, Jun 08, 2002 at 03:35:39PM -0400, Melvin Smith wrote:
> At 08:30 PM 6/8/2002 +0200, Jerome Vouillon wrote:
> >Instead of using some space on the stack, co-routines can store all
> >their local variables into their closure. Then, there is no need to
> >swap in any con
On Fri, Jun 07, 2002 at 07:40:14PM -0400, Melvin Smith wrote:
> The support isn't complete, for example, co-routines, etc. need to
> swap in their own context, which right now they don't do.
Instead of using some space on the stack, co-routines can store all
their local variables into their closu
On Sat, Jun 08, 2002 at 12:20:55PM -0400, Melvin Smith wrote:
> At 09:50 AM 6/8/2002 +0200, Jerome Vouillon wrote:
> >Alternatively, I think you can just replace the definition of yield
> >by:
> >
> >inline op yield (in INT) {
> > struct Parrot_Sub * su
On Sat, Jun 08, 2002 at 12:30:36PM -0400, Melvin Smith wrote:
> Right now all it [ret] does is pop the return address from the global
> interpreter control stack, but continuations, etc. will have their own
> control stack, so they must restore the caller's before returning.
Continuations never r
On Fri, Jun 07, 2002 at 01:50:27AM -0400, Dan Sugalski wrote:
> So, in total, we need:
>
> *) Original routine entry point
> *) Current routine entry point
> *) Native/bytecode flag
> *) Opcode table
> *) Global namespace chain
> *) "default" lexical scope
> *) All the register sets
> *) All the
On Sat, Jun 08, 2002 at 01:15:48AM -0400, Dan Sugalski wrote:
> First, we need to beef up ret, but that's a problem of definition. It
> should walk the control stack until it hits something it can return,
> so we can undo exception handler pushes, scope change, and suchlike
> things. (My proble
On Wed, Jun 05, 2002 at 04:52:22PM -0400, Dan Sugalski wrote:
> Could be wrong, of course. Wouldn't be the first time. I'll need more
> convincing for that, though.
Is this enough? :)
Stack usage
===
First, the stack are going to be used quite heavily: we need to save
all live registers
On Wed, Jun 05, 2002 at 12:07:26PM -0700, Sean O'Rourke wrote:
> Another thing to toss into the discussion, preferably sooner rather than
> later: continuations. From what I can tell, implementing continuations
> relies on having an arbitrary graph of "stack" frames, and garbage
> collecting them
My feeling is that the current implementations of stacks are not
adequate:
- the control stacks store too many registers at once;
- the generic stack is typed, so it is slow;
- none of these stacks provide any support for register
spilling/reload: there is no opcode to get or set the
n-th ele
On Wed, May 29, 2002 at 02:08:25AM -0400, Mike Lambert wrote:
> gc_generations.pbc
> me trying to simulate behavior which should perform exceptionally
> well under a genertaional collector, even though we don't have one :)
> each memory allocation lasts either
> a long time, a medium time, or
On Wed, May 29, 2002 at 11:45:45AM -0500, David M. Lloyd wrote:
> Dan may have been referring to the fact that on some key platforms
> (Solaris included) (sig)setjmp/longjmp are officially marked as unsafe for
> use inside of threads.
Is it really unsafe on these platforms?
- According to the Uni
On Tue, May 28, 2002 at 11:02:05AM -0400, [EMAIL PROTECTED] wrote:
> I also agree its funny we are worrying
> about performance when its not apparent
> the allocation overhead even has anything
> to do with the current performance problem.
I don't think performance is really the issue here. Rath
On Tue, May 28, 2002 at 05:47:56PM -0700, Hong Zhang wrote:
> > Important given: We can *not* use setjmp/longjmp. Period. Not an
> > option--not safe with threads. At this point, having considered the
> > alternatives, I wish it were otherwise but it's not. Too bad for us.
>
> I think this stat
On Wed, May 29, 2002 at 02:08:25AM -0400, Mike Lambert wrote:
> gc_alloc_new.pbc
> allocates more and more memory
> checks collection speed, and the ability to grow the heap
>
> gc_alloc_reuse.pbc
> allocates more memory, but discards the old
> checks collection speed, and the ability to reclaim
On Mon, May 27, 2002 at 08:41:59AM -0700, Sean O'Rourke wrote:
> Since our memory-allocating routines return NULL quite a ways back up the
> call chain (all the way through e.g. string_grow()), here's another way to
> do this -- if allocation returns NULL all the way to an op function, it
> can ma
On Tue, May 28, 2002 at 07:54:49AM -0700, Robert Spier wrote:
>
> >#define PARROT_str_local(d)\
> > STRING * d = NULL; \
> > frame frame_##d;\
> > int dummy_##d = ( \
> > (frame_##d.ptr = &d), \
> > (
On Tue, May 28, 2002 at 03:45:58PM +0200, Jerome Vouillon wrote:
> On Tue, May 28, 2002 at 08:30:52AM -0400, Mike Lambert wrote:
> > PARROT_str_params_3(a, b, c);
> > What's the point of this? With rule 5 that prevents function call nesting,
> > you're guarant
On Tue, May 28, 2002 at 08:30:52AM -0400, Mike Lambert wrote:
> Can you provide an implementation of the macros you described above? I
> have a few concerns which I'm not sure if they are addressed. For example:
#define PARROT_start() \
frame * saved_top = stack_top;
> PARROT_str_loca
On Tue, May 28, 2002 at 04:57:01AM -0700, Brent Dax wrote:
> I assume the lack of mentions of Buffers are an oversight.
Right. It would be great if there was only one kind of parrot objects...
> # (5) do not nest function calls
> #(for instance, "e = string_concat (string_concat(a, b
I propose the following alternate guidelines.
First, the code would look something like this:
STRING * concat (STRING* a, STRING* b, STRING* c) {
PARROT_start();
PARROT_str_params_3(a, b, c);
PARROT_str_local_2(d, e);
d = string_concat(a, b);
e = string_concat(d, c);
On Tue, May 28, 2002 at 04:45:06AM -0400, Mike Lambert wrote:
> When you call new_*_header, the neonate
> flag is automatically turned on for you. As a programmer writing a
> function, you explicitly turn off the neonate flag when you attach it to
> the root set, or let it die on the stack. If you
On Mon, May 27, 2002 at 04:33:07PM -, Peter Gibbs wrote:
> These changes do cause a slight performance degradation, but I believe it is
> worth it for the overall simplification of transparent protection of the
> newborn.
> Performance can only be a secondary goal, after correct behaviour.
Wh
On Mon, May 27, 2002 at 08:41:59AM -0700, Sean O'Rourke wrote:
> But there are two kinds of "available" here: available without asking the
> operating system for more; and available period. If we're in the first
> situation, it seems reasonable to just ask the OS for a new block and keep
> going,
On Sun, May 19, 2002 at 10:43:20PM -0400, Mike Lambert wrote:
[...]
> But if you'll notice down below in the body, it uses
> string_compare. Due to transcoding issues, that can trigger a full GC,
> which means you need to restore_invariants inside that loop. And that
> invalidates your 'chain' whi
On Sun, May 26, 2002 at 08:20:23AM -0700, Sean O'Rourke wrote:
> I'm sure it's been discussed before somewhere, but why can't we guarantee
> that we only do GC runs between ops? Each op would just have to guarantee
> that all of its persistent data is reachable before it returns. It seems
> like
On Fri, May 24, 2002 at 09:48:13AM -0400, Melvin Smith wrote:
> I hate debugging stack operations. Its one of the hardest bug's to spot
> in my limited experience. For this reason I'm glad that Parrot allows me
> to think in registers, not stack locations. Given, everything I've said
> relates
56 matches
Mail list logo
