Quote from LeeD:
Do you hint you were programming in assembly language as opposed to relying on an optimising compiler?
I assume that he meant that he either realized there was a redundancy of calculation so that the floating points could be run outside of the loop, or as was the rage, worked with all integer market prices (# of ticks so 102 15/16 = 16*102+15).
As far as compiled code vs JIT compilation, I don't really care. I tutored a private group on x86 assembly language many years back, and I based most of my lectures on "here is the C code, here is the resulting assembly, let's understand how they are the same." Since the students were capable programmers to start with, it went more productively than discussing J-cells and bus architectures. The reason that I bring this up is that I was appalled at what poor assembly code was actually coming out. As someone whose Cray research time allocation was 10-100x my paycheck, I spent a large amount of my time making my code almost incomprehensible in an effort to tune it to the particular architecture of the machine. Heck, I still run my loops backwards as a matter of habit "for(int i=count-1;i>=0;i--) {}" Machines are so fast, so simple, and so cheap nowadays that it isn't worth that much attention. When I do try to squeeze my code, the biggest payoffs tends to be string handling and disk IO. The fewest string allocations the better even if that means concatenating it all at the end. Being able to read and write whole files at a time has made life so simple and so fast. Having gobs of memory is great.
All of this is irrelevant to the original post though. Prospective customers want to see results, and they don't care whether you need more or fewer servers to deliver their working trading system. The key features were
-User written programs/strategies can run on the server AND on the client computer.
Dual server/desktop operation: Respondents have assumed that this software will be licensed to trading houses and run on their servers. Big assumption. If not, there are a myriad of problems such as "is my system no longer making money because someone else's system is hogging the bandwidth." If it is licensed, then it remains to be see if it is actually better than what they already have.
-User written programs are not script languages. They are COMPILED for the CPU where it is running. No Java and No .NET, this is the real deal!! It means you will be able to use your 64bit computer(S) at full steam.
This seems to imply that since your servers are 64bit Windows? that all of the desktop system developers must also use 64bit Windows. Not completely unreasonable, but some shops may need some 16-bit legacy stuff like TWAIN. Gotta remember that selling software is different from making software. Avoid giving the customer a reason to say no.
-Event based strategies: your program will react to events like orderFilled and newTick.
Nothing new there.
And the behavior is guarantied to be the same for back-testing and real-time.
Even with systems like NANEX which guarantee to deliver byte-for-byte the same result (except some communication status codes) regardless. There are still communication issues, software upgrade conflicts, server failures, and general timing issues which can not be guaranteed. (If your particular data connection stopped properly receiving Level II quotes for an hour one day, would you really make people back-test without Level II quotes?) Maybe it is a good idea to come up with a stress-test battery where people can test their system against a script of anomolous complications, but guaranteed identical?
-Use of huge amount of cached calculation. We already have the back-end for this.( As of now we haven't decide if optimization will only run on client side only, but this could be the case ).
This has been clarified to mean that you are providing support utilities to help the system writer judiciously accelerate their back-testing. Fine, but we get back to 90% of traders being non-programmers and 99% being alot more focused on their trading than their coding. Sellable value? I like the way that NinjaTrader has made caching transparent. May not be optimal, but it doesn't get in the way either.
-You can use more than one computer for total collaboration and sharing of calculation. They will use a similar architecture that we use for our severs.
Not really sure what that means. There have been massively parallel Internet based cryptographic challenges that made sense, but when it comes to tick-by-tick back-testing, bandwidth costs. And if this is a shared server environment, rather than a licensed package, I see major problems with resource sharing. One trader selects a very specific strategy to run over a small dataset, and another brute-force cherry picks from an astronomical number of parameters over a ill-considered dataset like "All Stocks". Part of cloud computing is managing customer utilization to maintain the illusion of free, unlimited resources.
Good Luck to you anyhow.