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 poi
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 sen
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)
Optimiz
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
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
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;
!
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-interp
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 i
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
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 *d
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
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
F
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
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 t
# New Ticket Created by Simon Glover
# Please include the string: [perl #27715]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=27715 >
This code:
newclass P0, "City"
subclass P1, P0
classname S0, P1
pr
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 not
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 complicat
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
poo
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 actua
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 a
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, you
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 o
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 clas
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
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 a
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
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 n
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 th
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
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 enoug
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
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
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 inher
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
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 sl
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'
36 matches
Mail list logo
