Predictability is one of the most exciting aspects of HVM, to me. That's because everything is linear, so time and space costs are completely measurable, in a way that resembles C, but even more profoundly. For example, in the following GitHub issue:

https://github.com/HigherOrderCO/HVM/issues/167

I discuss how HVM is able to perform deforesting, one of the core techniques that made GHC so fast, "for free" at runtime, without being explicitly hardcoded. That is great, but the point I'd like to make is how I show that: by measuring the 'rewrite count' of a program with HVM's '-c' flag. It shows you how many rewrites a program evaluation took. Since each rewrite is a constant time operation, this gives us a very precise metric of the complexity of a program.

On the issue above, I implemented two versions of the same function, and measured their rewrite counts. Here are the tables:

    Fn V1

    N | rewrites
    - | --------
    0 | 402
    1 | 802
    2 | 1202
    3 | 1602
    4 | 2002
    5 | 2402
    6 | 2802
    7 | 3202
    8 | 3602
    9 | 4002

    Fn V2

    N | rewrites
    - | --------
    0 | 1403
    1 | 1408
    2 | 1413
    3 | 1418
    4 | 1423
    5 | 1428
    6 | 1433
    7 | 1438
    8 | 1443
    9 | 1448

From these numbers, we can tell V2 scales better than V1, without doing any benchmark. Not only that, but we're able to write explicit formulas for the runtime cost of each version:

    TimeComplexity(FnV1(N)) = 402 + 400*N rewrites
    TimeComplexity(FnV2(N)) = 1403 + 5*N rewrites

Which means both are O(N), but V2 has a 80x smaller linear coefficient. This precision extends to memory and space too. This is why we're so excited to build Kindelia to apply HVM to the context of blockchain VMs, as this granular measurability isn't available on GHC, which is why Cardano can't use the Haskell compiler, and must resort to an interpreter, greatly affecting its throughput. Of course, this is just one of many the applications of the HVM.