On Wed 17 Mar 2004 02:31, Larry Wall [EMAIL PROTECTED] wrote:
On Tue, Mar 16, 2004 at 07:47:25PM -0500, Dan Sugalski wrote:
: Second, we're running over the same problems in system configuration
: that perl (and python, and ruby, for that matter) have already run
: across. Moreover, we're
Jens Rieks [EMAIL PROTECTED] wrote:
the attached program aborts if run without without -G...
$ tar xzf err6.tgz
I found three problems with that test:
1) Subs/Methods loaded by load_bytecode weren't marked
2) The regsave are of delelgate.pmc needs marking
3) It seems that your code has a
Dan Sugalski [EMAIL PROTECTED] wrote:
Looks like it may be time to investigate things further. A method
cache is probably the next thing in line to do.
Yep. The OO-version of fib spends by far the most time in callmethcc.
fib/fibA (3/4th of the calls) need 4 hash lookups currently.
leo
Simon Glover [EMAIL PROTECTED] wrote:
This code:
new P0, .PerlNum
set P0, -1.2
new P1, .PerlString
set P1, -1.2
eq_num P0, P1, OK
print not
OK: print ok\n
end
[And yes, I'm well aware of the problems inherent in doing
Mitchell N Charity [EMAIL PROTECTED] wrote:
Patch attached.
I've renamed the files to oofib sp running parrotbench -b='^oo' gets
then all. Thanks, applied.
My optimized parrot ran it a factor of 2x slower than my perls, 3x than
my ruby, with my pythons in between. Unoptimized was just a bit
Jens Rieks [EMAIL PROTECTED] wrote:
the attached test fails. It raises an exception in __init; if it is resumed
parrot exists after leaving __init.
I've now turned on again stacked exception handlers in runops(). With
this enabled, the test passes.
Thanks, added to object-meths.t
jens
leo
Should this really print ParrotClass:
newclass P0, Foo
typeof S0, P0
print S0
print \n
find_type I0, Foo
new P1, I0
typeof S0, P1
print S0
print \n
end
ParrotClass
Foo
leo
At 11:53 AM +0100 3/17/04, Leopold Toetsch wrote:
Should this really print ParrotClass:
That's a good question, and it dives into the whole
class/metaclass/object thing. If a class is an object, then it ought
to be an instance of some class, so class objects could reasonably be
instances of the
At 4:12 PM -0800 3/16/04, Larry Wall wrote:
On Tue, Mar 16, 2004 at 02:57:07PM -0500, Dan Sugalski wrote:
: Classes and roles don't automatically share the same namespace.
I think they do. I want to be able to tell the moment I compile it
whether Foo is a class or a role or (a bareword that will
Larry Wall writes:
Despite the severe overloading problems, it's really gonna be hard
to do much better than
$topic ? (.a + .b + .c)
my dog $spot ?= .new;
@array?.[.min .. .max]
And I do think people would rebel at using Latin-1 for that one.
I get enough grief
On Wed, 17 Mar 2004, Leopold Toetsch wrote:
Simon Glover [EMAIL PROTECTED] wrote:
This code:
new P0, .PerlNum
set P0, -1.2
new P1, .PerlString
set P1, -1.2
eq_num P0, P1, OK
print not
OK: print ok\n
end
[And
Okay, as I see it there are two big things that we can do to speed
objects up. (Well, besides speeding up the creation of continuation
PMCs, which I am, at the moment, sorely tempted to put in a special
pool for fast allocation) They are:
1) A method cache. Which we need anyway, so this isn't
Okay, so it's method cache time.
First important note: I've never done this before (I think my
antipathy towards objects might've given everyone just the tiniest
clue :) so pointers to good docs and papers on this would be much
appreciated.
My current thinking, based entirely on the Hmmm, if
Dan Sugalski wrote in perl.perl6.internals :
This seems... too simple, so I'm sure I'm missing something besides
the potential massive memory usage. So, by all means, have at it.
You'll need to worry about actions that invalidate all or part of the
method cache : introduction of a new class,
At 5:31 PM + 3/17/04, Rafael Garcia-Suarez wrote:
Dan Sugalski wrote in perl.perl6.internals :
This seems... too simple, so I'm sure I'm missing something besides
the potential massive memory usage. So, by all means, have at it.
You'll need to worry about actions that invalidate all or part
Might be worth looking at Smalltalk papers too - they've been doing objects
forever. If I remember correctly, some smalltalks have an interesting form
of caching: they call the last thing the call resolved to, and redispatch as
necessary. So rather than looking things up before every call,
Dan Sugalski [EMAIL PROTECTED] wrote:
Okay, as I see it there are two big things that we can do to speed
objects up. (Well, besides speeding up the creation of continuation
PMCs, which I am, at the moment, sorely tempted to put in a special
pool for fast allocation)
I though about that
I'm almost finished preparing a patch which incorporates the usage of
ICU, and makes some additional changes to the internal representation
of strings. These changes give us an internal representation model
which is a bit simpler, and is measurably faster. (More details to
follow with the
At 6:46 PM +0100 3/17/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
Okay, as I see it there are two big things that we can do to speed
objects up. (Well, besides speeding up the creation of continuation
PMCs, which I am, at the moment, sorely tempted to put in a special
pool
On Wed, Mar 17, 2004 at 12:41:20PM -0500, Dan Sugalski wrote:
: Currently I'm figuring on just nuking the whole cache in any of these
: cases. Later on we can consider doing Clever Things, if it seems
: worthwhile.
That's what Perl 5 does, FWIW. But you're caching scheme seems way
too
Something seems to be unanchored in with loadable modules. (I'm not
100% sure yet) I'm finding code that used to work OK with a bunch of
load_bytecode calls now dies at odd spots. Throwing in the -G switch
lets things run just fine to completion, so...
I'll try and dig in if I can, but I've
# New Ticket Created by Simon Glover
# Please include the string: [perl #27715]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27715
This code:
newclass P0, City
subclass P1, P0
classname S0, P1
On Wed, Mar 17, 2004 at 11:22:01AM -0500, Simon Glover wrote:
: OK, that suggests that there's a bug somewhere in our string-number
: conversion. Either that, or we're going to have to live with the fact
: that 1.2 and '1.2' are not the same number (which would suck).
The basic bug has to be
On Tue, Mar 16, 2004 at 08:13:06PM +0100, Leopold Toetsch wrote:
: Mitchell N Charity [EMAIL PROTECTED] wrote:
:
: if (value == vali (0 != vali || ...something...))
:
: Yep here it is.
:
: Do we *really* need that crap?
That depends on who we are, unfortunately.
Larry
What should these three code fragments print:
newclass P1, Foo
classname S1, P1
print S1
newclass P1, Foo
find_type I0, Foo
new P2, I0
classname S2, P2
print S2
new P3, .PerlInt
classname S3, P3
print S3
At the moment, we get:
Foo
Foo
Don't forget about cache invalidation on dynamic method redefinition.
--
Mark Biggar
[EMAIL PROTECTED]
Okay, so it's method cache time.
First important note: I've never done this before (I think my
antipathy towards objects might've given everyone just the tiniest
clue :) so pointers to
That's all fine and good, and the generic method cache will help here.
However... we can do better. What I'm thinking of is caching the
actual found method PMC pointer in the class somewhere (hanging off
the vtable or in the class' attributes or something) such that we
don't actually have to
At 2:24 PM -0500 3/17/04, Simon Glover wrote:
What should these three code fragments print:
newclass P1, Foo
classname S1, P1
print S1
newclass P1, Foo
find_type I0, Foo
new P2, I0
classname S2, P2
print S2
new P3, .PerlInt
classname S3, P3
print S3
Its the old problem of rounding errors in floating point arithmetic.
In string_to_num() in src/string.c,
f = f * sign * pow(10.0, exponent); /* ugly, oh yeah */
Which in this case translates to 12.0*-1*0.1 which is -1.2000...2 != -1.2.
I replaced this bit of code from a block I found
Dan Sugalski [EMAIL PROTECTED] wrote:
At 6:46 PM +0100 3/17/04, Leopold Toetsch wrote:
I though about that already. Returncontinuations created via the *cc
opcode variants are created in the opcode and used exactly once just for
returning from the sub. So I'd do for these a per-interpreter
Oops, use this one instead... re-fixes the exponent support...
*** tmp/parrot/src/string.c Sat Mar 6 03:00:06 2004
--- parrot/src/string.c Wed Mar 17 16:05:50 2004
***
*** 1836,1844
int exp_sign = 0;
INTVAL in_exp = 0;
INTVAL in_number = 0;
!
On Wed, Mar 17, 2004 at 04:13:40PM -0500, S. Livingston wrote:
: Oops, use this one instead... re-fixes the exponent support...
This still doesn't explain why the compiler would be using a different
routine to turn the string 1.2 into a number than the run time does.
This is not code that should
On Wed, Mar 17, 2004 at 12:06:35PM -0500, Sterling Hughes wrote:
:
: That's all fine and good, and the generic method cache will help here.
: However... we can do better. What I'm thinking of is caching the
: actual found method PMC pointer in the class somewhere (hanging off
: the vtable or
It's always nice to have numbers when planning optimizations.
So I started fiddling with oofib.imc.
It seemed like we were spending a lot of time copying strings.
So I defined the method name strings once, in main,
$S3 = fibB
and replaced calls like
self.fibB(n2)
with
self.$S3(n2)
IMCC uses atof() because it doesn't use (need?) any of the encoding
stuff. (See add_const_num() in imcc/pbc.c). Packing the cstring up
in a STRING then calling string_to_num() *fixes* the problem, but it
doesn't address the issue Larry brought up. The interpreter makes
heavy use of the encoding
Larry Wall [EMAIL PROTECTED] wrote:
The basic bug has to be that it's using two different routines to
do the conversion (or possibly there's one routine that's paying
attention to some context it shouldn't be paying attention to--but
that seems less likely).
Well, that's a very good point.
36 matches
Mail list logo
