C++ Optimization Manuals

Not new, but someone was asking me about this the other day… here you go – OpenOnload docs from SolarFlare

Suicide by C++ And How to Avoid It

Really – look at this code…

I had to look at it a few times. Cool, sorta wacky.

try_
[
    f(arg1)
]
.catch_<runtime_error>()
[
    cout << val("caught runtime error or derived\n"),
    throw_()
]
.catch_<exception>()
[
    cout << val("caught exception or derived\n"),
    throw_()
]
.catch_all
[
    cout << val("caught some other type of exception\n"),
    throw_(runtime_error("translated exception"))
]

Good old reference on basic C++ performance

Contains things like details on:

• type conversion
• base class functions
• cost of virtual, vs non virtual, vs static calls
• inlining
• multiple inheritance
• various casting operations
• time overhead of various exception mgmt schemes
• templates vs inheritance
• object construction
• temp objects
• templates
• std::string usage
• etc.

We have just had Scott Meyers come for his Fastware C++ course. It was/ he was very good. It has me me thinking about fast C++…

Optimizing C++

Just some reading on optimizing C++.

Also the Intel manuals are useful.

Also – the Intel(R) Threading Building Blocks

I have been thinking quite a lot about a few programming topics:

• Correctness – how do we make it easy to write correct software
• Size – how do we curb growth in size of our software (characters – not just lines – it all counts!)
• Understandability – how do we keep our software simple looking
• Parallelism – how do we really scale out across CPUs, machines from a language perspective
• Performance – how do we keep all of these other things AND have performance

All in all – I am after a functional/ functional hybrid language in order to achieve improved correctness, reduce size, increase understandability and promote parallelism. I have been working on a ‘pet project’ – mini-exchange for matching orders – a limit order book system. This has got me thinking about extreme performance.

Recently a former colleague went to work for the LSE, while another went to go work for a low latency trading group @ one of the banks. In light of recent events (the LSE is going to abandon windows) and when considering the experiences of reality – I think windows is simply not the tool for exchanges/ low latency trading – at least not now. This is much debated and I do not want to debate it – just to state my opinion.

Windows is not the solution for high frequency trading ’nuff said

Now – I have classically spent most of my professional development career working on windows machines developing software to be used by traders. I have done Java programming, some C++ programming, ruby and a zillion other languages for play.

Here is a good pointer to s set of writing on windows vs *nix performance.

What functional languages offer what performance?

Functional languages will win in the end for all the goals I have  - especially the languages that allow some OO-isms. I am really a fan of several functional languages. I have been doing small to mid size experimental projects with Clojure, OCaml, F#, Clean, Haskell and a few others. I have done some work on my mac, some on windows, some on Ubuntu. At the end of the day, this is all well and good – and with my 1st caveat (not just windows), the next question is what language on what *nix?

Here are a few links to the great language/ performance shootout

• Ubuntu 64 Bit Quad Core
• Gentoo P4
• Ubuntu 64 Bit Quad Core OCaml vs C++ Intel
• Ubuntu 64 Bit Quad Core OCaml vs Clean

You can see a few basic things here. Currently - C++ GNU g++ is the best perf across the board- not surprising at all.

Essentially we see that OCaml is fast – from 1-3x slower than C++ – max, similar for memory – certain tests OCaml wins, but mostly 1-3 multiplier for memory size. OCaml – unsurprisingly wins – code typically 1/2 the size of the C/C++ code. Clean is also fast in many cases. In certain cases it outperfs OCaml, but mostly OCaml wins.

In many – less trivial cases I bet that OCaml/ functional solutions will compare with C/C++ because it will be easier to make them small, understandable, less redundant etc. For ‘benchmarks’ where you can optimize the code in a small area – you can be as obtuse/ obscure as you need to in order to optimize for the benchmark. It becomes increasingly difficult to scale your software and maintain its performance if it is in some obscure form. Program size and understandability become very important – even to performance as the software scales up.

We need a higher performance functional language in order to use it to compete in the arms race vs uber low-latency trading systems. If we can write low latency trading systems that are competitive with C based systems on *nix machines. 3x slower worst case is still way to slow. It is not 30x slower like F#/ mono – but it is still too slow at that level of competition. Haskell is doing better these days – raking 6th after c/ c++ and java servers. OCaml and clean are a bit behind – but doing OK relative to the bunch.

Abstraction costs performance

Ultimately c/c++ abstract the computer for the most part – they abstract the computers memory and cpu resources. Functional languages are more abstract – they try to hide away the hardware-ness of the computer. This has a cost. The cost is still performance. The value for cost is size, understandability etc. Hopefully we can get the perf more in line and then we will be onto something…

OCaml Trading

Old news, but an excellent watch – Jane Street does trading using OCaml, here is a video…

ATS

Interestingly ATS is a programming language I never heard of. According to Wikipedia:

The performance of ATS has been demonstrated to be comparable to that of the C and C++ programming languages.

and

ATS is derived mostly from the ML and Objective Caml programming languages.

Now this is interesting…. According to the most relevant current shootout mentioned above, ATS is at worst 1.83x worse than C/C++. This is not a bad start. I bet that we could improve that number and we would have a functional – OCaml like programming language that is nearer to competitive with C/C++….

Wow – I have been a fan of Redgate for a while. I have used some of their tools in the past (Ants, Sql Compare). In the past I have liked Apex SQL Edit for my SQL Server specific SQL Coding. Well – now Redgate is offering a free SQL Editor here. This comes via my pal John.

