From: Dale Johnstone (DaleJohnstone@email.com)
Date: Sat Apr 14 2001 - 09:41:18 MDT
>If things really are bandwidth-limited, then that actually moves the
>project into a rather interesting software space. Go ahead and write the
>extra debugging check; perform all kinds of pattern-checking operations on
>the data as long as you've got in in memory; and, why not, do the whole
>thing in an interpreted language since there's no real speed advantage for
>C++. Could be fun.
That would be fun, but the picture isn't quite so black and white. You can always get performance gains by rearranging *when* you access your data. It's a balancing act of keeping the bus busy, yet not too busy your app is waiting for data.
If you add those extra frills you'll wind up with even worse memory access patterns and worse performance. Since processors are more and more dependent on their caches for performance, it pays to keep your data sizes down to an absolute minimum and use algorithms with cache friendly access patterns.
Being bandwidth-limited means your app can't go any faster because it's waiting for memory. This doesn't mean you app won't go any slower if you try doing more stuff - it will, especially if it uses more memory.
Of course execution speed has to be balanced with development speed. Since developing a seed AI is far from being a well-worn path, I would suggest you concentrate effort on the development issues (like flexibility) rather than speed issues. After you've nailed down exactly what various components will be doing, you can rewrite them later (or they can themselves). But just watch your memory consumption (e.g. no Java).
Many developers these days seem to take the speed of development approach but never finish (or start) the optimization stage, which is fine if you've got a business to run, but you can take that attitude too far and more often than not it's simply an excuse for sloppy coding. Over the years, during my transition from assembly right through to Java, and back again to C, I've argued the optimization case from all points on this spectrum. There is no single correct answer for all situations. As ever, the problem dictates the solution. In this case it's complex, demands speed, uses lots of memory, needs flexibility and wants to be done by yesterday. I would expect a wide range of tools, languages and innovative techniques to match each problem domain as part of the solution.
Sounds like even more fun.
Regards,
Dale Johnstone.
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:36 MDT