Re: Configure.pl and the history of the world
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 making the same decisions, only... : differently. This is silly both because we're re-inventing the wheel : and we're making the wheel with metric nuts instead of english. : : We could go dig through perl's configure every time we add a new : environment probe, but that'll get really old really quick. Instead, : what I'd like is for someone (Oh, Brent... :) to go through perl's : configure and dig out the tests in it, as well as the defaults that : it has and just get all the config variables in once and for all. : While some of what's in there we don't have to deal with (joys of C89 : as a minimum requirement) there's a lot of hard-won platform : knowledge in there and ignoring it's foolish. Er, yes, but...you might actually do better by looking at all the metaconfig units that go into generating Configure. Then you'd at least know what all the dependencies are. Better even, the metaconfig units are loaded with comments that do not make it to the final Configure script. Oh, and metaconfig will gladly do the work of weeding out the tests you're not interested in. But the metaconfig units still hold the code and comment, so you don't have to #ifdef/comment-out those unwanted parts and clutter the code Not using metaconfig (or something like it) would be the biggest mistake. It's actually next to impossible to maintain something like a Configure script directly. Who would maintain it? I've got no problem (yet) with maintaining it for perl5, and I'm even working on backward compatibility for 5.005._xx, so Configure and hints are usable for the complete actual range, and thus save huge amounts of backporting time The problem is that there are only a few knowledgable/interested in doing this, ehh, less interesting part of the project (I still like it) Larry -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.8.0, 5.9.x, and 806 on HP-UX 10.20 11.00, 11i, AIX 4.3, SuSE 8.2, and Win2k. http://www.cmve.net/~merijn/ http://archives.develooper.com/[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: [BUG] GC problem
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 slight bug (which I'm not too sure because I don't know exactly what it's supposed to do) Anway, inserting one line in EBNF/Source.imc:150 lets it run with above fixes w and w/o -t, --gc-debug. NO_EOF: set str, buffer # str is a reference to the original string property # running with or w/o DOD differs here clone str, str # concat str, stmp set i, pos Thanks again for your test code leo
Re: Object internal switchover done
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
Re: [perl #27690] Numeric comparison bug
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 floating point comparisons. Breakpoint 1, Parrot_PerlNum_cmp_num (interpreter=0x82654f0, pmc=0x40305850, value=0x40305838) at perlnum.c:301 301 diff = PMC_num_val(pmc) - VTABLE_get_number(interpreter, value); (gdb) n 302 return diff 0 ? 1 : diff 0 ? -1 : 0; (gdb) p diff $1 = 2.2204460492503131e-16 (gdb) Simon leo
Re: [PATCH] Re: Object internal switchover done
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 worse. (However, caveat, my optimized parrot doesn't pass make test.) A quick look at a profile (*** always a dangerous practice ***) seemed _vaguely_ like half method calls, and half memory management. parrot -p shows 0.4s callmethodcc 0.2s DOD 0.08 next slower With method calls split between lookup (spent in hash), and creating return continuation pmcs. Yep. I thought it curious 1/10+ of time seemed spent under Parrot_set_s_sc, when there's nary a string to be seen. Method names? Yes + DOD (parrot -o- foo.imc shows generated code) leo
Re: [BUG] exceptions and different runloops
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
typeof ParrotClass
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
Re: typeof ParrotClass
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 class ParrotClass. Anyone got a good reason to not put off the decision for a while? :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Classes and metaclasses
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 not succeed in being either). Roles are just funny packages, just like classes, modules, and er, packages. Only if you mix up the implementation and promise, which we're not doing at this level. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Mutating methods
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 for «...». :-) Larry How about - which is not overloaded by boolean connotations and is sort of ? turned by 90 degrees . $topic- (.a + .b + .c) my dog $spot- = .new @array- .[.min .. .max] arcadi
Re: [perl #27690] Numeric comparison bug
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 yes, I'm well aware of the problems inherent in doing floating point comparisons. Breakpoint 1, Parrot_PerlNum_cmp_num (interpreter=0x82654f0, pmc=0x40305850, value=0x40305838) at perlnum.c:301 301 diff = PMC_num_val(pmc) - VTABLE_get_number(interpreter, value); (gdb) n 302 return diff 0 ? 1 : diff 0 ? -1 : 0; (gdb) p diff $1 = 2.2204460492503131e-16 (gdb) 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). Simon
Optimizations for Objects
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 any surprise 2) Pre-figuring the delegated vtable functions. #1 is a pretty straightforward thing, I'll detail my scheme in a bit. #2 is where I think we can get some wins, though without a notification system it's a bit dodgy. (A fixable one, though) What I'm considering for a vtable method-specific cache is pretty straightforward. When we build a class we allocate a new vtable for it, though the vtable's essentially just a clone of the delegate vtable. Make a call and we do a method lookup and then call it. 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 *do* any method lookups. With the method PMC directly cached, we just call the darned thing and are done with it. No lookups at all, something definitely faster than actually looking anything up. At the moment I'm considering two storage schemes for the PMC pointers (one hanging off the vtable itself, another in the class attributes) but I'm open to suggestions here. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Method caches
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 I had no clue there was any history here, what would I do? school of design, is to do this: Method cache is an array of arrays of cache entries. Top level index is the class number. Second level index is bits 2-10 of the method name string (the actual string, mind--we use the bufstart address) shifted right two bits to give us a single byte offset. Third is a set of structs that look like: bufaddr string (maybe) pmc ptr next When we get to the list, we run through it looking for entries that match. If we find one, yay, we're done. If not, we do a slow search, find the entry, and put it in the cache. This presupposes that the method names are all constant, shared strings. I think this is reasonable, and I'm OK adding in some code to the namespace store to make *sure* that it's the case. 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. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Method caches
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, of a new method, modification of the inheritance hierarchy, destruction of a whole class. Not mentioning autoloaded methods.
Re: Method caches
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 of the method cache : introduction of a new class, of a new method, modification of the inheritance hierarchy, destruction of a whole class. Not mentioning autoloaded methods. 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. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Optimizations for Objects
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 make the same call as last time, and the called routine does: a) are we supposed to be here? (presumed to be cheaper) b) if not, redispatch and re-cache (presumed to be more expensive) c) main method body I'm not sure if that's apropos, but I thought it was quite clever when I first read about it. Searching the web for [smalltalk cache] pulls up some interesting info and discussions. Zellyn
Re: Optimizations for Objects
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 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 freelist, where they get put back after invokeing the return contination. 1) A method cache. Which we need anyway, so this isn't any surprise 2) Pre-figuring the delegated vtable functions. At the moment I'm considering two storage schemes for the PMC pointers (one hanging off the vtable itself, another in the class attributes) but I'm open to suggestions here. Or: after the 1st delegate lookup create a JITed stub that is in pseudo-code: enter call saveregs S0 = meth P2 = obj P5 = value # arguments call runops call restoreregs # handle return val leave ret This function's address replaces the vtable slot of the old one and is now called directly as the delegate. When the register assignments are done interpreter-relative, this stub should be reusable by different threads too. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk leo
ICU incorporation and string changes heads-up
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 actual patch, of course.) The patch itself is shaping out to be rather large (mostly because I've added an interpreter argument to the string functions which were lacking it, and updated the places where these function are called), but is self-contained in the sense that (1) the functions which actually call out directly to any ICU API are collected into one file (for clarity, and in case we ever want to transition to a different library), (2) there are minimal API changes, and (3) the GC behavior of strings isn't affected. It will take me a few more days to finish this up, but I wanted to give everyone a heads-up that this is on the way. JEff
Re: Optimizations for Objects
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 for fast allocation) 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 freelist, where they get put back after invokeing the return contination. Unless something inside the call's taken a continuation, in which case they're still valid and may be reused. Can't do that, unfortunately. :( I was thinking of a special PMC arena for continuations that already had the full data chunk tacked on the end of the struct and the various PMC pointers-to-data filled in. 1) A method cache. Which we need anyway, so this isn't any surprise 2) Pre-figuring the delegated vtable functions. At the moment I'm considering two storage schemes for the PMC pointers (one hanging off the vtable itself, another in the class attributes) but I'm open to suggestions here. Or: after the 1st delegate lookup create a JITed stub Which is swell, except for that pesky can't-guarantee-a-JIT thing... :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Method caches
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 complicated to me. In Perl 5, you cache the method simply by making it look like it's a member of the current class. There's very little extra mechanism. You just have to know which methods are the fake ones you can blow away. Admittedly MMD complicates things, but maybe that's a separate cache. Larry
Loadable modules and the DOD
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 been in the bytecode segment stuff in a very long time. I'll try and get a simple test case, since my working code's about 77K of machine-generated PIR. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[perl #27715] Fetching the class name of an anon. subclass causes coredump
# 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 print S0 print \n end dies with: parrot: src/hash.c:256: promote_hash_key: Assertion `key' failed. Abort (core dumped) Simon
Re: [perl #27690] Numeric comparison bug
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 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). I hope this doesn't point to a more general problem. Using different routines to do the same thing for compilation and execution was a bad mistake I made in early Perls, and had to work hard to fix in Perl 5. For instance, all the constant folding in Perl 5 happens by actually running the code in question, not by trying to guess what the run-time system will do, as Perl 4 did. I recommend not remaking my mistakes. Please make different mistakes. :-) Larry
Re: PerlNum -0.0 bug?
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
Classname op semantics
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 Segmentation fault Note that the second fragment only works because currently PCD_CLASS_NAME and POD_CLASS_NAME occupy the same slots in their respective enums; are we prepared to guarantee that this will always be the case? Simon
Re: Method caches
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 good docs and papers on this would be much appreciated. My current thinking, based entirely on the Hmmm, if I had no clue there was any history here, what would I do? school of design, is to do this: Method cache is an array of arrays of cache entries. 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. teddy bears get drunk
Re: Optimizations for Objects
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 *do* any method lookups. With the method PMC directly cached, we just call the darned thing and are done with it. No lookups at all, something definitely faster than actually looking anything up. How do you handle the threaded case with two private objects and runtime method overloading? -Sterling
Re: Classname op semantics
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 At the moment, we get: Foo Foo Segmentation fault Note that the second fragment only works because currently PCD_CLASS_NAME and POD_CLASS_NAME occupy the same slots in their respective enums; are we prepared to guarantee that this will always be the case? Yes, we are. I'm seriously considering redoing class and object internals--I'm just waiting until the metaclass stuff settles in. (Like a plague, alas) The segfault's wrong, though. That needs fixing. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #27690] Numeric comparison bug
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 in mysql. I only tested
this
on linux, but it seems to do the trick. See attached.
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 yes, I'm well aware of the problems inherent in doing floating point
comparisons.
Breakpoint 1, Parrot_PerlNum_cmp_num (interpreter=0x82654f0, pmc=0x40305850,
value=0x40305838) at perlnum.c:301
301 diff = PMC_num_val(pmc) - VTABLE_get_number(interpreter, value);
(gdb) n
302 return diff 0 ? 1 : diff 0 ? -1 : 0;
(gdb) p diff
$1 = 2.2204460492503131e-16
(gdb)
Simon
leo
*** tmp/parrot/src/string.c Sat Mar 6 03:00:06 2004
--- parrot/src/string.c Wed Mar 17 12:24:02 2004
***
*** 1836,1844
int exp_sign = 0;
INTVAL in_exp = 0;
INTVAL in_number = 0;
! FLOATVAL exponent = 0;
INTVAL fake_exponent = 0;
INTVAL digit_family = 0;
while (start end) {
UINTVAL c = s-encoding-decode(start);
--- 1836,1845
int exp_sign = 0;
INTVAL in_exp = 0;
INTVAL in_number = 0;
! INTVAL exponent = 0;
INTVAL fake_exponent = 0;
INTVAL digit_family = 0;
+ FLOATVAL exp_log=10.0, exp_val=1.0;
while (start end) {
UINTVAL c = s-encoding-decode(start);
***
*** 1849,1855
if (df df == digit_family) {
if (in_exp) {
! exponent = exponent * 10 + s-type-get_digit(s-type,c);
if (!exp_sign) {
exp_sign = 1;
}
--- 1850,1856
if (df df == digit_family) {
if (in_exp) {
! exponent = exponent + s-type-get_digit(s-type,c);
if (!exp_sign) {
exp_sign = 1;
}
***
*** 1906,1912
exponent = fake_exponent + exponent * exp_sign;
! f = f * sign * pow(10.0, exponent); /* ugly, oh yeah */
}
return f;
--- 1907,1936
exponent = fake_exponent + exponent * exp_sign;
! if(exponent 0) {
! exponent = -exponent;
! exp_sign=-1;
! }
!
! for (;;) {
! if (exponent 1) {
! exp_val *= exp_log;
! exponent--;
! }
! if (!exponent)
! break;
! exp_log *= exp_log;
! exponent = 1;
! }
!
! if(exp_sign 0)
! f /= exp_val;
! else
! f *= exp_val;
!
!
! if(sign 0)
! f = -f;
}
return f;
Re: Optimizations for Objects
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 freelist, where they get put back after invokeing the return contination. Unless something inside the call's taken a continuation, in which case they're still valid and may be reused. Can't do that, unfortunately. :( Could you please provide a code snippet that shows this reusing. Thanks, leo
Re: [perl #27690] Numeric comparison bug
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;
! FLOATVAL exponent = 0;
INTVAL fake_exponent = 0;
INTVAL digit_family = 0;
while (start end) {
UINTVAL c = s-encoding-decode(start);
--- 1836,1845
int exp_sign = 0;
INTVAL in_exp = 0;
INTVAL in_number = 0;
! INTVAL exponent = 0;
INTVAL fake_exponent = 0;
INTVAL digit_family = 0;
+ FLOATVAL exp_log=10.0, exp_val=1.0;
while (start end) {
UINTVAL c = s-encoding-decode(start);
***
*** 1849,1855
if (df df == digit_family) {
if (in_exp) {
! exponent = exponent * 10 + s-type-get_digit(s-type,c);
if (!exp_sign) {
exp_sign = 1;
}
--- 1850,1856
if (df df == digit_family) {
if (in_exp) {
! exponent = exponent*10 + s-type-get_digit(s-type,c);
if (!exp_sign) {
exp_sign = 1;
}
***
*** 1906,1912
exponent = fake_exponent + exponent * exp_sign;
! f = f * sign * pow(10.0, exponent); /* ugly, oh yeah */
}
return f;
--- 1907,1936
exponent = fake_exponent + exponent * exp_sign;
! if(exponent 0) {
! exponent = -exponent;
! exp_sign=-1;
! }
!
! for (;;) {
! if (exponent 1) {
! exp_val *= exp_log;
! exponent--;
! }
! if (!exponent)
! break;
! exp_log *= exp_log;
! exponent = 1;
! }
!
! if(exp_sign 0)
! f /= exp_val;
! else
! f *= exp_val;
!
!
! if(sign 0)
! f = -f;
}
return f;
Re: [perl #27690] Numeric comparison bug
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 be duplicated. Or am I misunderstanding the problem? Larry
Re: Optimizations for Objects
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 in the class' attributes or something) such that we : don't actually have to *do* any method lookups. With the method PMC : directly cached, we just call the darned thing and are done with it. : No lookups at all, something definitely faster than actually looking : anything up. : : : How do you handle the threaded case with two private objects and : runtime method overloading? I suspect Dan is primarily talking about public, single dispatch in a (more-or-less) static, global class hierarchy. Private dispatch shouldn't be trying to use the public dispatcher in any case, in my opinion, and Perl 6 will enforce that by making you call private methods differently from public methods, to keep private things in a completely separate namespace. (Whether Parrot will have to confuse the private and public dispatchers to support other languages is another matter, of course... But we'd prefer not to violate Liskov substitutability just because you add a private method.) Larry
Optimizations for Objects
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) Optimized and unoptimized reported run times went down 10%. That's 1/5 of the way to perl! :) I would like to see at least two other tests: (1) doing fetch_method in main, and using the fetched methods, rather than repeatedly looking them up. (2) creating an explicit return continuation in fib, and using it for both recursive calls, cutting continuation creation in half. The first will illustrate the maximum savings we can expect here from a perfect, costless, method lookup cache. The second will illustrate how much time is being spent in return continuation pmc creation and associated garbage collection. What else might be interesting? I began work on (1), but got bogged down. Perhaps a better imc writer than I could knock it off? I just don't have that warm fuzzy feeling that we know where our time is going yet. Mitchell
Re: [perl #27690] Numeric comparison bug
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 sensitive STRING type, the compiler does not. I'm not very familiar with the garbage collector, would the call to string_make() be a memory leak? Or will it be collected? diff -r1.68 pbc.c 593c593,594 int k; --- int k, l; STRING *str; 594a596 str = const_string(interpreter, buf); 596d597 600c601,602 (FLOATVAL)atof(buf); --- string_to_num(str); Larry Wall wrote: 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 be duplicated. Or am I misunderstanding the problem? Larry
Re: [perl #27690] Numeric comparison bug
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. The compiler just does atof() while string_to_num() is a long and possibly buggy conversion routine that tries to deal with unicode codepoints. I recommend not remaking my mistakes. Please make different mistakes. :-) We'll try hard ... Larry leo
