> Of course, matrix multiplication is a trivially simple task. (That's why 
> they chose it.) But now consider building a huge, highly complex program 
> that does a crapload of numerical work, and trying to figure out where the 
> hell the performance is going, and how to fix it... Good luck with that.

Even in huge programs the bottlenecks are often only due to a tiny 
proportion of code running a vast number of times (for instance, I am pretty 
sure almost all of the CPU time for my CFD solver is spent inverting 
matricies).  Compilers are already quite good at optimising such things, but 
it appears they can still do a lot more.  For example they already can spot 
fairly basic patterns in read and write locations and rearrange the 
instructions to give better performance, adding more complexity just means 
more work for the compiler writers and handling more special cases.  Whether 
anyone can be bothered though is another matter...

> Would you like me to use lists, immutable arrays, mutable arrays, unboxed 
> arrays or parallel arrays? Should I use 2D arrays or 1D arrays? Should I 
> allow integers or doubles, or stick to only integers?

You could do a similar exercise to what the guy did.  Start off with a 
really "obvious" way of doing it, then try out different things and time 
each one.  Make a nice list like he did showing how much faster you can make 
it than the "initial" version.

Post a reply to this message