News for hackers. Stuff that matters.
Re:How we made Haskell search strings as fast as Rust by timerol on Wednesday March 13, 2019 @02:15PM (#19381687)
> Clearly there was plenty of room for speeding up our string matching. We considered binding the Rust library, but due to the way that Haskell’s foreign function interface interacts with the garbage collector, passing a string to a foreign function requires copying it. That copy alone puts any foreign library at a significant disadvantage, so we decided to see how close we could get in Haskell alone.

It's a shame Haskell copies strings across FFI boundaries, because binding the Rust version would have been almost as fast, with (presumably) significantly less effort.

Re:How we made Haskell search strings as fast as Rust by chrisdone on Wednesday March 13, 2019 @02:17PM (#19381711)
As I wrote elsewhere that depends on the string type used: https://www.reddit.com/r/haskell/comments/b0l93l/how_we_made...
Re:How we made Haskell search strings as fast as Rust by Tarean on Wednesday March 13, 2019 @07:29PM (#19385049)
I wondered about this and poked at the internals of ByteString (suitable for ffi) and Text. Turns out Text could allow ffi by changing a single function (newByteArray to newAlignedPinnedByteArray).

Presumably creating lots of small strings is a typical use case for Text so losing compacting gc hurts. ByteString on the other hand is more used with binary data and is designed for ffi use.

Re:How we made Haskell search strings as fast as Rust by whateveracct on Thursday March 14, 2019 @03:07AM (#19387066)
Hmm ByteString has the opposite issue and solved it with ShortByteString. Seems like PinnedText could be the analogue.