Crud, I forgot to attach the quicksort in the last one...
Brian
On Sat, 2002-05-25 at 21:17, brian wheeler wrote:
> On Fri, 2002-05-24 at 15:10, Sean O'Rourke wrote:
> > > I was starting with a very simple test to decide how to determine where the
> > > memory overuse was coming from,
> >
> >
On Fri, 2002-05-24 at 15:10, Sean O'Rourke wrote:
> > I was starting with a very simple test to decide how to determine where the
> > memory overuse was coming from,
>
> I'm actually looking at this now as well, though with zip2.pasm instead of
> quicksort. What I've found is that because zip co
> I was starting with a very simple test to decide how to determine where the
> memory overuse was coming from,
I'm actually looking at this now as well, though with zip2.pasm instead of
quicksort. What I've found is that because zip constructs the result with
incremental packing, and since the
"brian wheeler" wrote:
> I've written a quicksort which will sort a file on stdin. It could go
> into examples, I suppose.
> Building parrot with -pg makes it run 5s slower. The gprof -T dump of
> the timings looks like this:
I find it useful, if running on a system that normally uses the com
I've written a quicksort which will sort a file on stdin. It could go
into examples, I suppose.
System: Athlon 700 running Redhat 7.3
Parrot is using defaults
Running "./parrot quicksort.pbc < rx.ops" returns times like:
real0m34.166s
user0m5.830s
sys 0m3.840s
Which seems a bit lo
