On Tue, Feb 1, 2011 at 7:48 AM, Patrick R. Michaud wrote:
> On Mon, Jan 31, 2011 at 08:05:29PM +0100, Nick Wellnhofer wrote:
>> I hope this clarifies why there hasn't been much progress in this
>> area and why you shouldn't expect too much in 2011.
>
> I totally understand the reasons why Parrot h
Patrick R. Michaud wrote:
On Mon, Jan 31, 2011 at 11:59:44AM -0500, Peter Lobsinger wrote:
Get away from PIR (and we're
working to provide you the tools to do this), and you most likely will
not have this issue.
If I may channel Jim Keenan for a moment: Is there any estimate as
to which Parro
On 01/02/2011 17:12, Patrick R. Michaud wrote:
Okay. In this case, part of my message is "Here's a (very) small
program that shows the large delays."
It's entirely possible that this example is small in source but
has a large memory footprint... but I don't think this should
be the case. Howev
On Tue, Feb 01, 2011 at 03:11:07PM +0100, Nick Wellnhofer wrote:
> >Even in loops where there's a non-trivial amount of work taking
> >place in the body of the loop, Parrot's GC has the impact of making
> >some iterations take 10x longer than the rest.
> [...]
> Another reason for the large pauses
On 31/01/2011 21:48, Patrick R. Michaud wrote:
So there's nothing wrong with C, other than it currently
takes a lot more work to construct than C and we should
probably see about optimizing it. But the expense of C
serves very much to further the point of the demonstration:
Even in loops where
On Mon, Jan 31, 2011 at 08:05:29PM +0100, Nick Wellnhofer wrote:
> (Side note: A single iteration of the loop above seems to allocate
> about 3MB of memory. I also get:
>
> $ time ./perl6 -e -1
> real0m0.752s
> $ time ./perl6 -e 'for 1..100 { time }'
> real0m0.758s
> $ time ./perl6 -e 'for
On Tue, Feb 1, 2011 at 6:08 AM, Patrick R. Michaud wrote:
> On Mon, Jan 31, 2011 at 12:47:33PM -0600, Patrick R. Michaud wrote:
>> > Get away from PIR (and we're
>> > working to provide you the tools to do this), and you most likely will
>> > not have this issue.
>>
>> If I may channel Jim Keenan
On Mon, Jan 31, 2011 at 12:47:33PM -0600, Patrick R. Michaud wrote:
> > Get away from PIR (and we're
> > working to provide you the tools to do this), and you most likely will
> > not have this issue.
>
> If I may channel Jim Keenan for a moment: Is there any estimate as
> to which Parrot release
On 31/01/2011 15:56, Patrick R. Michaud wrote:
1. GC. Although GC has much improved, it's still fairly slow
in places, especially when mark/sweep occurs. The effect can
be observed by running the following program in Rakudo:
my $time = now.x;
for 1..300 -> $step {
On Mon, Jan 31, 2011 at 11:59:44AM -0500, Peter Lobsinger wrote:
> On Mon, Jan 31, 2011 at 9:56 AM, Patrick R. Michaud
> wrote:
> > 3. Serialization. The major item that makes Rakudo startup so slow
> > is that we have to do so much initialization at startup to get
> > Rakudo's type syste
On Mon, Jan 31, 2011 at 9:56 AM, Patrick R. Michaud wrote:
> 3. Serialization. The major item that makes Rakudo startup so slow
> is that we have to do so much initialization at startup to get
> Rakudo's type system and setting in place.
>There's not a good
> way in Parrot to reliab
At Saturday's Parrot Developer Summit [1], I agreed to write up a
post addressing what Rakudo needs from Parrot over the next 3/6/9/12
month period. This is that posting.
[1] http://irclog.perlgeek.de/parrotsketch/2011-01-29
But before I address what Rakudo needs from Parrot for the future,
I
12 matches
Mail list logo
