Hope no one minds me essentially reposting this email. :)
> Am I correct in assuming that the stacks stuff leaks memory? Both stacks.c
> and rxstacks.c allocate memory via mem_allocate_aligned, but never free
> it, relying on the GC for it (code written before the GC existed).
There was a frame
Here it is. You can cut all of the Cola support __* subs
except __strlen or just replace the bsr __strlen with the actual
op.
-Melvin
# Cola (0.0.4) generated
#
_START:
save ""
bsr __Main
__END:
end
__Generate: pushi
pushs
push
At 02:08 PM 4/12/2002 -0400, Dan Sugalski wrote:
>At 12:49 PM +0200 4/12/02, Paolo Molaro wrote:
>>On 04/11/02 Dan Sugalski wrote:
>>> I'm not sure which is worse--the amount of data we're copying around,
>>> or the fact that we eat Mono's lunch while we do so.
>>
>>:-)
>>Could you post the code
sorry, the body of that message got lost:
parrot is a cool technology, but it's s buzzword-lacking. well,
here's the solution: xml based assembler!
--
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There's a crack in everything.
It's how the light gets in.
-Is
PML.tar.gz
Description: Binary data
Dan Sugalski wrote:
> I think perhaps a rewrite of life.pasm into perl with some
> benchmarking would be in order before making that judgement.
Following is a rough perl5 version of life.pasm.
On my system [Pentium 166; linux 2.2.18; perl 5.6.1] this takes 96 to 97
seconds; CVS parrot takes 91 t
On Wed, Apr 10, 2002 at 06:29:30PM -0400, Roman Hunt wrote:
> Hey guys:
> Here is what I have so far of the string_nprintf function. As of now it
> only handles C string backslash escape sequences and regular chars
> from the format string. My primary concern is whether I am using
> +
At 12:49 PM +0200 4/12/02, Paolo Molaro wrote:
>On 04/11/02 Dan Sugalski wrote:
>> I'm not sure which is worse--the amount of data we're copying around,
>> or the fact that we eat Mono's lunch while we do so.
>
>:-)
>Could you post the code for the sample?
Simon did a one-for-one translation of
At 8:09 AM -0400 4/12/02, Michel J Lambert wrote:
>
>Few things immediately come to mind:
>a) with the current encoding system, we're guaranteed to be slower than
>without it. If we want Parrot to be as fast as Perl5, we're deluding
>ourselves.
I think perhaps a rewrite of life.pasm into perl wit
On Friday 12 April 2002 08:21 am, Michel J Lambert wrote:
> > I thought the point of the discussion was turning off the GC until such
time
> > that it was ready to go. I know what it *does* - what should it *do*?
> >
> > {Rest of the comments snipped.}
>
> I don't know quite what you mean by wh
> I thought the point of the discussion was turning off the GC until such time
> that it was ready to go. I know what it *does* - what should it *do*?
>
> {Rest of the comments snipped.}
I don't know quite what you mean by what 'should it *do*'? *do*, as in
what it should do with my patch? Or *d
> compared to a current CVS version of:
> 5000 generations in 90.813806 seconds. 55.057708 generations/sec
> A total of 32768 bytes were allocated
> A total of 130932 DOD runs were made
> A total of 10930 collection runs were made
> Copying a total of 57801936 bytes
>
> so a 97% decrease in the nu
On Friday 12 April 2002 03:22 am, Michel J Lambert wrote:
> > > So you're saying that the calls to get memory during interpreter
> > > initialization are somehow guaranteed to not require more memory (and
thus
> > > a dod or collection run)? Currently, this guarantee is not expressed in
> >
> > I
On 04/11/02 Dan Sugalski wrote:
> I'm not sure which is worse--the amount of data we're copying around,
> or the fact that we eat Mono's lunch while we do so.
:-)
Could you post the code for the sample? Is it based on the snipped Simon
posted a while ago where it used the pattern:
strin
"Michel J Lambert" wrote:
> Below is a patch which allocates the pools from system memory.
> Unfortunately, it doesn't seem to provide any noticeable speed gains. I
> get anywhere from a -1 to 15 extra generations per second. Current results
Even though we copy large amounts of memory around, ve
> The current design never shrinks the free header pools, and indeed there is
> probably little point in doing so, so nothing seems to be gained from
> including them in the collection process.
>
> Using my favourite 5000-generation life.pasm as an example:
> A total of 10930 collection runs were
The string_grow function (currently used only by string_replace) does not
allocate a new buffer if there are no bytes to be copied from old buffer to
new buffer. Patch below fixes this.
--
Peter Gibbs
EmKel Systems
Index: string.c
=
Michel J Lambert wrote:
> Right. However, that's not to say that memory cannot grow. The interpreter
> allocates the various *_pools from the interpreter's memory_pool, and it
> gets copied with each collection run. This memory can grow and change in
> size as more memory for pools are needed. Cu
> > So you're saying that the calls to get memory during interpreter
> > initialization are somehow guaranteed to not require more memory (and thus
> > a dod or collection run)? Currently, this guarantee is not expressed in
>
> I don't understand the "thus." Nothing states that requesting memory
19 matches
Mail list logo
