Performance

The basic heuristics and algorithms I envisioned a year and a half ago have stood up well to testing, both internal testing and using external beta tester and client data.  Lessons learned have largely been associated with learning what is important to institutional investors.  Some of those lessons:

  1. To date, every client has avoided long-short portfolios.  All of my initial clients have asked for strictly long-only portfolio optimization. Based on their directions, I have temporarily incorporated a “zero-floor” for all securities, which modestly speeds up the optimization process.  (Note: this constraint can easily be reversed.)
  2. The initial portfolio-optimization code ran open-loop; that is to say that any asset could be assigned a weighting between 0 and 100%.  Generally, extreme asset-weightings were mathematically avoided for the majority of the “optimization surface.”   However, all Sigma1 clients have requested individual asset minimum and maximum asset-weighting constraints.  While these constraints somewhat reduce the enormous search space, in practice, they tend to slow down the heuristic algorithms.  Much of my optimization effort has been focused on efficiently enabling individual asset range constraints.
  3. The third major lesson was that some clients want layered asset-class constraints.  This capability has been incorporated into the base code.

The primary thesis behind HALO Portfolio Optimization is that compute technology and algorithms have sufficiently progressed to optimize portfolios beyond simple mean-variance optimization (MVO).  Moreover, creating a set of three(an efficient surface) of portfolios optimized for multiple objectives (three: risk1, risk2, and expected return) is performed, rather than a simpler 2-D optimization.

Much more run-time optimization is on the Sigma1 road map.  The primary speed up is via conversion of increasing conversion of key parts of the HALO Ruby code to C/C++.  In the meantime, upgrading to arguably the fastest processor on the planet, the Intel i7-4700K, has shown a 2.95X speed up over benchmarks running the i5-2647M CPU running Ruby code that is currently the HALO Portfolio Optimization run-time bottleneck.  The primary operations are (billions of) double-precision floating-point arithmetic computations.

The HALO portfolio-optimization algorithms/heuristics have already “fast enough” for every single institutional investor we have worked with to date.  That does not measurably dampen my personal desire to push optimization speed to its limit.  I intend to crush previous performance benchmarks, again and again.

Does a hard-working professional investment advisory team need optimization to faster than 30 minutes?  I’d argue “No.”  But do they want faster, of course “Yes!”  If the crunch time is reduced to 5 minutes — the same logic applies — they want faster.  I understand.

It could easily be argued that it would be better to apply my efforts to developing the web UI.  I am, in parallel, at my own pace.  Currently, however, my passion is speed.  Having achieved some speed, I crave more.  When I follow my passion, my productivity is dramatically improved.  Moreover, the skill set I am trying to master has intrinsic value beyond the field of portfolio optimization.  Fun and profit, in a start-up, is often more important than maximum profit (or maximum revenue).

The HAL0 algorithms and heuristics are intrinsically fast and scalable.  Since I am not planning on sharing their inner architecture (except for millions of dollars), the proof of their power is measured in raw performance.  If that effort results in temporary loss of revenue for enhanced future revenue, then so be it.

 

.