I claimed you dont have much programming experience otherwise you would not make a dumb claim such as that developing a quick and dirty script is Ami is a pain or difficult. Saying such shows you have not at all understood how to write custom code in Ami which operates on vectors and arrays rather than running through single dimensional variables. What do you consider "modular code"? If you want a develop code utilizing the strength modern OOP languages afford then you are wrong to go with Ami but also wrong to go with Tradecision. I give that to you. But I told you already, there is no one size fits all solution, not in retail space and not elsewhere. I suggest you start developing your own code as you claim you are a top coder. And if you have not come to this conclusion by yourself then I highly question your programming experience claims. Simple as that. Stop wining and bring facts to the table rather than shilling Tradecision and claiming everyone else, who compares this piece vs other apps, is hijacking YOUR thread.
finally someone who knows what he is talking about. OP, I recommend you get off your high horse and listen to people who used the software that you asked all of us to mention to you in case we believe there is something better out there than Tradecision. Yes there is, and for certain aspects its Amibroker, for others its coding your own from scratch, and again for other purposes its gonna be something such as RightEdge or Smartquant.
At this point I have to agree with AsiaProp. What you say is pure sales speak. "Zero-lag"? There is a necessary lag from comuunicating via a network to the exchange. Even if you discard that there is a (small) lag due to multithreading in Windows or Lunux. Some platforms claim to be able to produce a trade signal before they finish receiving a network package carrying the price quote that triggers the trade. Even these don't have "zero" lag. Just their lag is better than others. Also "price noise filters" are very common among trading platforms and even if the platform desn't support one as a separate entity, you can often implement it the way you want as a part of a trading system. You are talking about toolboxes.... Well, maybe Tradecision is a toolbox (i.e. a number of assorted components that you can easily to put together to make something useful) but what other posters are talking about are "platforms", that is software that can collect streaming quotes from hundreds of active symbols, handle charts at volume peaks and do all the rutine work so that trading systems have to cover only trading logic. Regarding neural networks... sorry to say this but neural network toolboxes are the worst waste of money. (Rates just below playing roulette repeated till there is no money left.) Most of them are too primitive and too expensive compared to neural networks that are not advirtised as "trading" ones. If you don't have expertise to use neural network to an independent trading platfor, chances are you don't understand how neural networks or trading platforms work and shouldn't use them. Neural networks is a very special tool and it is at the very least strange to expect it to be a part of a trading platform.
Hello, So I will not be advertising any products or endorsing toolboxes. I do, however own a commercially available multi-broker trading platform software company and I understand how the platforms connect and speak with each other as well as execute trades in all standard formats as well as several non-standard formats. Additionally I was a well respected programmer for a number of years that worked on several very complex problem solving routines using neural networks in the late 90's. With all of that out of the way, I would say that using a NN function or method to apply in a trading environment would most likely pose several problems. In no particular order; 1) Reliability and speed of factored results 2) There is no known logical reason that I can find to specifically need to do any computational analysis using a NN that cannot be more reliably calculated in other, more efficient ways, not to mention more reliable ways. 3) almost any market data based calculation can be made _faster_ than you update your price feed without any need for a NN, and if you add a NN no way will that be faster than other methods we use everyday to make complex calculations dynamically now. My point is that using a NN for an essential ingredients list to a toolbox for programming into a trading environment leaves me scratching my head as to why exactly that would be important. Again, I don't know much of anything about what the user wants to do but I understand trading platforms, quant analysis using dynamic calculations, and trade execution routines extremely well. Also, experience tells me that trying to force a NN into this environment is likely to have the possibility of introducing some rather complex errors from time to time. My 2 cents worth, Peace Out.
I'm curious. Does AmiBroker support multi-core parallelization? Somebody did a portfolio of multi-strategies per symbol brute force optimization with a single symbol on TickZoom on an 8 core machine. It took 2 minutes where it took TradeStation 60 hours. TradeStation, of course, still uses a single core and is slower than AMIBroker in general. Still, that performance difference was a combination of 3 features of TZ. 2 of which may or may not be in AmiBroker. 1) multi-core support. 2) Optimization runs all passes in parallel, simultaneously which slashes the overhead of data processing per pass. 3) high performance code. You're right. Never seen any benchmark comparisons to AmiBroker.
It appears after Googling that AMIBroker only supports a single CPU for optimization and historical tests. So on a single CPU it's a toss up who will win, AMI or TZ. But if you compare on a dual core or quad core or larger, TZ will always win by a long shot, most likely.
I have noticed your posts commenting on AmiBroker and I would like to offer you some insight. It is not true that AmiBroker uses single thread. If you run Microsoft Process Explorer on AmiBroker you will find that it runs at least 5 threads (sometimes more). For example if you run it with IQFeed as data source, it will use separate thread for application itself, separate thread for streaming data and upto 5 separate threads for backfills. BUT... it uses separate threads only when it makes sense to run separate threads. Not always running more than one thread is most efficient way of doing things. One striking example is AFL engine. Since about 2005 I have been doing various experiments with OpenMP (google if you want more details on what it is) and parallelization of AFL engine on various CPUs. And what are my findings? My findings are is that with highly optimized, assembly level code that AmiBroker uses for AFL engine internals, in some places hand optimized with SSE (streaming SIMD (single instruction multiple data) extensions), the SINGLE CORE of CPU is *waiting* for memory. Yes. Single core is able to fully saturate memory bandwidth even on i7 triple channel DDR3 memory. What happens if you forcefully run multiple threads ? It gets SLOWER, because cores interfere with each other for memory access. This is all based on actual measurements I did using several different compilers and CPUS including Intel i7, Core 2 Duo and AMD Athlons. Multiple threads give advantage only if you have high compute-to-memory ratio (lots of computation with few memory accesses). But this is not the case for most data crunching like backtesting for example. Nowadays memory is much slower than CPU is (that is the reason why CPU vendors put bigger and bigger caches) and that is the reason why multi threading does not give speedup if you exceed on-chip cache size. So to summarize - AmiBroker uses multiple threads but not everywhere, only where it gives actual speed increase. Naive "multi core" thinking leads often to performance drop. Best regards, Tomasz Janeczko amibroker.com
Thanks for the in depth reply. Very interesting. After reading up on L1, L2 and L3 cache effects in multi-core CPUs. It was informative. If other want to see the link where I found the most clear info: http://igoro.com/archive/gallery-of-processor-cache-effects/ One observation is that cache hits require only read and possibly never write to the memory to gain those benefits. Specifically, if you modify even one byte in cpu cache line, it invalidates the cache for reads and must be refetched, right? So for AMIBroker to heavily utilize cpu cache, doesn't that imply that all calculations must be done in advance? And to be specific, doesn't that presuppose using bar data only with the high,low, close already pre-calculated? It seems that benefit is lost in real time trading where the high,low,close are constantly changing. Maybe that explains why you find a benefit of multiple threads in real time. Also, it means in historical that you can't use strategies that want to see the daily bar as it develops with the high,low and close changing for the current bar as the day progresses, right? It seems the institutional type, high-end platforms that operate with tick data have the high, low, and close constantly changing as new ticks arrive even during in historical testing, so you can test more types of algorithms for orders or more precise simulation of real time, live trading. It seems TZ works like the latter which is why it benefits so much from multi-core machines for historical. Another question, does AMIBroker support multi-symbol portfolios? If so, how do you keep all that data for 100's or 1,000's of symbols in the cpu cache? Or do you run all the symbols in a portfolio symultaneously? Perhaps you run them one at a time. Some platforms do it that way which makes it impossible to do any type of cross-symbol statistics, strategies or program trading. Intitutional type systems like TZ always run all symbols synchronized so strategies can historically test pairs, baskets or other types of cross symbols algorithms. That benefits hugely from multi-core CPUs in historical testing. Still it would be nice for someone to do benchmarks in different scenarios. That's because one platform may be far better in a certain scenario like a single symbols strategy testing whereas another may be faster at historically testing a portfolio of 500 symbols. Another scenario is testing "scanner" strategies that have 1 strategy X 1000's of symbols. How does AMIBroker handle that kind of thing.
Does this assessment sound correct? It was very interesting to read the "array based" explanation of TickZoom. Very clever! http://www.amibroker.com/guide/h_understandafl.html Near the bottom of that page it says: So it's important to realize that if a user has strategies that benefit heavily from array based calculations (similar to a spreadsheet) then running on AMIBroker is going to be faster than anything out there. However, if you need any kind of "if else" logic then AMIBroker correctly says doesn't work in array based mode, in that case you need looping. It's finally important note that if you need the looping features with if/else logic then you instantly need the power of multi-core computers since you can run loops in parallel, one for each symbol or one for each optimization process. With array based, it's clear that you never benefit from multi-threading and will be lightening fast with AMIBroker.
Yes, AmiBroker supports multi symbol portfolios. It is the fastest portfolio level backtester available today (10 year backtest of 100 symbol portfolio under one second on low-end machine). AmiBroker uses LIVE data and does not need or use any "pre-calculation" With regards to the CPU cache and how they are utilised - all your divagations are completely incorrect. Cache lines do not need to be refetched on each read/write cycle. There are cache coherency mechanisms in the CPU that make sure that data are not refetched when not needed (if for example one core only accesses them). Also current CPUs triple channel read 192 bits at once (thats 24 bytes), it does not matter if you need one byte or 24 bytes - RAM access time for both is the same. Also you forget the fact that quotation data is not one byte. Single Timestamp+OHCLV quote is at least 6 (items) * 4 (bytes per item) = 24 bytes. Such amount of data is actually fetched from RAM in single step. If you want to learn more about how AmiBroker works then reading User's Manual is recommended. With regards to if-else logic - Amibroker is able to do if-else logic in fully vectorized manner (array-based) using IIF function. It is run as fast as any other array based code. "Classic" looping is provided for people who are not familiar with vector processing, as not everyone is immediately upto speed with "parallel" thinking. Regular (scalar) if-else statements are also faster than you think. Why don't you download a trial and check for yourself, you will be surprised how much faster AB is than anything else.