develooper Front page | perl.perl5.porters | Postings from April 2008

[rfc-patch] expose ptr-table funcs, add ptr-table-delete, and benchmarkthem

Thread Next
From:
Jim Cromie
Date:
April 1, 2008 08:49
Subject:
[rfc-patch] expose ptr-table funcs, add ptr-table-delete, and benchmarkthem
Message ID:
47F2595A.5050101@gmail.com

this patch exposes ptr-table-* funcs for use in XS,
and adds ptr_table_delete.

then I tested it for storing a sequence of integers.
This workload is pessimized; it causes hash collisions
in PTR_TABLE_HASH, and bucket chains of 8 entries.

              Rate  hash(10) pth(10,1)
hash(10)  157284/s        --      -72%
pth(10,1) 560274/s      256%        --
              Rate  hash(100) pth(100,1)
hash(100)  19076/s         --       -70%
pth(100,1) 62624/s       228%         --
              Rate  hash(1000) pth(1000,1)
hash(1000)  1884/s          --        -71%
pth(1000,1) 6573/s        249%          --
              Rate  hash(10000) pth(10000,1)
hash(10000)  183/s           --         -70%
pth(10000,1) 605/s         230%           --
                Rate  hash(100000) pth(100000,1)
hash(100000)  14.6/s            --          -76%
pth(100000,1) 59.9/s          310%            --
                 Rate  hash(1000000) pth(1000000,1)
hash(1000000)  1.22/s             --           -79%
pth(1000000,1) 5.84/s           379%             --


the ptr-table hash is always faster,
increasingly so for larger sets.

I also tested ptr-hash with a step=8 sequence,
which works with (rather than against) the PTR_TABLE_HASH
formula, these show significant improvement (30%)
over the step=1 results.

at the small hash, the overhead of creating and destroying
the hash buries any insert & delete differences.



              Rate pth(10,1) pth(10,8)
pth(10,1) 559073/s        --       -2%
pth(10,8) 570511/s        2%        --
              Rate pth(100,1) pth(100,8)
pth(100,1) 62737/s         --       -22%
pth(100,8) 80184/s        28%         --
              Rate pth(1000,1) pth(1000,8)
pth(1000,1) 6573/s          --        -25%
pth(1000,8) 8773/s         33%          --
              Rate pth(10000,1) pth(10000,8)
pth(10000,1) 607/s           --         -25%
pth(10000,8) 807/s          33%           --
                Rate pth(100000,1) pth(100000,8)
pth(100000,1) 59.9/s            --          -25%
pth(100000,8) 79.6/s           33%            --
                 Rate pth(1000000,1) pth(1000000,8)
pth(1000000,1) 5.81/s             --           -22%
pth(1000000,8) 7.47/s            29%             --


SO, was denken sie ?

speed is good, but does this expose too much implementation ?
does it create too much opportunity for misuse ?

I wrote XS to do unit/developer & performance testing,
not to give it a perlish interface, which would really
expose it, and raise the Qs above.

Offhand, it looks useful for XS modules such as Devel::Size.


Aside - this is part of my *now-working* patchset to
strip siblings out of OPs, and into a global hash
(ptr-table based).  It now scores 99 on perlbench,
so its in the ballpark.  Im now pondering how to better
characterize and optimize it.

Good sci-fi has basis in facts.



Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About