Wednesday, July 25, 2012

Comparative Memory Management, Part 1

When Apple first announced Automatic Reference Counting (ARC) at WWDC in 2011, the fanfare was considerable. Developers took it be the best thing since sliced bread. Some called it "innovative". The whole idea that iOS and now MacOS X developers (since Mountain Lion) could be freed from error-prone manual memory management without the runtime pauses of conventional garbage collection was certainly played up by the Apple machine. However, when I saw the words "reference counting" and "no overhead" in the same sentence, I cringed. Reference counting isn't a new concept at all. Automatic reference counting is used in a number of languages including Python and Delphi, though neither of those languages can claim to be the sole pioneer. More importantly, reference counting implies the presence of a reference count for each object (a considerable runtime memory overhead especially if lots of small objects are allocated) and the constant maintenance of the reference count (i.e., reference counters for each object must be updated when new owners lay claim (retain) or old owners release).

Thursday, July 19, 2012

Scala Gotcha?

There is a weird behavior where the Scala compilers scalac and fsc take argument classpaths that contain shell expansions (such as ~/Documents) in MacOS X but not the Scala REPL scala. The REPL will still execute, but any classpaths with ~ in them will be omitted.

Wednesday, July 18, 2012

How Top Hedge Fund Managers Started Out: What environments and opportunities gave rise to these financial business titans

The rarefied world of hedge funds normally does not like to stay public limelight too long. When they end up in the limelight, it is usually more trouble than it is worth. So how did these titans of finance get started? In particular, how many years of experience did they have and how much initial capital did they start out with?

David Einhorn of Greenlight Capital started in 1996 with $900K ($500K from his parents) after 2 years at SC Fundamental Value Fund. Cite. He graduated from Cornell in 1991 (Wikipedia).

Ray Dalio graduated from Long Island University and Harvard (1973) source, and founded Bridgewater Associates in 1975 after a few years working as a futures and equities trader. In the beginning, Bridgewater was for the most part an advisory outfit. It wasn't until 1987 that it started managing $5MM from the World Bank. Source

Glenn Dubin and Henry Swieca founded Highbridge Capital Management in 1992 with $35MM. Dubin graduated from Stony Brook University in 1978 with a degree in Economics, upon which he started as a retail stock broker at E.F. Hutton in the same year. Swieca graduated from Stony Brook University and Columbia. He started at Merrill Lynch and moved to E.F. Hutton eventually.

Daniel Och founded Och-Ziff Capital Management in 1994 with $100MM from the Ziff publishing family. He is a graduate of UPenn and an 11-year alumnus of Goldman.

Seth Klarman founded Baupost Group in 1982. He is a graduate of Cornell and Harvard.

David Tepper founded Appaloosa Management in 1993 with $57MM in initial capital after spending 8 years at Goldman and earning degrees from Univ. of Pittsburgh and CMU.

Steven Cohen founded SAC Capital in 1992 with $20MM of his own money. He started as an options arbitrage trader at Gruntal & Co. in 1978, giving him 14 years of experience before starting his own fund. He is a graduate of UPenn.

Friday, July 13, 2012

JavaScript Anti-Patterns

An unfortunate side-effect of JavaScript becoming pretty much the most widely used programming language of all time is that the community has expanded in such a way that there is a lot of bad advice going around. The distribution of skills in JavaScript programmers likely varies widely (anyone have any hard data on this?). The more I study JavaScript JITs and the community, the more I realize that JavaScript is truly the assembler of our time. The big catch is that back in the days of assembler, you didn't have millions of inexperienced people putting out code.

The problem is this. So-called JavaScript patterns nearly all have to do with micro-optimizations. So many micro-optimizations have turned into folklore in the JavaScript community. Due to the inefficiency of early JavaScript interpreters, things such as hoisting array range/bounds checks have become quite widespread. If all these micro-optimizations actually made things better, no one would question the whole endeavor. However, I dare say that most beginning JavaScript programmers don't have a good handle on all the caveats and provisos which come along with each of the micro-optimizations. Micro-optimizations are being marketed as something that will always make your code faster and implicitly never breaking code. This is how beginners will understand micro-optimizations. This is unfortunately quite a bit removed from the truth. Optimizations have provisos. Modern JITs are actually quite good at squeezing every little bit of performance out of JavaScript code. It those cases where a construct cannot be optimized in general, it may be due to a lack of information, especially domain knowledge, on the part of the JIT compiler. But when the compiler doesn't optimize, the programmer cannot blindly optimize either. In the range check example, the programmer must be certain that the body of the for loop does not modify the size of the array. If this weren't the case, then checking the array length just once won't cut it.

for (var i=0, len=arr.length; i<len; i++) {

The above code will print out a lot of undefineds. Leaving the range check optimization to the JIT compiler would avoid this error. Fortunately, threading is not in JavaScript. If your typical JavaScript program were multi-threaded, this so-called optimization may cause even more deleterious behavior since the value of the property arr.len is no longer clear from looking only at the body of the loop.

Monday, July 9, 2012

Fixed Income Update

While equities have certainly entered summer doldrums, bonds have recently mounted an impressive rally. It's no surprise at this point that high-grade corporates are very popular for fixed income allocations since they are one of the few remaining bastions where one can obtain an inflation-beating yield. Since the May 22 near term trough, high-grade corporates (as represented by LQD), high-yield corporates (JNK), and intermediate term Treasuries (IEF) have rallied 3.49%, 3.76%, and 2.03% respectively. I am choosing to compare LQD to IEF because they have similar durations, 7.69 and 7.55 respectively. Though Treasuries have yet to reclaim their highs for the year (achieved on Jun. 1), high-grade corporates are looking at a multi-year high (the highest at least as far back as 2002). The correlation coefficient between LQD and IEF during the span between May 22 to July 9 stands at 0.737. Historically, for the nearly 10-year period from July 31, 2002 to July 6, 2012, the correlation coefficient between LQD and IEF stood at 0.952. The whole Treasury complex is quite richly valued at this point. Have we reached the point where high-grade complex are even more richly valued?

Thursday, July 5, 2012

What is the ML Module System?, Part 1

Browsing through the heated Scala mail list discussion from 2009 on OOP versus functional programming, I ran into a number of messages which indicate some confusion as to the role and mechanism of the ML module system. The natural question that was raised is how is a module system different from a "low-level" object system. I am not entirely sure what a "low-level" object system is but in this post I would like to compare and contrast the ML module system and object systems, principally class-based object system but also classless object systems. First, what role do these language features serve? There is some overlap in purpose but also significant differences. The ML module system was originally designed to serve to roles:

  1. To support programming-in-the-large organization of large system architecture
  2. To facilitate the construction of a type-safe container library
In contrast, OOP is typically defined as supporting design goals of encapsulation, inheritance, and subtype polymorphism. On the surface, this suggests some overlap. Programming-in-the-large may sound like encapsulation, but as I will discuss, the reality is considerably more nuanced.