

What's new in purely functional data structures since Okasaki? (2010) - profquail
http://cstheory.stackexchange.com/questions/1539/whats-new-in-purely-functional-data-structures-since-okasaki

======
kazagistar
Out of curiosity, how to purely functional data structures compare with
classic mutable data structures in terms of real hardware performance? From
what I hear, they are useful if you are into functional purity, and sometimes
if you are doing certain parallel programming tasks, but suffer significant
overhead outside that domain, but I would like to hear of any specific
evidence people have in either direction.

~~~
jules
Since the other comments are platitudes, I'll try to give some concrete
information. Well implemented purely functional data structures are usually
anywhere from just as fast to about 20x slower. If the imperative version is
tree like, the cost for lookups in the functional version is the same, but the
cost for updating is a bit higher because a path needs to be copied rather
than just 1 node modified in place. For a data structure like an unordered
map, you can use a hash table backed by an array for the imperative version,
but you'll have to use a tree for the purely functional one. This can cause
about a 10x-20x slowdown.

For example in this post [http://donsbot.wordpress.com/2009/09/26/very-fast-
scalable-m...](http://donsbot.wordpress.com/2009/09/26/very-fast-scalable-
mutable-maps-and-hashes-for-haskell/) Haskell's Data.Map is compared with Judy
arrays, and found to be 11x slower. Judy arrays themselves are about 2x slower
than a basic hash table [http://preshing.com/20130107/this-hash-table-is-
faster-than-...](http://preshing.com/20130107/this-hash-table-is-faster-than-
a-judy-array/)

Is this slow? Perhaps, but in most cases the difference is smaller. Compare
this to the speed of Ruby vs C, that can easily be a 100x difference yet
people use Ruby a lot because of productivity reasons.

~~~
dons
Importantly, comparing "ephemeral" structures - those that destroy previous
states through direct hardware mutation - with persistent structures (such as
all pure data structures) - is a fraught topic.

You can surely gain speed ups on real hardware directly mutating memory you
know to be reusable (linear) - but proving that precondition is very hard, and
we often screw it up.

Persistent data is a safe default. Mutation/destruction is an optimisation.

------
MaxGabriel
For people who've read it, do you have a review of Okasaki's book? Also, what
background should someone have before reading it (eg should you be able to
read it after reading Learn You a Haskell? Should you already be familiar with
the imperative equivalents?)

~~~
how_gauche
It's the best book about data structures in functional programming, as
relevant today as when it was published almost fifteen (gasp) years ago.

You can get a flavor of the book by reading Okasaki's PhD thesis:
[http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf](http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf)

The book is essentially a fleshed-out version of this thesis.

~~~
hamidr
Why there's no updated book out there (in the cold!) ?

~~~
cmarschner
See here why not: [http://okasaki.blogspot.de/2008/02/ten-years-of-purely-
funct...](http://okasaki.blogspot.de/2008/02/ten-years-of-purely-functional-
data.html?m=1)

~~~
keithpeter
_" That changed one day during a walk in the snow."_

The paragraph that follows this phrase in the OA is straight out of _The
psychology of invention in the mathematical field_ by Jacques Hadamard.

------
ot
Note that this thread has been submitted many times to HN, but it never
generated generate many comments:

[https://www.hnsearch.com/search#request/submissions&q=what's...](https://www.hnsearch.com/search#request/submissions&q=what's+new+okasaki&start=0)

~~~
skybrian
I think posting one algorithm you really like and explaining why works better
than a laundry list.

------
moomin
The importance of the Phil Bagwell/Rich Hickey* vector can't be understated.
AFAIK, pretty much all standard immutable lists provided by platforms use this
work.

*Bagwell designed the tries as a mutable data structure. Hickey saw how to apply that to a workable immutable list implementation.

------
Aqueous
Even as a rabid user of Scala and sometimes Erlang, it strikes me that
"exciting purely functional data structures" may be an oxymoron.

