C# or VB code is using lots of C++ code behind the scenes when compiled during run time. This is mostly choice of front end vs back end in .Net. That is why there is not much performance difference in the end. I personally prototype in VB and I am very surprised with good performance of VB code. For more critical applications code is ported to C++. I agree that using C# is one of the best choices there in terms of power, support, literature and lots of samples on Web. I use C# knowledge base extensively myself (still moving some of it to VB nonetheless)
Agree, but precisely because of this fact it makes so much sense to code most applications in C# as long as you target Windows OS. Except when top performance gains are a must C# gets you where you want a lot faster than C++ and that a lot safer (it takes much much more effort, care, and time to code safely in C++ than C#). My point in all my posts where I recommend to seriously consider C# is that when a compiled language is so simple to learn, so many publicly accessible libraries, open source code, and public scrutiny, when such language challenges the very language on which it was originally built on in terms of performance then why not perusing it. The biggest motivation to currently still keep abreast with C++ is to connect with APIs and interfaces that were written in C++. With more and more language agnostic interfaces and communication connectivity such dependence on C++ should lessen over time something we already see right now. In terms of VB vs C# it actually does not matter at all performance wise because both target the exact same .Net CLR. Its just that C# coders command a higher salary than their peer VB programmers and the vast majority of code that targets .Net is written in C# not VB. It is a lot easier to find open source code in C# than VB that complements your project. Having said that I politely bow out of the discussion as for me the choice of tools for each problem is very apparent.
I am a huge fan of simple. So I use R and python. If I need more speed I use java, c#, cython. SIDENOTE: If c# worked on linux it would blow java away. As another sidenote, I have been working with matlab recently... wow , they must have great sales people.
Would you care to elaborate? All the performance comparisons of C# vs Java that I've seen show they are fairly equivalent.
This just popped up on my radar: http://tradexoft.wordpress.com/about-tradexoft/ http://tradexoft.com/lockfree.pdf It's C++ and deemed on the paper the guy seems to know his stuff, so someone here might find it interesting. If I didn't have my hands full I would probably have a closer look at it my self.
I'm not the developer at my firm, I've got a computer science grad for that. He is versed in C#, Java, R, Matlab, SQL, and a bit in Python. So FWIW... We also do our profiling in R making use of the extensive quant finance libraries to cut down development time. He manages our database in SQL. We do a bunch of rigorous backtesting during off hours as well as real-time simulation (e.g. MCMC), so the system needs to handle both. We do some of the testing in R and some in a combination Java/SQL. The real-time platform/GUI is Java using SQL as database. The machine is basically an amped up desktop as we don't need server capability yet. Core i7, 500G SSD, 32 gigs RAM. We prefer to run Linux and I execute through Interactive Brokers, so that has a lot of influence on why Java instead of C#. We don't ever run into speed issues and RAM isn't a bottleneck.
Base on my understanding, institutional HFT would have setup like this: front: C# middle: Java Backend: C++ a very wellâturned Linux would let Java little bit faster than C#, while C++ faster than both C# and Java. In a default retail windows, C# would be faster than Java or C++. C# offers the fastest and easiest way to build GUI which is nothing Java and C++ can compare. So for retail usage, C# is the best especially for both live trading and back-test system. Seem like AB is going to have official C# API solution then makes C# becomes an even better choice. Seem like it is hard to use R to do living trading with AB or any brokerage firm. If we need to rewrite R to another language just for live trading, then no point to use R at all.
Thanks for your input on this. I spent a bit of time recently playing with Julia, Erlang, and golang recently. Julia actually seems to be quite a lovely language; reminds me a bit of Python. Scientific oriented, was able to write very terse and efficient code. Go is obviously making a lot of headway, although I am unsure that I'd use it in anything trading oriented, if only because of the dearth of existing libraries in Java / C++. All are very fine languages, and was thinking to tinker with Erlang for a data collection server, possibly hooked up to something like Cassandra, tokyodb, or another document store (not mongo!). Erlang -- what a cool language! I really enjoy learning this one, and hope to spend more time with it in the future. Forces you to think in terms of immutable state and in a functional way. Joe Armstrong's presentations are a lot of fun, too. Previous attempts to roll my own backtesting/charting platform in past times (when there was more free time..where does the time go?) were done using Qt / C++ and I found this to be a very pleasurable experience. Now, with far greater experience and abilities, I'd look to build something a bit more modular and service-oriented, possibly using a RESTful API over HTTP/HTTPS, as this is what I know from day-to-day experience. At the least, separating the front end to the back end over a REST API would make a ton of sense, allowing good/easy flexibility for future build-out of, say, a mobile trading application. JMHO. edit: Some more thoughts based on day-to-day experience. While trying to build out a gnarly SOA/modular solution makes a lot of sense for a high traffic environment (and where the human capital is available to maintain such complexity), I've found that the lone wolf programmer can do much better using a monolithic architecture where possible. Since my needs are just for experimentation/testing on a personal level, it probably makes more sense to keep things in one language, under one hood, using logical class hierarchy for separation of concerns. Still would like to at least have two application tiers to separate the front end from any business logic, though. Thank you again to all for your valuable input. Going to tinker with this at some point, for sure.
May be it would be so hard to build a live trading system with these uncommon languages. Do you have strategies on hand? The strategies are still the cord part. I think for backtest/live trade system, just pick a way to build it in shortest time is the key if making money is the goal.