Re: [boost] [ boost ] [ Trie ]

Subject: Re: [boost] [ boost ] [ Trie ]
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2015-03-06 03:44:46

2015-03-05 20:48 GMT+03:00 Cosmin Boaca <boost.cosmin.boaca_at_[hidden]>:

> On 5 March 2015 at 19:15, Kenneth Adam Miller <kennethadammiller_at_[hidden]
> >
> wrote:
>
> > Ok, where is the repo?
> >
> > Cosmin: Are you open to the idea of having the trie act as a container
> and
> > sort of adopt a superset of the operations that work on traditional STL
> > containers?
> >
> > Are you open to the idea of having the trie be parameterizable with
> > concurrency strategies? With value strategies that can even be an
> > additional data structures?
> >
>
> I am not quite experienced in concurrent data structures. Honestly I have
> never thought of that but I am open to any discussion about implementation
> strategies. Maybe Anthony could help us taking design decisions and some
> plan of implementation.
>

Well, usually you make a data structure concurrent after you've polished
the implementation, removed the unnecessary fields, tuned structure for
size. Big problem with concurrent data structures - is that generic
solution would probably be much slower than a problem-tuned solution.

Making a concurrent trie is discussable, but in any case tuning the current
implementation must be done first.

> I'm interested in each of these. And I have ideas about how to move
> forward
> > implementing them. I'd also like to work on applying what we make toward
> > several already open libraries, by writing some bindings to python and
> some
> > other languages. I'm interested in writing some protobuf/capnproto
> > specifications and some data-type translations between the vernacular
> too.
> >
>
> I am not familiar with protobuf / canproto.
>

Trie's API is not stable yet, so do not rush with that task.

-- 
Best regards,
Antony Polukhin