you can look at event processing engines such as Esper which is open source. You can look at Apama (http://www.progress.com/en/apama/index.html). And take a look here: http://www.elitetrader.com/vb/showthread.php?threadid=236747 Then the institutional suite by Open Quant is worth a look. Nothing beats a system that was written from the ground up as I have made clear multiple times. So, if you are serious then you will agree that it will take time to setup a professional trading architecture, whether the building blocks are commercial or self-written. I do not understand how some people not expect such project to at least take a year. It is the same I-expect-to-get-rich-quick type of people that now believe they can hack away with a 500 dollar software package. It is just not gonna happen. But I know there will be a host of naysayers who disagree. Good luck in your endeavor.
If normal commercial/open-source software can handle the normal tasks with accuracy, then the only reason to build by ourselves would be HTF level super massive back-test/real time analysis which requests crazy millions/trillions calculations to be done in a second, then basically would need a supercomputer level hardware with specific design software for it, even modify OS too.
A good trading software would have excellent much-threading, even most of the full-time programmers don't even have experience about this.
It is multi threading and you seriously overestimate it. We had multi threading in our software, ripped it out in most parts - faster without, no synchronization. A backtest / optimization is now totally single threaded. In exchange we start one job per processor core MUCH faster. Same with real - unless you go HFT and need to be FIRST, it is a lot easier to debug single threaded code. You have some "stages" and every stage is single threaded. The strat is totally so.
Subtract all the fancy (and not necessary) GUI and (BS) TA indicator stuff, and you will see that it takes not long to code up a basic trading engine sufficient for many purposes. Why bother with tradelink, etc. for backtesting if you can write up tools of >= quality in R, Mathematica, Maple, Mathlab, etc. during a weekend ... In case you are not able to code up the tools ... maybe this is not the right hobby You might survive with retail shelf-tools, but not really succeed ...
Have you coded up your own trading software? If yes, then I would like to ask you following:- I am curious how long in your experience does it take to code up a basic trading engine sufficient for many purposes? Please also write the specific capabilities that such a basic trading engine would have, so that it allows for a proper mapping with the time required to code this system up. Thank You for your response.
oh yes, and of course you easily extend the language functionality if something is not offered out of the box. Yes you should definitely trade your fund's money and fulfill your fiduciary duty in terms of risk management with Amibroker ;-)
Gee, you keep on asking, I keep on giving you references to commercial packages that are much more capable at getting a decent trading architecture started. What else do you want? Should I house-deliver you one or what? And what the heck are you talking about others not knowing how to program multi-threaded and parallelized applications? Please do not talk about things you know nothing about. Why do you not search for couple multi threaded terms on Stackoverflow and lets see whether people know or not. Here some tips to get you started as you yourself do not seem to know but project on others: Async/Await, task parallel library, TPL dataflow, task scheduler, and that is just for C#. Good luck. I gave you my advice good luck taking or rejecting it. You seem to want something quick then go and seek your luck, you will need it.
I somewhat disagree. You hardly get around multithreaded applications these days even in trading architecture space. Think about the following: You run one application on core1, containing x trading strategies, then you run more more strategies in app2 on core2. So what if you want to manage a total risk book where decisions made in strategies within app1 impact the risk book and may prevent strategies in app2 from submitting new trades? You cannot realize a true global book with your approach. You could trade each app on each core in a closed container fashion, giving it its own risk caps and available capital but that is hardly considered "scaling". Even if you wanted to report to a global risk book, you would have to start sending messages over a message bus which will greatly slow down your back tests and real trading as well. Thus, I see no point why you would try so hard to avoid a multi-threaded approach where all you have to do is context switching but you would have access to shared object state. You can use concurrent/shared collections in C# such as ConcurrentDictionary to start with. The next step would be to peruse the rich task parallel library and spin off tasks. Then you can go a step further and implement an async/await framework and if you really want to see top notch performance and what .Net 4.5 can deliver then you use TPL Dataflow. That is what I am using and I stand by my claim that I have not seen a single back test engine in C++ that would beat mine in C# in terms of performance, throughput wise. Of course I could do the same as you do and run the same app over and over again, even on different machines but when we are talking backtest you hardly get around synchronization issues because of Risk. Of course it can be done but you would have to make a lot of simplifying assumptions. You could ignore global risk and in a second run actually eliminate trades that may have violated global risk limits because other strategies already reached a certain cap. You avoid all those with a multi-threaded approach. I prefer it this way a thousand times. I only split up strategies when I trade completely different accounts and hence do not need to share risk caps. Even then I frequently sync risk to a global risk book because it makes zero sense, for example to have 10 trades from 10 different strategies result in a huge exposure to eur/usd, for example.