On Thu, Mar 21, 2013 at 6:54 AM, wren ng thornton <w...@freegeek.org> wrote:
> On 3/20/13 1:02 PM, Thomas Schilling wrote:> To make this more precise the > next version of hashable (say, 1.3) > > would include this: > > > > newtype SipHashed a = SipHashed a > > > > class SipHashable a where > > sipHashWithSalt :: Int -> a -> Int > > > > instance SipHashable a => Hashable (SipHashed a) where > > hashWithSalt salt (SipHashed x) = sipHashWithSalt salt x > > > > Then all Hashable instances are taken from hashable-1.1. All Hashable > > instances from hashable-1.2 are renamed to become instances of > > SipHashable. > > That seems like a reasonable solution. > > I only ever use hashmaps explicitly for speed reasons and in applications > that are not susceptible to DoS. The arguments about not wanting to > introduce security issues due to some transitive dependency also hold for > not wanting to introduce performance issues due to some transitive > dependency. I respect all the folks working on web frameworks in Haskell, > but there are also those of us who work on programs where compute time > really is the number one concern (once an acceptable level of correctness > and precision has been obtained); and when experiments are measured in > days or weeks of cluster time, those "little" 1.3x and 1.5x slowdowns > really hurt, let alone the 2.0x people've mentioned with siphash. > > One concern with the above approach: is "siphash" a sufficiently generic > name, or is it just one hashing method that happens to deflect this DoS > issue? I haven't read the paper, so... > There was also a complaint that the old hashable uses id as the hash function for Ints, while the new one always hashes them, also degrading performance. This might be a harder nut because `hash` itself was removed as a method of Hashable, but perhaps it could be added back(?), and then it could also be a case for the newtype. I can't remember what the motivation was for hashing them. In any case I'd prefer a more generic name for the newtype, who knows if this kind of tradeoff might not be present elsewhere. > > -- > Live well, > ~wren > > > _______________________________________________ > Libraries mailing list > librar...@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -- Your ship was destroyed in a monadic eruption.
_______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
