Front page | perl.perl5.porters |
Postings from January 2017
Re: Should we consider locked hashes a failed experiment?
Thread Previous
|
Thread Next
From:
Steffen Mueller
Date:
January 28, 2017 18:45
Subject:
Re: Should we consider locked hashes a failed experiment?
Message ID:
9dd75136-90df-1742-6fac-78fd20d26b2d@steffen-mueller.net
On 01/28/2017 03:31 PM, demerphq wrote:
> Steffen has started working on a patch series to make hashes
> pluggable. (Big big fricking A to him on that!) This is only going to
> be more complex if we support locking (does every hash implementation
> have to support locking? Does the hash api have to support
> "clear_placeholders"?
Since Yves is already pimping what I'm doing, let me add a tiny bit of
context.
In a nutshell, see the commit message for the first commit in
smueller/hash_vtable (attached below for your convenience).
My expectations for this are essentially:
- That I'm enjoying myself, stealing a few minutes of spare time here
and there. (Been too long since I hacked on anything of substance.)
- To try and see how viable this is.
- To find out what exactly this first stab will fail on.
- That I might run out of spare time at any moment.
Which is to say:
- I'm perfectly willing to cut corners and make some changes that I know
won't be merged into blead as is.
- I'm anticipating that try #1 will fail, except in that it's for learning.
I also don't have any good bit of language design in mind on how to
expose this to regular Perl users.
So, this all being said, I'm totally open to collaboration and feedback.
If the feedback is constructive, but essentially boils down to "in order
to get this into blead, you need to implement it in a completely
different and much more complex/exhausting way", then please understand
that I might not jump at it because I'm trying to prototype something
rather than getting it perfect from day one. This is primarily because
I'd rather have a working prototype by the time I run out of spare time
instead of a 20% implementation that's promising. Hope y'all understand!
Best regards,
Steffen
commit f5273c31fc75116e686a7151faeada96493fa72f
Author: Steffen Mueller <smueller@cpan.org>
Date: Tue Jan 24 10:48:06 2017 +0100
Proof of principle hash vtables
This is a very partial implementation of having pluggable hashes by
(optionally) having magic-alike vtables which make all top level hash
operations pluggable.
At this point, this has all sorts of objectionable shortcuts. It also
means slowing down all operations by at least and extra compare+branch.
It also only does this for deletes right now because I'm just dabbling.
So in summary, this isn't much at all.
The reason why I'm playing with this is that if one were able to
specialize hash implementations (eg. perfect hashes or scanning small
lists for low-number-of-keys objects, having actual sets for huge
sets, having more compact "string only" (ie. no SV overhead) tables,
etc etc), I'd expect that one could gain a bunch.
Ultimately, this sort of thing is hindered by a great deal of things
such as the complete insanity of the hash API (way too many ways to do
things), the structure of the code (it's all shims to the same common
function - in an attempt to reduce code duplication), and the horror
that is MAGIC support. It's also decidedly hindered by my understanding
of the intricacies of the code base.
This doesn't solve the language design issue of how one would actually
make this accessible to Perl users. It'd be reasonably easy to have a
new keyword that takes an additional first parameter which
indicates the
hash storage type (presumably as a constant string which can be
converted to a vtable at compile time using some kind of global
lookup).
In terms of execution, this could generate either an OP that is similar
to pp_anonhash but has the type info on the stack, or it could
literally
generate a pp_anonhash which abuses its op_targ as a way to store the
vtable pointer (PADOFFSET is an IV or UV which are big enough to hold a
pointer, but yuck.).
So I'm throwing this out there in case somebody (which includes my
future self) finds this intriguing enough to try to pursue further.
Right now, this commit includes a small change that redefines newHV to
ALWAYS assign a vtable (instead of defaulting to NULL, which falls
through to the normal hash implementation). It also ships a (partial)
vtable implementation which is meant to behave exactly the same way as
the normal implementation. This is to test that this whole scheme
actually work. As I was saying, right now in this commit, newHV is
hardwired to always set this "mock" vtable for testing.
Thread Previous
|
Thread Next