Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Interesting. However... the two programs aren't equivalent. You're
> using constant values and putting results onto an existing data
> structure in perl, so true 'equivalence' requires a few changes to
> the source. With those in place, I get the following:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> SArray and Array PMCs, in addition to being sparse (which has some
> overhead), allow you to really store PMC *, STRING *, INTVAL, and
> NUMVAL entries, which means that each slot in an SArray and Array
> needs to have a flag on it that says what data type
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> One thing that can help in our sub calling is to keep IMCC from
> unconditionally saving all the registers. It does that now, which is
> fine, but there's no need to do a full restoretop/savetop between
> calls when there haven't been any changes to some of
Joe Wilson <[EMAIL PROTECTED]> wrote:
> Perl's arrays do indeed accept mixed data types (see example below).
Perl's Arrays take SV's. Please use a PerlArray instead of SArray.
Parrot (still built unoptimized) is significantly faster then perl5 on this
test.
leo
Joe Wilson <[EMAIL PROTECTED]> wrote:
> $ time parrot -j f6.pasm
> 21001094.10 (note: wrong result and slower with jit)
I don't get a slow down nor a wrong result (i386/linux). On what
platform do you test?
leo
Joe Wilson <[EMAIL PROTECTED]> wrote:
> I implemented the same variable argument function "varargs_adder"
> in both Perl 5 (addit.pl) and Parrot (f4.pasm).
I've put in the addit benchmarks and some variations of it:
- addit.pl ... as of Joe Wilson
- addit.pasm .. ditto but use PerlArray
- addit.im
# New Ticket Created by Peter Gibbs
# Please include the string: [perl #24769]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=24769 >
Attached is a patch to add a function 'mem_sys_allocate_executable", to
allocate memory w
Peter Gibbs (via RT) wrote:
Attached is a patch to add a function 'mem_sys_allocate_executable",
All comments welcome.
I'd really like to have these kind of functions in platform code. Some
memory handling functions that manage a pool of such memory and handle
out small chunks would be fine in
- Original Message -
From: "Leopold Toetsch" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, December 28, 2003 2:24 PM
Subject: Re: [perl #24769] [PATCH] mem_sys_allocate_executable - initial
draft
> Peter Gibbs (via RT) wrote:
>
> > Attached is a patch to add a function 'mem_sy
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> when doing a make realclean in the 'parrot' directory, I noticed that the
> file 'vtable.dump' isn't cleaned up.
> I added the removal of vtable.dump in config/gen/makefiles/classes.in.
Thanks, applied,
leo
Okay, now that we're getting more into extensions and NCI access, we
need to add an extra array to the root set of the interpreter. The
purpose of this array is to root PMCs that are passed into external
libraries and may not be in any of the current root set members (the
stacks, registers, sys
Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> The other question is does Parrot care about the memory being zero'd out?
Isn't necessary. Executable mem is filled with ops anyway. Currently it
is zeroed to aid debugging a bit. It should be filled up with trap
operations of some kind finally I t
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Okay, now that we're getting more into extensions and NCI access, we
> need to add an extra array to the root set of the interpreter.
> ... (A PMC may be in the registry multiple times, and if so
> each unregister removes *one* reference)
> It's fine for
At 9:14 PM +0100 12/28/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Okay, now that we're getting more into extensions and NCI access, we
need to add an extra array to the root set of the interpreter.
... (A PMC may be in the registry multiple times, and if so
each unregis
Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
It's fine for this to be a simple array for now. I realize that means
O(n) access times,
I'd use a custom hash with the PMC address being the key[1]. /Me thinks, it
doesn't help, when a PMC gets registered multiple times - its
At 3:27 PM -0500 12/28/03, Matt Fowles wrote:
Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
It's fine for this to be a simple array for now. I realize that means
O(n) access times,
I'd use a custom hash with the PMC address being the key[1]. /Me thinks, it
doesn't help, when
- Original Message -
From: "Leopold Toetsch" <[EMAIL PROTECTED]>
To: "Jonathan Worthington" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, December 28, 2003 6:36 PM
Subject: Re: [perl #24769] [PATCH] mem_sys_allocate_executable - initial
draft
> Jonathan Worthington <[EMAIL PRO
On Mon, 29 Dec 2003 09:14, Leopold Toetsch wrote;
> I'd use a custom hash with the PMC address being the key[1]. /Me
> thinks, it doesn't help, when a PMC gets registered multiple times
> - its always the same address - removing it multiple times is
> fine, the first succeeds, following fa
On Dec 28, 2003, at 1:42 AM, Leopold Toetsch wrote:
Joe Wilson <[EMAIL PROTECTED]> wrote:
Perl's arrays do indeed accept mixed data types (see example below).
Perl's Arrays take SV's. Please use a PerlArray instead of SArray.
Parrot (still built unoptimized) is significantly faster then perl5 on
On Mon, 29 Dec 2003 09:27, Matt Fowles wrote;
> Why not just have the hash value be an integer, then each register
> increments it and each unregister decrements it. With the entry
> getting removed if it hits 0.
Apologies for spamming the thread with mention of Set::Object again :)
But i
Dan Sugalski wrote:
At 3:27 PM -0500 12/28/03, Matt Fowles wrote:
Leopold Toetsch wrote:
I'd use a custom hash with the PMC address being the key[1]. /Me
thinks, it
doesn't help, when a PMC gets registered multiple times - its always
the
same address - removing it multiple times is fine, the f
At 7:19 PM -0500 12/28/03, Matt Fowles wrote:
Dan Sugalski wrote:
At 3:27 PM -0500 12/28/03, Matt Fowles wrote:
Leopold Toetsch wrote:
I'd use a custom hash with the PMC address being the key[1]. /Me thinks, it
doesn't help, when a PMC gets registered multiple times - its always the
same address
Leopold Toetsch wrote:
Jonathan Worthington <[EMAIL PROTECTED]> wrote:
The other question is does Parrot care about the memory being zero'd out?
Isn't necessary. Executable mem is filled with ops anyway. Currently it
is zeroed to aid debugging a bit. It should be filled up with trap
operations o
On Dec 28, 2003, at 6:35 PM, Mark A. Biggar wrote:
Leopold Toetsch wrote:
Jonathan Worthington <[EMAIL PROTECTED]> wrote:
The other question is does Parrot care about the memory being zero'd
out?
Isn't necessary. Executable mem is filled with ops anyway. Currently
it
is zeroed to aid debugging a
24 matches
Mail list logo
