Supercomputers today don't have fast processors, they have many processors. Any modern high-performance system must address the problem of distributing its calculations over multiple cores within a machine and across multiple machines across a network. The transport of simple data types (numbers, character strings, Booleans etc) is trivial. But when objects are used to represent real life (and therefore often complex) concepts, explicit work is necessary to facilitate network transport.
The technical term for converting an object in memory to a form compatible with network transport is serialization. In fact, the problem of communicating an object across a network is equivalent to that of saving an object to non-volatile memory such as a hard disc. Such persistence forms a critical part of the robustness of any server and is even at the heart of the everyday act of a user saving his or her work to a file.
Many robust serialization frameworks are available in C++, such as Boost.Serialization. However, serialization is perhaps best regarded as a distraction, a necessary but costly evil, not something which provides direct value to solving the business problem in a given domain, such as the pricing of financial derivatives. In that domain, it is rare to find a quant who, in addition to expertise in financial mathematics, is well versed in object serialization.
This problem can be neatly finessed by saving, not the internal state of objects, but the information from which they were constructed in the first place. Here is an example of a suitable format:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
f> n>CreateSimpleRootSearchOptimizer a> p> n>OptimizerName v> r> s>MyOptimizer p> n>Tolerance p> n>MaxIterations p> n>CollectDiagnostics |
The above is the serialized form of a simple root-finding optimizer object, where we have saved the instructions necessary for building the object, as opposed to the internal state of the objects itself.
Of course, an object's internal state is only equivalent to its construction instructions if it is immutable, but immutable objects in fact vastly simplify the engineering of concurrent systems which support multiple users, threads and processes.
As a final technical note, bitwise immutability is not strictly necessary, which means that some bespoke serialization may be desirable, but this is strictly an optimization.
