Martin's point about immutable and persistent data structures is further
developed in his interview on infoq
<http://www.infoq.com/interviews/reactive-system-design-martin-thompson>, you
can skim to point #9 if you're in a hurry.
Overall what he says is that in terms of scalability of the development
activity, immutability and persistence are great ideas, since we don't
have to deal with non-deterministic behaviour any more. When one needs
to scale the running system, meaning increasing the rate at which the
persistent data structure is updated, these can lead to performance
issues in various ways:
- longer GC pauses because persistency increases the number of objects
that are neither very short-lived nor long-lived,
- contention because the root of the tree of the persistent data
structure becomes the focal point of concurrency,
- increased CPU cache misses since persistent data structures are trees
that increasingly span larger non-contiguous and non-sequential parts of
memory
Of these the last point is probably the most painful, since there's no
way to deal with it unless one reconsiders the whole persistent data
structure.
In other words increasing the number of threads and cores may eventually
lower throughput because the time taken for dealing with these issues
(GC pauses, locking, cache misses) grows larger than the time taken for
useful computation.
I can't backup any of this with actual data and experience. However I
think this old thread about poor performance on multicore
<https://groups.google.com/forum/#%21topic/clojure/48W2eff3caU> does
provide a clear picture of the problem, which becomes even clearer with
actual stats showing
<https://groups.google.com/d/msg/clojure/48W2eff3caU/FBFQp2vrWFgJ>CPUs
<https://groups.google.com/d/msg/clojure/48W2eff3caU/FBFQp2vrWFgJ>were
83% idle
<https://groups.google.com/d/msg/clojure/48W2eff3caU/FBFQp2vrWFgJ>, i.e.
waiting for memory.
Also one should view Martin's other vidoes on infoq
<http://www.infoq.com/author/Martin-Thompson> to get a better
understanding of his arguments. He's actually quite positive about
Clojure in general. It's just that depending on the scalability and
performance requirements, persistent data structures may not provide a
satisfactory answer and could even lower throughput.
On 14/03/14 18:01, ?????? ????????? wrote:
He talks about simple things actually.
When you have any sort of immutable data structure and you want to
change it from multiple threads
you just must have a mutable reference which points to the current
version of that data structure.
Now, updates to that mutable reference are fundamentally serial.
Whatever synchronization
strategy you chose been that optimistic updates (atom) or queuing
(agent) or locks you inevitably
will have a contention on a large number of threads. When you will run
on that you will also
have hundred ways to solve a problem.
There is nothing magical about persistent data structures on
multi-core machines :)
???????, 13 ????? 2014 ?., 20:58:54 UTC+4 ???????????? Andy C ???????:
Hi,
So the other day I came across this
presentation:http://www.infoq.com/presentations/top-10-performance-myths
<http://www.infoq.com/presentations/top-10-performance-myths>
The guy seems to be smart and know what he talks about however
when at 0:22:35 he touches on performance (or lack of thereof) of
persistent data structures on multi-core machines I feel puzzled.
He seems to have a point but really does not back it with any
details. There is also a claim that STM does not cooperate well
with GC. Is it true?
Thanks,
Andy
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
