Re: [RfC] disable unused vtable entries
Dan Sugalski [EMAIL PROTECTED] wrote: This is 3 times faster and saves ~1000 DOD runs. Wow. Okay. Go for it. Done. CODE OP FULL NAMECALLS TOTAL TIME AVG T. ms - --- -- -- 743 findclass_i_sc1000.478843 0.0005 leo
Re: [RfC] disable unused vtable entries
At 12:14 PM +0100 12/2/03, Leopold Toetsch wrote: Leopold Toetsch [EMAIL PROTECTED] wrote: OTOH I'm thinking of adding _keyed_str variants to used _keyed vtables. We are already constructing too much temporary key PMCs from a string just to pass a string to an hash lookup. Object ops and functions do this all over the place repeatedly. And here is a profile timing comparison for doing 1E6 findclass ops [1]: CODE OP FULL NAMECALLS TOTAL TIME AVG T. ms - --- -- -- 743 findclass_i_sc1001.356876 0.0014 -3 DOD 10580.211712 0.2001 ... - --- -- -- 1130010661.666512 0.0006 Doing the same with a direct hash_get() [2]: 1257 findclass_str_i_sc1000.462577 0.0005 ... - --- -- -- 113090.564461 0.0002 This is 3 times faster and saves ~1000 DOD runs. Wow. Okay. Go for it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [RfC] disable unused vtable entries
I wrote here at mid-May:
[ vtable - opcode coverage ]
Here is an update of a really old story:
$ ./vtbc.pl # s. below
vtable coverage
vtable.tbl has 202 entries
core_ops.c has 116 entries + 10 internally used
[ ... ]
76 unused
19 _bignum variants - TODO
19 unused vtables with _same suffix
- _same are intended as short cuts, when all data types are known. But
IMHO to know what data types are involved, you have to test the PMC
types - this is what the normal methods do anyway, so these methods
are probably superfluous.
And: is_same does compare, if the PMCs have the same address, so there is
really no need for a vtable slot. All but one _same variant are unused.
set_bool
set_integer
set_number
set_string
These have the same problem as the _same variants. The assembler would
have to know, that the RHS is a PMC of the given type, and that the
assignment should result in that type. I can hardly imagine how.
If no one has good reasons to keep these 19 + 4 vtable slots, I'll
removed it, reducing vtable size by more then 10%.
OTOH I'm thinking of adding _keyed_str variants to used _keyed vtables.
We are already constructing too much temporary key PMCs from a string
just to pass a string to an hash lookup. Object ops and functions do
this all over the place repeatedly.
Yeah, and we still have 29 unused _keyed entries ...
leo
#!/usr/bin/perl
#
# vtbc.pl - vtable coverage
use FindBin;
use lib 'lib';
use lib $FindBin::Bin/..;
use lib $FindBin::Bin/../lib;
use Parrot::Vtable;
use strict;
my $default = parse_vtable(./vtable.tbl);
printf vtable coverage\n;
printf vtable.tbl has . scalar (@{$default}). entries\n;
my %methods;
foreach my $method (@{$default}) {
$methods{$method-[1]}=1;
}
my %vops;
open IN, src/core_ops.c or die(can't read core_ops.c\n);
while (IN) {
$vops{$1}++ while (/VTABLE_(\w+)/g);
}
close(IN);
my @int = qw/morph mark destroy elements init_pmc visit freeze thaw thawfinish
nextkey_keyed/;
printf core_ops.c has . keys(%vops) . entries + . scalar(@int) .
internally used\n;
foreach my $i (@int) {
$vops{$i}++;
}
my $unused;
foreach my $c (keys(%methods)) {
$unused++, printf $c\n unless $vops{$c};
}
printf $unused unused\n;
Re: [RfC] disable unused vtable entries
Dan Sugalski wrote: Got Warnocked, I think. I'm partway through partitioning the vtable up to make overriding vtables on a per-PMC basis less expensive. I'm pretty sure that most of the keyed variants will end up being used, but we may end up pruning a bunch of these out. The _keyed math, logical and binary ops are history. As mentioned several times, I don't see any chance to implement them without having about 64 times the opcount we have now. This doesn't mean, that we never support multi keyed ops: $ cat 3key.imc new P0, .PerlArray new P1, .PerlArray new P2, .PerlArray set I0, 0 set I1, 10 loop: set P1[I0], I0 set P2[I0], I0 add P0[I0], P1[I0], P2[I0] inc I0 lt I0, I1, loop ... $ parrot -o- 3key.imc new P0, 22 new P1, 22 new P2, 22 set I0, 0 set I1, 10 loop: set P1[I0], I0 set P2[I0], I0 set P18, P1[I0] set P17, P2[I0] new P16, 27 # .PerlUndef add P16, P18, P17 set P0[I0], P16 inc I0 lt I0, I1, loop ... This code can for sure be improved, also the semantics of the LHS (new, assign) has to be defined, but that problem has the original code too. WRT _same opcodes: I finally found a usage for some of these, when fixing the assign Px, Px vtables ;-) But I still can't imagine any usage besides the set_type_same variants. leo
Re: [RfC] disable unused vtable entries
At 8:53 PM +0100 8/6/03, Nicholas Clark wrote:
On Tue, May 20, 2003 at 04:33:31PM +0200, Leopold Toetsch wrote:
In perl.perl6.internals, I wrote:
When looking at classes/*.c struct _vtable temp_base_vtable {} by far
the most vtable methods are unused or uncovered by opcodes:
Some more details (vtbc.pl is below):
$ ./vtbc.pl |grep same | wc -l
20
$ ./vtbc.pl |grep bignum | wc -l
25
$ ./vtbc.pl |grep keyed | wc -l
123
$ ./vtbc.pl |grep -v keyed | grep -v same | grep -v bignum
vtable coverage
vtable.tbl has 265 entries
core_ops.c has 94 entries + 5 internally used
set_number
substr
cmp_num
bitwise_shl_int
bitwise_shr_int
set_integer
set_string
concatenate_native
cmp_string
invoke_pmc
modulus_float
substr_str
repeat_int
subtype
get_pmc
166 unused
- _same are intended as short cuts, when all data types are known. But
IMHO to know what data types are involved, you have to test the PMC
types - this is what the normal methods do anyway, so these methods
are probably superfluous.
- _keyed - by far the most group and IMHO will never be implemented due
to the huge opcode count necessary to implement them.
- _bignum will be needed
- from above list: set_integer, set_number, set_string always use their
_native variants so they are probably unneeded.
Others might be missing or unneeded - who knows.
Comments still welome
No-one commented, did they? Did anything come of this?
Got Warnocked, I think. I'm partway through partitioning the vtable
up to make overriding vtables on a per-PMC basis less expensive. I'm
pretty sure that most of the keyed variants will end up being used,
but we may end up pruning a bunch of these out.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: [RfC] disable unused vtable entries
On Tue, May 20, 2003 at 04:33:31PM +0200, Leopold Toetsch wrote:
In perl.perl6.internals, I wrote:
When looking at classes/*.c struct _vtable temp_base_vtable {} by far
the most vtable methods are unused or uncovered by opcodes:
Some more details (vtbc.pl is below):
$ ./vtbc.pl |grep same | wc -l
20
$ ./vtbc.pl |grep bignum | wc -l
25
$ ./vtbc.pl |grep keyed | wc -l
123
$ ./vtbc.pl |grep -v keyed | grep -v same | grep -v bignum
vtable coverage
vtable.tbl has 265 entries
core_ops.c has 94 entries + 5 internally used
set_number
substr
cmp_num
bitwise_shl_int
bitwise_shr_int
set_integer
set_string
concatenate_native
cmp_string
invoke_pmc
modulus_float
substr_str
repeat_int
subtype
get_pmc
166 unused
- _same are intended as short cuts, when all data types are known. But
IMHO to know what data types are involved, you have to test the PMC
types - this is what the normal methods do anyway, so these methods
are probably superfluous.
- _keyed - by far the most group and IMHO will never be implemented due
to the huge opcode count necessary to implement them.
- _bignum will be needed
- from above list: set_integer, set_number, set_string always use their
_native variants so they are probably unneeded.
Others might be missing or unneeded - who knows.
Comments still welome
No-one commented, did they? Did anything come of this?
Nicholas Clark
