Proposal: Add the unordered-containers package and the hashable package to the Haskell Platform
Johan Tibell
johan.tibell at gmail.com
Tue Mar 19 16:51:14 CET 2013
Hi Thomas,
On Tue, Mar 19, 2013 at 8:41 AM, Thomas Schilling
<nominolo at googlemail.com>wrote:
> On 19 March 2013 16:01, Johan Tibell <johan.tibell at gmail.com> wrote:
> >
> http://trac.haskell.org/haskell-platform/wiki/Proposals/unordered-containers
>
> The links to the repos are wrong. It should be "tibbe" instead of
> "tibbel".
>
Fixed.
> Bryan's recent change to change "hashable" to use SipHash is certainly
> the right default. There were some complaints about performance for
> use cases where security is not an issue. What are the options for
> users that wish to use a different hash function? According to the
> paper, SipHash is about 2x slower than CityHash.
>
2x is *a lot*. 2x is about the performance difference between Map and
HashMap. Since the raison d'etre for HashMap is that it's faster than Map,
if we'd see a 2x slowdown in HashMap there would be little reason to use it.
For example, 'delete' for HashMap ByteString got almost 2x slower with
hashable-1.2. Since 'delete' does more than just hashing, that means that
SipHash is quite a bit slower than the current (insecure) hash function.
Another example: with GHC 7.6.2 HashMap String is almost unusable slow (5x
slower than before). This is likely due to a GHC bug, but it's something we
need to investigate. At the moment I don't encourage people to upgrade to
hashable-1.2.0.5.
The right way to go is probably to make this a user decision. Many
applications (e.g. data processing) has no need for the security guarantee
so paying for it makes little sense.
Cheers,
Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130319/8ca4c72a/attachment.htm>
More information about the Libraries
mailing list