At 11:19 AM +0100 4/17/04, Piers Cawley wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
Aaron Sherman <[EMAIL PROTECTED]> wrote:
On Fri, 2004-04-16 at 18:18, Leopold Toetsch wrote:
Sorry, I gave the wrong impression. I meant it looks suspiciously like
Python is doing a lazy construction on
Piers Cawley wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
These two memcpys are the most heavy part of the operation.
Maybe we should rethink that then and make allocation and
initialization two different phases. Or dictate that
new PObj, IClass
should be treated as if it were a funct
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Aaron Sherman <[EMAIL PROTECTED]> wrote:
>> On Fri, 2004-04-16 at 18:18, Leopold Toetsch wrote:
>
>> Sorry, I gave the wrong impression. I meant it looks suspiciously like
>> Python is doing a lazy construction on those objects, not that there is
>> an
Jeff Clites <[EMAIL PROTECTED]> wrote:
> BTW, I'm failing a bunch of tests now (Mac OS X); not sure if it's
> related:
Fixed. It was caused by the faster PMC creation code I've put in earlier
in the week, if ARENA_DOD_FLAGS is off (e.g. due to missing memalign).
Thanks for reporting,
leo
Jeff Clites <[EMAIL PROTECTED]> wrote:
> BTW, I'm failing a bunch of tests now (Mac OS X); not sure if it's
> related:
> t/op/gc.NOK 11# Failed test (t/op/gc.t at line 219)
> # got: 'get_pmc_keyed_str() not implemented in class
> 'RetContinuation''
Have that now too
On Apr 16, 2004, at 11:19 PM, Jeff Clites wrote:
BTW, I'm failing a bunch of tests now (Mac OS X); not sure if it's
related:
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/op/gc.t
Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Apr 16, 2004, at 9:29 AM, Leopold Toetsch wrote:
>> $ ./bench -b=^oo[234f]
> Looks cool!
Yep.
> BTW, I'm failing a bunch of tests now (Mac OS X); not sure if it's
> related:
Strange. valgrind doesn't indicate any problem with these tests.
> I'll po
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> On Fri, 2004-04-16 at 18:18, Leopold Toetsch wrote:
> Sorry, I gave the wrong impression. I meant it looks suspiciously like
> Python is doing a lazy construction on those objects, not that there is
> anything wrong with the benchmark.
No, I don't think
On Apr 16, 2004, at 9:29 AM, Leopold Toetsch wrote:
With all current optimizations[1] I now have these timings:
$ ./bench -b=^oo[234f]
Numbers are relative to the first one. (lower is better)
p-j-Oc perl-th perlpython ruby
oo2 100%182%152%90% 132%
oo3 100%
On Fri, 2004-04-16 at 18:18, Leopold Toetsch wrote:
> Aaron Sherman <[EMAIL PROTECTED]> wrote:
>
> > That looks suspicious... especially Python.
>
> You have the sources in examples/benchmarks. Maybe we are comparing
> apples and oranges. But the code looks good to me.
Sorry, I gave the wrong im
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> That looks suspicious... especially Python.
You have the sources in examples/benchmarks. Maybe we are comparing
apples and oranges. But the code looks good to me.
> I would suggest using iterations that go much longer so that you can
> detect over-optim
On Fri, 2004-04-16 at 12:29, Leopold Toetsch wrote:
> With all current optimizations[1] I now have these timings:
>
> $ ./bench -b=^oo[234f]
> Numbers are relative to the first one. (lower is better)
> p-j-Oc perl-th perlpython ruby
> oo2 100%182%152%90% 132%
> o
12 matches
Mail list logo