Gotta love free stuff;

Chris

I just wanted to make a few quickie comments on mock frameworks. I have been using Rhino Mocks daily. It is great. In the past I had tried NMock and just found it too clunky.

In short – NMock leaves you with a lot more ’stringy’ stuff to deal with. Rhino is MUCH more in the language. You type normal code. Your refactoring tools work. Your IDE helps you, etc.
The purpose of using a mock framework is basically so you can just work on testing the CUT (class under test). The CUT should usually be the ONLY concrete class in the test. This all works when you are practicing IoC. When you are using IoC – you pass in dependencies from the outside. When you do this – and you are seperating your interfaces from implementation – you can pass mock interfaces to your CUT. Once you do that – the mock can act as a spy.

1. The mock lets you wriggle into code branches so that you can test pieces of the code that are otherwise difficult to get to.
2. The mocks make your tests simpler. You do not have to instantiate lots and lots of classes correctly – you just set up interfaces and expectations and you are good.
3. The mocks make your tests more stable. You do not have to worry about changing test data etc.
4. The mock can act as a spy and tell you if it is being treated as you expect while it is ‘on the inside’

This used in conjunction with a code coverage tool (like Clover or NCover) helps you to really work your tests to cover your codebase fully.

Carry this over to the Java world – Rhino is much more like EasyMock which I am now writing some tests with. I had formerly used JMock (sort of like NMock in usage) – but I just replaced my jar reference and updated several tests. The tests are immediately more understandable, cleaner and therefore – better.

More another day – Maybe I will get around to posting comparison examples.
Chris

Object oriented software development is something that takes people time to get. Often I find myself pointing people to this this article to sum up why I am doing or something, why something feels right or wrong to me.

This is not a new article – I just find myself pointing people to this better explaination than I could give on more and more occasions.

Summary of principals:

The Open Closed Principle (OCP) ?
A module should be open for extension but closed for modification.

The Liskov Substitution Principle (LSP) ?
Subclasses should be substitutable for their base classes.

The Dependency Inversion Principle (DIP) ?
Depend upon Abstractions. Do not depend upon concretions.

The Interface Segregation Principle (ISP) ?
Many client specific interfaces are better than one general purpose interface

The Release Reuse Equivalency Principle (REP) ?
The granule of reuse is the granule of release.

The Common Closure Principle (CCP) ?
Classes that change together, belong together.

The Common Reuse Principle (CRP) ?
Classes that aren’t reused together should not be grouped together.

The Acyclic Dependencies Principle (ADP) ?
The dependencies betwen packages must not form cycles.

The Stable Dependencies Principle (SDP) ?
Depend in the direction of stability.

The Stable Abstractions Principle (SAP) ?
Stable packages should be abstract packages.

So…. I spend most of my day typing C# code for the past several years. This is of course not to mention running dev teams to ‘get the job done’, being a husband, dad, etc. I also spend time writing Java code, Ruby code, when I need to – C++, etc, etc – i will spare the list. That all said – there is so much debate lately regarding dynamic vs static typing…. I think that there are some missed points in these debates as I have been experiencing while writing my C# to Java converter (lets call it Hydrogue).

Many of the ‘debates’ regarding static vs dyamic typing seem to have left out much of what my experience tells me are key differentiators. Most of the dynamic language fans say:

“Type errors are such a small part of the error spectrum – why be burdned by type constraints???. Focus on unit tests.” Sounds good – take away the ‘constraints’ of strong typing.

But:

1. Dynamic languages force you to know the implementation – or the type expected – how about that! This is the biggie in my mind. BREAKS ENCAPSULATION/ INFORMATION HIDING.
2. When data modeling – I WANT to know the types/ subtypes etc of aggregate objects (see 1st bullet too – I must go look around to see the ‘interface’ of an object/ sub-object)
3. Tools have a hard time helping
1. Refactoring support
2. Intellisense like support
4. “Duck typing is fine” – but it does NOT help me when I need to expect certain ‘interfaces’ will be passed into a routine. (related to bullets 1,2)

The worst of all of these has been point 1. Without knowing types of objects – I am constantly having to run around and look at routines innards to see what methods they will be calling on my objects I pass to them. If I pass an interface reference – this is effectively saying – you can call only these things on me – and I expect it. With out this notion – I need to go look inside and see what the client class will call…. thus breaking down encapsulation.

It is hopeful/ possible/ likely that a dynamic language IDE will support statement completion (Ruby Eclipse does MINIMALLY). When this happens – it will be beyond helpful. I find that even though it is ‘more code’ I can turn out more code in an automated fashion using IDEs that support refactoring, intellisense, AND INTELLIGENT find usages/ implementors, etc.

That all said – I LIKE Ruby. Writing Hydrogue has been fun, educational and useful. Just pouring over the C# language spec @ msdn has been worth the work as my understanding of the bowels of C# from the inside out have gotten all the more clear. The extra Ruby education has been great – and getting everyday back into Java has been great as well. I will just say that – either IDEs have to get smarter, or I do to be as productive with a dynamically typed language as I am with a strongly typed language.

My thought was, and continues to be – the right language for the right job. I am not convinced (as many others seem to be) that dynamic languages are ready to do the things that C#/ Java do (much less C++). Perhaps I will be more convinced to use Ruby for ‘bigger’ or ‘more complex’ applications eventually. I will keep working with Ruby and hopefully by the time the tools catch up – I can contribute to the community of developers that start with them…

Enough;

Chris