At 9:34 PM +0100 11/5/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
[ Yet another f'up ]
..., except that it caches the top
half of the register sets
[ ... ]
copying the low half registers of the (now old)
Dan, the split in lower and upper half of registers was a premature
o
Dan Sugalski <[EMAIL PROTECTED]> wrote:
[ Yet another f'up ]
> ..., except that it caches the top
> half of the register sets
[ ... ]
> copying the low half registers of the (now old)
Dan, the split in lower and upper half of registers was a premature
optimization with zig opcodes to address t
Piers Cawley <[EMAIL PROTECTED]> wrote:
> The catch with generation GC is that, once you have guaranteed
> destructors being called promptly, you still have to sweep the whole
> arena every time you leave a scope.
Yes. I hope that we can track objects needing timely destruction
directly. We have
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:39 AM +0100 11/5/04, Leopold Toetsch wrote:
>>The cache misses are basically in two places
>>
>>a) accessing a new register frame and context
>>b) during DOD/GC
> b) is relatively easy -- I'd bet that the vast majority of the cache
> misses are becau
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 05, 2004 at 09:16:36AM +0100, Leopold Toetsch wrote:
>>
>> So, pbc2cc.pl needs just to hexify that image. And the entry point
> hexify? IIRC the fastest compilable representation of arbitrary byte blocks
> we found for perl 5 was how Encode d
At 11:39 AM +0100 11/5/04, Leopold Toetsch wrote:
The cache misses are basically in two places
a) accessing a new register frame and context
b) during DOD/GC
b) is relatively easy -- I'd bet that the vast majority of the cache
misses are because of the copying collector. That could be cleared up
Sam Ruby wrote:
I have a simple unit test[1], one that was not intended to be a
benchmark.
I probably should have included the following in my email *blush*:
[1] http://intertwingly.net/stories/2004/11/05/parrot/t/dynclass/pyint.t
- Sam Ruby
Dan Sugalski wrote:
At 3:49 PM -0500 11/4/04, Sam Ruby wrote:
Background: Pmc2c.pm emits code which references Parrot_PMC_typenum.
This code is present in libparrot.so, which currently is not
referenced as a library by the link step for dynclasses.
Options include:
1) eliminating this dependen
Miroslav Silovic <[EMAIL PROTECTED]> writes:
> Leopold Toetsch wrote:
>
>>> I believe that you shouldn't litter (i.e. create an immediately
>>> GCable object) on each function call - at least not without
>>> generational collector specifically optimised to work with this.
>>
>>
>> The problem isn'
On Nov 4, 2004, at 10:30 PM, Brent 'Dax' Royal-Gordon wrote:
On Thu, 4 Nov 2004 21:46:19 -0800, Jeff Clites <[EMAIL PROTECTED]> wrote:
On Nov 4, 2004, at 8:29 PM, Brent 'Dax' Royal-Gordon wrote:
This is true. But how do you define a number? Do you include
floating-point? Fixed-point? Bignum? B
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
>> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
>>> Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
Hello,
>>>
I've been playing with closures and subs but I have a little bit of
trouble with those.
>>>
On Fri, Nov 05, 2004 at 09:16:36AM +0100, Leopold Toetsch wrote:
> Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> * a PackFile is a PMC (needed e.g. for "eval" anyway)
> * the binary representation is a frozen PackFile
>
> So, pbc2cc.pl needs just to hexify that image. And the entry point
Jeff Clites wrote:
a) As Sam says, in Python "y**z" is just shorthand for
"y.__pow__(z)"--they will compile down to exactly the same thing
(required for Python to behave correctly). Since __pow__ isn't
"special", we don't need anything to support it that we wouldn't need
for any other arbitrary
Miroslav Silovic <[EMAIL PROTECTED]> wrote:
> The problem with copying GC is that pointers can change under your feet
> at every opportunity.
Basically yes. We have that problem currently with the copying
collection of strings. Normally this is solved by keeping the old object
in place, so that p
Jeff Clites <[EMAIL PROTECTED]> wrote:
> a) As Sam says, in Python "y**z" is just shorthand for
> "y.__pow__(z)"--they will compile down to exactly the same thing
> (required for Python to behave correctly).
I don't think so (and you can replace with add, sub, ... FWIW). All these
binops compile
Leopold Toetsch wrote:
I believe that you shouldn't litter (i.e. create an immediately
GCable object) on each function call - at least not without
generational collector specifically optimised to work with this.
The problem isn't the object creation per se, but the sweep through
the *whole obje
On Nov 4, 2004, at 5:24 AM, Sam Ruby wrote:
From a Python or Ruby language perspective, infix operators are not
fundamental operations associated with specific types, they are
syntactic sugar for method calls.
A the moment, I'm compiling x=y**z into:
x = y.__pow__(z)
There is nothing "reserv
[EMAIL PROTECTED] wrote:
a) accessing a new register frame and context
b) during DOD/GC
We have to address both areas to get rid of the majority of cache
misses.
ad a)
For each level of recursion, we are allocating a new context structure
and a new register frame. Half of these is coming from the r
Michael Walter <[EMAIL PROTECTED]> wrote:
> I sense confusion between "closure", "continuation" and "coroutine".
> http://c2.com/cgi/wiki?ContinuationsAndCoroutines
and that's even referencing Dan's blog ;)
leo
Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
[ nested coroutines ]
> Do you think the above code snippet could work? That is, without much
> special code, can this be done in PIR?
As said, coroutine's (argument passing and more) behavior isn't yet
layed out and there are several possibilities for t
Luke Palmer <[EMAIL PROTECTED]> wrote:
> The question is, though, how do compilers think of it? That is, does
> the compiler have the liberty, given the code:
> $x ** $y
> To emit:
> pow $P0, x, y
> Or must it use a named multimethod?
Well, that's a thing compilers (or their writers
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Parts of this should have been done in my previous patch, but at the
> time wasn't needed. As the first to need it, I guess I get to implement
> it. ;-)
The "mmd_clone" is done only for dynclasses, I presume.
Why not create the _temp_mmd_init for dynclasses
Miroslav Silovic wrote:
[EMAIL PROTECTED] wrote:
a) accessing a new register frame and context
b) during DOD/GC
Or it would make sense to use multi-frame register chunks. I kept
locality of access in mind but somehow never spelled it out. But I
*think* I mentioned 64kb as a good chunk size precis
Below (inline/attached) is a longish analysis of fib benchmark timings.
leo
Why is the fib benchmark still slow - part 1
Python runs the fib test roughly twice as fast as Parrot. I don't
like that ;) So what's the problem?
1) CPU cache issues
First, if you like to investigate the issue yourself
Jeff Clites writes:
> On Nov 4, 2004, at 8:29 PM, Brent 'Dax' Royal-Gordon wrote:
> >This is true. But how do you define a number? Do you include
> >floating-point? Fixed-point? Bignum? Bigrat? Complex? Surreal?
> >Matrix? N registers don't even begin to encompass all the "numbers"
> >out t
Christian Aperghis-Tramoni writes:
> I have the folowing program :
>
> print "Give me an integer number : Ân"
> getstdinP0
> readline S1,P0
>
> Its execution gives :
>
> 10
> Give me an integer number :
>
> How is it possible to flush stdout before reading the number
Klaas-Jan Stol writes:
> Hello,
>
> I spoke (through email) with Roberto Ierusalimschy, one of the creators of
> the Lua programming language, and I said that Parrot has good support for
> implementing coroutines and closures (heck, they are explicitly there).
>
> However, in a reply, Roberto a
# New Ticket Created by Sam Ruby
# Please include the string: [perl #32322]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32322 >
Parts of this should have been done in my previous patch, but at the
time wasn't needed.
Piers Cawley <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>> Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
>>> Hello,
>>
>>> I've been playing with closures and subs but I have a little bit of
>>> trouble with those.
>>
>> newsub $P0, .Closure, _foo
>> $P0
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> To make this actually work we need some standards, and the ability to
>> embed bytecode segments into an executable (like, say, parrot :) so
>> they're always at hand.
> The attached patch implements
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 4:38 PM -0500 11/4/04, Matt Diephouse wrote:
>>On Tue, 2 Nov 2004 13:35:09 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>> What, think this warrants a 0.1.2 release? I'm not so sure about
>>> that. It's not that big a deal...
>>
>>In the past week,
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Since I'm about to start in on some of the Irrevocable Changes (or
> something like that) to the string system with the new
> encoding/charset stuff, I tagged CVS and will be working in a branch
> (I hope).
> If you feel like watching or playing along at h
32 matches
Mail list logo
