On Mon, Apr 21, 2008 at 11:54 AM, Andrew Coppin
I suppose the idea is that Haskell is supposed to help you work at a higher level of abstraction, so you can concentrate on building better *algorithms* which require less work in the first place. Surely using an algorithm in a suitably superior complexity class could more than make up for the performance loss from lack of cache coherence. But people who work in C and C++ know how to build efficient algorithms too, so... hmm, we seem to be in trouble here.
I don't think things are so glum. There are certainly things we can do to control where data is located (e.g. using unboxed arrays and keeping track of strictness, and strict data types combined with -funboxstrictidontrecalltheexactpragma). In truth, C++ programs also tend to have severe issues with memory use. Garbage collection is horrible on the cache, but it's also done relatively infrequently (at least, full GCs are). Writing seriously fast Haskell code is indeed challenging, but it's a fun challenge. And writing bug-free code is also a fun challenge, and one at which we have a huge advantage over most other languages. And in Haskell we less are forced to choose between a horribly ugly implementation and a horribly inefficient implementation. David