C++ C# or C for backtesting (no ninja or multicharts C#, vanilla only with libraries)
I am wondering if anyone has any experience doing backtesting and pricing in C/C++ family of languages. I want to exclude ninjatrader and Multicharts C# versions due to the fact it is actually wrappered using their own proprietary platform. I am thinking in a platform independent and totally customization solution.
I was looking at QuantLib library. Anyone have any experience?
For a end to end tech stack, from backtesting to deployment I think C family languages will execute the fastest but develop the slowest. Also opinions on the garbage collection of C# vs C++? Any thoughts?
The following 2 users say Thank You to treydog999 for this post:
I've build my own test environment to be independent from other Software vendors. It's a tough way because you have to build every functionality by yourself. But therefore you can focus your work at special topics, which are much important for your type of system. It's not a generic approach, but you can iterate thru your system development much faster. I use C# because i have to develop as fast as possible. It doesn't bother me if the backtest runs in seconds or minutes. You can even optimize C# code.
If you use plain C# and common components you can always transfer your c# code (trading system core - no gui stuff) into c++ code easily. There are a some tools for it available.
The following user says Thank You to Koepisch for this post:
Thanks for the reply. What do you think of doing your stuff in MATLAB / R / PYTHON for rapid proto typing first then "translating" to C# C++. I mean it is a lot of hassle and may introduce new bugs, but it may be worth it as you can test more models more quickly. Although I think the end to end tech stack solution has a lot of pluses it also requires the most amount of development time as you mentioned. Atleast R / MATLAB / Python have pre built backtesting and statistical analysis tools vs say C++ which has Quantlib but its pretty stark compared to R which has 8000 or so librarys.
I looked at python and numpy in the past, but because i was new to it i never would as fast as in my current programming language. For myself i don't waste any time in searching for the approbiate library or getting familiar with it. If i need a functionality i'm much quicker in doing it myself with lots of freedom how to do it. But if you want get much of common statistics/functions which a "Quant Lib" provides, then invest time in evaluating these libs.
The following user says Thank You to Koepisch for this post:
For the last 5 years I've used R as my primary quant tool. The number of functions and libraries is vast. And over the last year and a half the execution speed has become very high, probably due to the core routines being converted to c++. The greatest advantages, compared to other platforms and systems I've used is in the very powerful date/calendar management libraries, wide variety of high-quality graphics and charting packages, and finally the comprehensive statistical and optimization tools. Also useful are the data loading connections to a variety of the usual data sources. Also its free.
The R user community has grown rapidly, especially over the last 3 or 4 years. It is well on its way to outpacing SAS as the most popular data analysis system.
There are two challenges to using R (1) The script-learning curve is a bit steep. The syntax is powerful, but is a somewhat confusing mix of functional and object-oriented paradigms, and (2) Choosing the best libraries amongst the >5000 and counting, is a challenge. The best starting point is to read some of the introductory articles and guides found on the R foundation web site. It's worth considering if you plan on extensive back testing and modeling efforts.
Thanks for recommending R, I am actually fairly well versed in it myself. However it is just not fast enough. Yes the underlying libraries may be written in C/C++/Fortran, however control structures (for loops, if else) are really slow. apply functions works fine if you just want to run something against all the rows of something, or all the columns of something. But it does not work for creating an event based back tester, which requires for loops in order to expose each new event or tick.
Also the multi core/parallel functionality of R is low, python is worse with its GIL(global interpreter lock). But if you are going to work with intraday data on dozens of instruments your going to be waiting hours. C#/C++/Java etc have much better parallel computing capabilities.
To answer your original question, yes I have experience with C# and backtesting. For similar reason as Koepisch, I am more productive with C# syntax. For me, coder productivity is the most important thing. Coder enjoyment comes in second. Execution performance has not been an issue for me with C#.
Now, that being said, If I began my journey today, I would go with Python. I am slowly switching over to python in my dev environment, fwiw.
For me, python is also enjoyable to write. The syntax just makes sense to me, where as when I started (and failed) to learn R, it was nothing but frustration. I knew I wasnt going to be happy so I stopped early in to my education.
Python also has a following in the data science community. In higher education it appears they either will gravitate towards python or R. So I guess either will be fine. My thinking is that if you come from a computer science background you should go python, and if you feel more comfortable working with GUI based tools, then maybe you might choose R?
I've been reading a couple interesting opinions here regarding building your own, independent trading platform, so ditching any third-party software. I'm an intermediate level programming skill trader, basically in C#. I've been wondering if is it really worth programming your own platform in a Broker's Api, looking for achieving better performance, solving sync issues...etc To be honest I've been analyzing a couple of advanced samples and it seems to be really out of my league.
Any comment will be highly appreciated
The following user says Thank You to pstrusi for this post: