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