Purity in D – new article
bearophile
bearophileHUGS at lycos.com
Mon May 28 13:37:07 PDT 2012
Gour:
> How many are on a single CPU today and in the nearby tomorrow?
This question turns this discussion into something vast and
complex. The short answer is that if your purpose is to go fast,
those immutable data structures don't seem the solution. Please
take a look at what data structures and algorithms are used where
people have to perform large amounts of processing (Google data
centers, modern video games, sensory processing, and so on).
If your computational hardware looks like a GPU, with thousands
(or more) very small cores able to run all similar code, code
that contains few jumps and conditions, the best data structures
aren't those. Take a look at how they implement Support Vector
Machines on GPUs or other advanced data structures fit for that
computational iron. There was a very active research on this.
Today I have seen cases where low-indirection-ratio data
structures used by plain looking C programs running on a single
core are faster (and use 1/15 of the RAM) than Clojure programs
running on 8 cores (and I don't think having 16 cores will change
those specific cases). This happens because (among other things)
communication between cores has a cost, and there are parts of
the programs that don't parallelize. Single cores that are
programmed to work smartly on their L1 and L2 caches are fast.
In future we'll have many cores, but physics tells us that
communication and synchronization can't be for free. So for
several not so easily parallelized algorithms you will keep
wanting to use not tiny cores/memory organized in a tree of
progressively more costly communication and synchronization. For
such iron structure, I think languages like X10 and Chapel have
far better chance to produce efficient code than Clojure and it
current standard data structures.
You are able to build data structures more fit for heavy
computation for Haskell too, but Chapel and X10 languages are
built around them from the start (example: in Chapel it's easy to
design _complex hierarchical tiling_ strategies for data
structures, that to me seem the key to work efficiently on the
modern pyramid-shaped design of memories and their related
communication costs. D design seems to have ignored all the nice
ideas present in Chapel and X10 languages).
Bye,
bearophile
More information about the Digitalmars-d-announce
mailing list