My portfolio performance
About three years ago I created a low frequency trading system. The only reason it's low frequency was due to market data access and available resources, as there's nothing much frequency specific about the strategies I've developed. I applied my strategies so that their performance could be compared to the OBX index, in other words the 25 most liquid stock on the Oslo Stock Exchange.
So it's been a few years now, and I think it's time to do a review of the performance. The strategies reviewed here have remained unchanged for this period, and the portfolio consists of in total 9 different stocks, all part of the OBX index. There are several distinct strategies, and based on back-test performance (three years ago) a stock/strategy combination was selected so that of the 9 distinct stocks my portfolio would consists of 20 separate stock/strategy combinations.
OBX performance
The benchmark we're comparing against is the OBX index, and the time period is roughly three years, in other words from the beginning of 2008 till now (almost end of 2010, 8. of December to be accurate). A buy-and-hold strategy would not have performed very well, ending at about the same value as we started on three years ago. Not an impressive performance by any means.
Individual stock/strategy performance
Below I've put in a graph showing each stock/strategy performance. All of the strategies are allowed to go both long and short, and some of them also stay out of the market if they so chose to do. Now remember that this performance is not based on over-fitted back-testing. This is based on signals given by the strategies that I could, and indeed did trade on. The signals (long/short/close) are given after market close, and acted on the next trading day at opening prices.
I wouldn't comment too much on each of them, other than saying the vast majority have given a profit over the given period. The Y-axis represents stock/strategy value with an investment of 1 NOK at T = 0, while the X-axis shows the number of days since T = 0.
Portfolio performance
There's quite a bit of work that I could have put into selecting the optimal portfolio, doing continuous rebalancing etc. But I made it simple by doing an equally weighted portfolio without rebalancing. The system focus has been on individual stock/strategy performance and not portfolio performance, and at the moment I have a few exams to prepare for as well.
So in the graph below I've plotted the portfolio performance against the OBX performance. No rebalancing is done at any moment, so each strategy starts out with 1/20th (since there's 20 stock/strategy combinations) of the total portfolio size at T = 0. In our example this is represented by a 1 NOK total investment. This could of course be any amount, but that's not the point.
The red dots represents the daily value of my portfolio, while the blue dots represents the OBX index. It's not a bad performance at all, with a fourfold increase compared to the initial investment.
Long only performance
Maybe it's unfair to compare a long/short strategy to a buy-and-hold strategy. So what happens if I limit all strategies to being long/close only. In other words, if they wish to go short, I change the signal to close instead, forcing it to go out of the market. This isn't optimal as all strategies are run and monitored as if they could go short.
Still very good, with almost a twofold increase compared to the initial investment.
Final details
Using an equally weighted portfolio probably isn't optimal, so if there was one thing to look at it would be the portfolio construction and rebalancing routines. Also, I should include the risk free rate for investments that are taken out of the market (close signal), but it wouldn't change my results too much.
None of the results for my portfolio presented here has used any form of leverage. For those of you curious about transaction costs I haven't done any analysis on this but can say that a total of 434 long signals, 408 short signals, and 415 close signals was given over this three year period. That should be about 2 trades each day for all the 20 stock/strategy combinations combined, if my calculations are correct.
Relative Sharpe ratio
I just read Irene Aldridge blog post titled "How Profitable Are High-Frequency Strategies?".
Although no hard facts about the overall profitability of high frequency trading strategies are given, it got me thinking about something else. As Irene does in her blog post, she takes historical data and calculates the Sharpe rato of the absolute optimal, 20/20 hindsight, strategy based on historical data. Now of course, it's not possible to actually have a strategy that is this good, unless you give me a time machine and let me play with that!
But is does however give an upper range value, something you could use to compare against your own models/strategies when doing back testing. The Sharpe ratio it self only gives you a number telling you how well you're doing compared to the underlying benchmark. That is of course great when comparing two or more models against each other. But it does not tell you how much head room you have with regards to improving a specific model.
And this is where a relative Sharpe ratio would enter the picture. Take your models Sharpe rato, and divide that by the absolute maximum Sharpe ratio for the same test periode, and you have a number between zero and one. The closer that value is to the value of one, the better. I guess maybe you could also say that the more stable this value is over time, the better as well. In other words, your model can perform just as good no matter varying market conditions.
BTW Irene is the author of the brilliant book named High-Frequency Trading, a book I plan on writing a review of soon.
C++ vs Java performance; It’s a tie!
So a while back I came across this Java vs C++ performance benchmark. It was kind of dated and as the Java VM continues to improve (in addition to the C++ compiler I would presume), I thought it would be interesting to rerun the tests to see what we would end up with.
So this is what I did: I started up a new Rackspace Cloud Server of their biggest kind (most CPU and 15.5G RAM) and booted it up with Debian 5.0. I then compiled all the tests and ran them all 25 times each. I used the time utility to measure the elapsed real time used by each test and logged that for later analysis. Of the 25 runs on each test, the slowest and the fastest were removed so that I ended up with 23 sample points pr test. These 23 sample points were then averaged so that we end up with one measure point pr test.
C++
The diagram below shows (click to enlarge) the run time for each of the C++ test cases, compiled with the -O, -O2, and -O3 optimization flags. All test cases are compiled with -march=x86-64, using g++ version 4.3.2.
Not too surprising, in general, the performance improves with increasing optimizations.
Java
Next up is Java. It's run with the -client and -server flags, and the diagram below (click to enlarge) shows run time for each Java test case. The Sun Java HotSpot VM, version 1.6.0_20 was used, and as we see there's not much of a difference between using either the -client or -server flags when benchmarking these test cases.
C++ vs Java
So how do they compare to each other? In the diagram below (ones again, click to enlarge), I've taken the absolute best run time for each of the tests from both C++ (either -O, -O2, or -O3) and Java (either -client or -server) and set them up against each other.
And the conclusion? It's a tie between C++ and Java, each "winning" 6 of the 12 test cases.
Additional information
I've made available two ZIP files. The first one contains all the source code, compile and run scripts + input files (quite large, therefor the large ZIP size), and the second contains all this + the compiled files and time logs for each of the test cases.
There's also a Google spreadsheet with all the numbers and diagrams.
Finally, there were two tests I excluded, hash.cpp and hash2.cpp (available in the ZIP files), as the C++ compiler complained and refused to compile the source code due to a deprecated or antiquated header.