|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |