I was merely arguing with your broad generalization that it is difficult and expensive to take systems not designed to run in cluster/parallel and adapt them to such a processing architecture. The transition is trivial where inter-node communication is minimal. Just split the data and/or parameters to survey among nodes. You are probably talking about the opposite extreme with high inter-node communication requirements, something most intelligent system testers/traders would try their best to avoid from the start. High inter-node comm. is more appropriate for massive computational fluid dynamics or finite element simulations... 3D or 4D data, not for analysis of 1D or 2D market data unless one is doing heavy statistical arbitrage between 100's or 1000's of markets or something like that. Otherwise for most market data analysis problems you rarely need a high inter-node comm. architecture. I have designed my architecture to maximize memory locality and to naturally split the problem into multiple independent optimizations that can run for hours without any inter-node communication. That's a scalable and easy solution, attainable by anyone who understands the basics of algorithms and processing architectures, for both backtesting and real time trading.Quote from linuxtrader:
Its not an argument, merely an observation from about 20 + years writing massively parallel and not so massively parallel systems. Even people that claim to be expert in these areas have produced system designs that were astoundingly bad with very poor quality control and testing during their design development phases - essentially rendering their systems salvage.
Again you generalize too much. As long as there isn't any need for extreme inter-node communication, it does not matter so much how the code changes. Just distribute the new code among nodes and implement a method to assign different data, markets, or parameters to each node. Problem solved.Yes some of your points are valid but, each system is essentially a custom build for these problems: even slightly different requirements for an optimization can change the program problem regime enough that only a very clever design will make multiple problem regimes tractable: these are few and far between ....