Re: [boost] Final benchmark graphs for Colony vs std:: containers now available

Subject: Re: [boost] Final benchmark graphs for Colony vs std:: containers now available
From: degski (degski_at_[hidden])
Date: 2016-05-12 00:28:00

On 12 May 2016 at 03:59, Soul Studios <matt_at_[hidden]> wrote:

There's no way currently, I'd be more inclined to implement a separate 100%
> threadsafe version specifically - for both performance reasons and to not
> expose unnecessary details to the end user.
>

'Unnecessary' is a qualification that is a function of ones' objectives...

> Might be a good idea for a future test, but I think the GCC results cover
> it more-or-less for now- plus it's good for people to know how terrible
> some of MS/Dinkumware's implementations are :)
>

Yes, bashing Dinkumware is fun, but they might have been given rules about
not breaking binary compatibility. I do agree though, that some of their
stuff is horrible. For this one they might have an excuse. The std::random
lib is another really horrible one and since it's new, this time no excuse.
boost::random (drop-in replacement) is much much faster (and more
extensive, for games taus88 is the one in my view).

The git-repository you reference in another post seems to be behind the
references download on your site, 3.05 vs 3.07.

The web-site states plf::colony is a vector-like container, I'm missing the
indexes, iterating is good in some cases but not all.

I've implemented a (simple) Concurrent Graph Library, based on ideas (the
base structure) borrowed from the LEMON Graph Library, using
tbb::concurrent_vector, instead of std::vector. This comes with some
limitations as you correctly pointed out. You did give me some good ideas
to actually make that CGL better and more flexible. I've read your paper on
jump-counting-skipfields, there are some fun ideas in there that I would
like to explore as well.

degski