YetiSim Blog

A few years ago, I read about the Intel Itanium processor.  One of the ideas that stuck with me was branch prediction.  The concept in my head is likely different now than what the processor actually does, but the idea is what is important here.  When a branch is encountered if we guess an execution path, we can start processing as if we should proceed down that path.  If our guess is wrong, we take a minor hit in performance.  A correct guess could result in a substantial performance gain.

The YetiSim state machine has guarded transitions, that are a lot like branches.  If we are able to guess which branch we will proceed along, then we could begin processing as if that is the correct path.  This is an example of how YetiSim performance can improve by further refinement of the implementation, without affecting the user interface.  I like this capability within YetiSim, since I believe simulation users (like processor users) should not be overly affected by the new architecture.  Readers knowledgeable about the Itanium could certainly point out problems with my analogy right now, but let’s just stay focused on YetiSim.

Branch prediction within YetiSim has a natural mapping to the state machine execution.  Statistics would have to be gathered during execution to improve the predictions made.  Fortunately,  YetiSim will be bundled already with just the tools required.  This is not something that I would do however, I would have to ask someone with more statistics experience than me to build the models for the branch predictions.  This is something that I would like to experiment with, after YetiSim becomes more stable.  The goal is to construct a stable simulator right now, not to wander around with a never ending list of desired features.  Still, this is a glimpse of the possible future of YetiSim.

A more immediate use of the branch statistics, is to dynamically adjust the order of branch evaluation so that the list of guards to consider is sorted by most frequently taken transitions.  This will reap some benefits at minor cost, and is easily implemented.

I’m not entirely sure about the details of the branch prediction, I have some ideas that I will outline but will not discuss in detail right now.  One of the ideas I have been toying with, is to separate out data from YetiSim so that it could be stored in a database.  Alternatively, it could fall back to just ordinary memory allocated from the heap.  The main idea is that if users restricted themselves to using YetiSim data storage constructs, that data could be saved elsewhere.  The execution of state machines could be captured with a data snapshot, and a database which provides transaction support could be used.  Only the correct path is committed to the database, the other transactions are silently discarded.  I’m not a database expert, someone else would have to provide the details here… but this is a general idea which could be of use.  Unfortunately it has disadvantages too… classes must use YetiSim data storage constructs.

Anyways, here’s a glimpse of what I’m thinking about.