
Cache-Efficient Functional Algorithms (2014) [pdf] - ingve
http://www.cs.cmu.edu/~rwh/papers/iolambda-cacm/cacm.pdf
======
d33
I'm getting the impression that our problems with caching are related to the
way we abstract computer memory. If languages are built with the assumption
that you can jump around your RAM with no cost, I guess that can result in
code that could have been made more efficient. This makes me wonder - what
kind of abstraction would help alleviate this problem?

~~~
hacker_9
More abstractions! Higher level languages!

~~~
rawnlq
Don't you need a lower level language (than even assembly and maybe even some
sort of hardware support)? Virtual memory abstracts away whether the address
is in RAM or disk. Going a step further, you need to undo even one more layer
of abstraction so you know whether you're accessing L1, L2, or main memory.

But to be honest I think just malloc is a decent abstraction. You control
memory layout and the rest is having algorithms with good access patterns.

------
onalark
This is a really interesting article and I'm glad this is getting attention.
It's especially refreshing to see a theoretical treatment bridging algorithms
with more "modern" hardware implementations.

One opportunity I do find in this article is real-world performance tests and
determining the importance of constants in performance tuning. Prakop et al.
did some really interesting work in 1999 on cache-oblivious algorithms, with
applications to kernels such as the FFT and matrix multiplication. The work is
theoretically extremely interesting, but in practice, hand-written or machine-
generated algorithms continue to dominate. The most famous example of this is
probably Kazushige Goto, whose hand-optimized GotoBLAS (now under open source
license as OpenBLAS) still provides some of the fastest linear algebra kernels
in the world.

If you're interested in learning more about how the differences between the
two approaches shake out in linear algebra, I recommend "Is Cache-Oblivious
DGEMM Viable?" by Gunnels et al.

------
fpoling
This is about algorithms over immutable or persistent data structures, not
about algorithms operating on functions, a common and unfortunate misnaming.

Ocaml is functional but allows arbitrary state mutations. On the other hand it
is typically very straightforward to implement persistent data structures in a
non-functional language with GC support.

~~~
sctb
I would be very hesitant to accuse Robert Harper of misusing the term
'functional'. I'm not an expert in their field, but I interpret 'functional
algorithm' to mean an algorithm whose inputs are transformed by successive
applications of functions (in the mathematical sense.)

~~~
fpoling
I guess I formulated not precisely enough. I have not tried to accuse anybody
of misusing. From books that I read I got a strong impression that the term
"functional programming" as a term is about treating functions as the first-
class entities (or even the only entities). The persistent data structures is
orthogonal to this. But I guess I just have to accept that in the field it is
a common speak to use "functional algorithms" to mean "algorithms for
persistent data structures".

Personally I see this as unfortunate as the persistence as a term IMO is much
more precise. It also remains that one also needs GC and properly accounts its
cost which this paper discuss a lot.

~~~
RcouF1uZ4gsC
The confusion is that you are thinking of function in the programming language
sense (i.e. A subroutine ) rather than in the mathematical sense (i.e. A
function called with the same arguments always returns the same value). The
mathematic definition of function necessitates persistent data structures
(i.e. You do not modify the dataset but return a new dataset with the
modifications).

~~~
fpoling
Yet persistent data do not imply functional programming. For example, one can
work with persistent data structures in Java using global variables to pass
references to data structures. One can also implement algorithms from the
article using explicit stack to avoid recursion. Yet such atrocities will not
change the conclusion of the article that the code will be cache-efficient as
long as the runtime is sufficiently smart.

So my assumption (which could be wrong) is that by using the word "functional"
that article unnecessary restricts its auditory. For example, a Java
programmer would not even bother to open it assuming this is something
relevant at best to Haskell or F#. I definitely had such expectation.

