[montereynack]

I have mixed feelings on this article.

On the one hand, I know this is a sentiment that I’ve seen echoed amongst some of my colleagues. Simulation codes just don’t FIT, sometimes, into the neat little box that these mature hardware coprocessors try to put them in. It’s easy enough for ad revenue peeps to adjust their data and models to a new architecture, since the only will they’re obeying is their own and the computational reality is more-or-less whatever they want it to be. With simulations a lot of these assumptions go out the door, because now you can’t just disobey fundamental laws when convenient. If you need to go through a calculation on a single core because you have to evaluate every state sequentially, sometimes that’s all that can be done.

On the other hand, this article seems to be subtly beating the hardware co-design drum, which in my opinion isn’t always a good idea either. One argument could be made that limiting ourselves to one computational approach actually encourages creativity because it encourages some bright young researcher to come up with a new way of looking at things to make the software better fit the hardware. An argument could also be made that co-design is sometimes a bad idea because it might result in things being shoehorned in when they have no place. I’m certainly guilty of experimenting with FPGA implementations which, at the end of the day took so long to compile they would never be useful.

As in all things, I think in this case both “sides” have a little something to offer.