Quote from fullautotrading:
I wish to give you some constructive advice. It's unrealistical to think that any user will find useful something that not even the creator uses actively.
In my experience, it's impossible to separate the implementation aspects from the strategy aspects. It's not sufficient to know how to code to make a platform which, for instance, an hedge fund or a community of traders will be happy to use. If it were so, all programmers would do this activity. It takes much, much more... and your users must be inspired by your <b>enthusiam for trading and strategies</b> ...
If yourself are not able to use profitably your tool, there might be no user that will either. Just because there is a <b>profound design problem</b> at the basis of a <b>profitable</B> system, and if the design is flawed, there is no way to create anything profitable, for any user. Take programs like WL, for instance. Once the design is conceptually flawed, there is no way to come out from the empasse. The program may become a "curve fitter", a creator of illusions ...
Tom
Thank you, Tom, for adding the acronym AOT=Ahead-Of-Time for the type of compilation/optimization done by C++ compilers. When I wrote earlier, I had to say "compile-time optimization vs JIT", but I only did that for lack for knowing the AOT vs JIT.
Aside from AOT vs JIT, the subject of optimization is broad. We can all agree that taking calculations out of the loop is a valuable tactic, but actually, like most optimization methods, it depends on the hardware.
As our servers get more cores, we are quickly coming to fine-grain parallel computing. By fine-grain parallelism, I mean using many cores to execute the same instructions concurrently. The importance of this can be seen by the growing support by Microsoft and Intel.
I have spent plenty of time tuning socket servers built on coarse-grain parallelism. (Have four threads paused waiting for the next batch of quotes. If a second batch arrives before the first is completed, wake a second thread to leap-frog on the first batch. Once you have four threads chewing on a batch, other threads on the system are getting starved so yield, sort, bunch, and try to catch-up. ...) With fine-grain parallelism (distributing operations across multiple cores), memory management is all so important.
In the example of taking a calculation out of the loop, this is often a poor choice when using parallelism. If it the inputs need already be pulled to each core, then often, it is faster to let each core produce its own copy. Optimizers will still keep it to one calculation per core, but the issue isn't as clear-cut as it originally sounded.
LeeD, I am glad that you were right about loops of addition being optimized to multiplication in certain situations.
I agree with many on this thread, that it is the delivery of useful features to market that matters the most. The software architects with whom I have worked are far more concerned will timely, scalability (network bandwidth, security, and redundancy) then CPU load. Code optimization is something that can be done post-profiling. (That is the point of having a profiler isn't it.)
I have code that correlated most futures and equities multiple ways in multiple timeframes. It spends hours doing floating-point. The thing that mattered most when I optimized it, was memory management. The memory cache is big enough to fit a few data histories. I reorganized the calculation to load a few series in cache, and then compute the combinations. I wouldn't be surprised if a .Net JIT version with this clumping wasn't faster than an AOT version done in the unconsidered way.
Mhtrader, the Advanced Market System's platform (not available for sale at this time) does support .Net plug-in studies which can update every trade, Level I quote, and/or every Level II quote for a whole portfolio (1000 equity symbols tested.) It is AOT compiled, but the idea of doing this is not unique.
My earlier point that this trend began as a business/features discussion is still valid. Having a product and being a successful business are different things. Facebook is not in the news for having solved a technical challenge which allowed social networking to become a reality.
Tom, I disagree with you that a basic design decision can be a truly fatal flaw in a platform. It is not that I disagree that design decisions can be truly hampering. Quite the opposite, I have consistently found that as one takes the concept and makes the reality, there are a myriad decisions to make. And as one makes decisions, following decisions depend on earlier choices creating design paths. Much like the game of chess, many architectural decisions are intractable. That is why people are shifting to iterative design principles such as Agile. Just as with a trade, one doesn't want to overcommit to an earlier decision. On the other hand, to get the iteration process to converge in a timely manner, it is often necessary to curtail discussions similar to the AOT vs JIT flame.
. Now, the editor and the publisher of the journal, are also impatient (i have anticipated them my research) because the publication of a breakthrough will make the journal among the top ones, and probably the publisher a rich man.
my production 
) So i get so carried out with all the technical details and concerns around some aspects my task that some time passes (in the meantime i also had to learn c++ 
. I rewrote the all thing in assembly, and now it seems ok).