Bug: self parameter increases heap usage

[timohanke]

Uses "normal" heap amount (or no heap):

• Region.loadNat64(region, ..) from core 1.0.0
• Prim.regionLoadNat64(region, ..)

Uses higher heap amount:

• Region.loadNat64(region, ..) from core 2.0.0
• region.loadNat64(..) notation with core 2.0.0

The only difference between the two is that the first parameter of Region.loadNat64in core 2.0.0 is named self. Everything else is the same.

Note: This happens only for loadNat64, not for loadBlob.

To reproduce:
Check out this branch: https://github.com/research-ag/stable-trie/tree/optimize
Run mops bench main and you will see:

Garbage Collection

|    |        2 |        4 |       16 |      256 |
| :- | -------: | -------: | -------: | -------: |
| 0  |    440 B |    440 B |    440 B |    440 B |
| 1  |    484 B |    468 B |    468 B |    468 B |
| 2  |    512 B |    512 B |    496 B |    496 B |
| 3  |    600 B |    584 B |    568 B |    552 B |
| 4  |    744 B |    744 B |    728 B |    664 B |
| 5  | 1.04 KiB | 1.01 KiB |    968 B |    888 B |
| 6  | 1.65 KiB | 1.52 KiB | 1.48 KiB | 1.41 KiB |
| 7  | 2.91 KiB | 2.84 KiB | 2.51 KiB | 2.48 KiB |
| 8  | 5.41 KiB | 4.96 KiB | 4.68 KiB | 4.62 KiB |

Then go to here (UPDATED):
https://github.com/research-ag/stable-trie/blob/abb60a0eab1ef1c02c0f84b1fab802a8462d6248/src/base.mo#L248
and replace this line

Prim.regionLoadNat64(region, getNodeOffset(node, index)) & loadMask;

with

Region.loadNat64(region, getNodeOffset(node, index)) & loadMask;

Run mops bench main again and you will see:

Garbage Collection

|    |         2 |         4 |       16 |      256 |
| :- | --------: | --------: | -------: | -------: |
| 0  |     440 B |     440 B |    440 B |    440 B |
| 1  |     484 B |     468 B |    468 B |    468 B |
| 2  |     560 B |     512 B |    496 B |    496 B |
| 3  |     672 B |     632 B |    580 B |    552 B |
| 4  |   1.1 KiB |     924 B |    764 B |    700 B |
| 5  |  1.82 KiB |  1.44 KiB | 1.11 KiB |    912 B |
| 6  |  3.64 KiB |  2.58 KiB | 1.86 KiB | 1.51 KiB |
| 7  |  7.64 KiB |  5.27 KiB | 3.57 KiB | 2.88 KiB |
| 8  | 16.43 KiB | 10.66 KiB | 7.33 KiB | 5.85 KiB |

To try core 1.0.0 you have to go back a few commits and check out 2d1a6e35c6a01b919acb009e22adffad62b70b41. Then change to core "1.0.0" in mops.toml and run mops bench main again.

[crusso]

Ok, thanks for that. We'll investigate, but probably not immediately. I suspect there is some subtle difference in the inital lowering to IR that is causing this, but not sure.

looping in @christoph-dfinity

[crusso]

Hmm,
I tried to repro this (had to do mops self update) but getting exactly the same numbers with

      // region.loadNat64(offset) & loadMask;
      Prim.regionLoadNat64(region, offset) & loadMask;

and

      region.loadNat64(offset) & loadMask;
      //Prim.regionLoadNat64(region, offset) & loadMask;

I also (on a smaller test case) looked at the IR difference between

 region.loadNat64(offset)
 Region.loadNat64(region, offset)
 Region.loadNat64Fn(region, offset)  // declared without self

and the initial translations and wasm code are identical.

Maybe a user error?

[timohanke]

Which of the two tables I posted above do you get?

[crusso]

(This is the PR I first started to use to investigate with a hand crafted small example, before trying to follow your instructions to see if I could reproduce them in the first place).

[crusso]

Which of the two tables I posted above do you get?

The first one (with smaller numbers).

[crusso]

crusso@crusso-Virtual-Machine:~/stable-trie$ $(mops toolchain bin moc) --version
Motoko compiler 1.0.0 (source 0h933y9h-9nwsp7q2-cb6q1gb6-05hz02v7)
crusso@crusso-Virtual-Machine:~/stable-trie$ mops --version
CLI 1.12.0
API 1.3

[timohanke]

% $(mops toolchain bin moc) --version
Motoko compiler 1.0.0 (source i88kjbqg-hw27ggq9-lpp9pv13-hhr8nhki)
% mops --version
CLI 1.12.0
API 1.3

I just reproduced it after doing a fresh clone of the repo (to rule-out possible legacy artefacts in .mops). On MacOS M1. Am I running an older moc source than you? Or is the hash different because my OS is different?

[crusso]

I'm on linux so I suspect it's the hash.

Now, I can reproduce your larger numbers (second table) if I change the next function to not inline loadPointer in getChild:

    /// Load pointer from a region.
    public func loadPointer(region : Region.Region, offset : Nat64) : Nat64 {
      region.loadNat64(offset) & loadMask;
      // workaround for https://github.com/caffeinelabs/motoko/issues/5767
      //Prim.regionLoadNat64(region, offset) & loadMask;
    };

    /// Load node's `node` child number `index`.
    public func getChild(region : Region.Region, node : Nat64, index : Nat64) : Nat64 {
      loadPointer(region, getNodeOffset(node, index))
      /*Prim.regionLoadNat64(region, getNodeOffset(node, index))*/ & loadMask;
    };

Garbage Collection

	2	4	16	256
0	440 B	440 B	440 B	440 B
1	484 B	468 B	468 B	468 B
2	560 B	512 B	496 B	496 B
3	672 B	632 B	580 B	552 B
4	1.1 KiB	924 B	764 B	700 B
5	1.82 KiB	1.44 KiB	1.11 KiB	912 B
6	3.64 KiB	2.58 KiB	1.86 KiB	1.51 KiB
7	7.64 KiB	5.27 KiB	3.57 KiB	2.88 KiB
8	16.43 KiB	10.66 KiB	7.33 KiB	5.85 KiB

[timohanke]

Right. That's it.

[crusso]

Oh, now I'm very confused, because this:

    /// Load pointer from a region.
    public func loadPointer(region : Region.Region, offset : Nat64) : Nat64 {
      //region.loadNat64(offset) & loadMask;
      // workaround for https://github.com/caffeinelabs/motoko/issues/5767
      Prim.regionLoadNat64(region, offset) & loadMask;
    };

    /// Load node's `node` child number `index`.
    public func getChild(region : Region.Region, node : Nat64, index : Nat64) : Nat64 {
      loadPointer(region, getNodeOffset(node, index))
      /*Prim.regionLoadNat64(region, getNodeOffset(node, index))*/ & loadMask;
    };

Produces:

Garbage Collection

	2	4	16	256
0	440 B	440 B	440 B	440 B
1	484 B	468 B	468 B	468 B
2	512 B	512 B	496 B	496 B
3	600 B	584 B	568 B	552 B
4	744 B	744 B	728 B	664 B
5	1.04 KiB	1.01 KiB	968 B	888 B
6	1.65 KiB	1.52 KiB	1.48 KiB	1.41 KiB
7	2.91 KiB	2.84 KiB	2.51 KiB	2.48 KiB
8	5.41 KiB	4.96 KiB	4.68 KiB	4.62 KiB

[timohanke]

Why confused? That's exactly the effect I mean.

Prim.regionLoadNat64(region, offset) & loadMask; => low heap
region.loadNat64(offset) & loadMask; => high heap

Moreover:
Region.loadNat64(region, offset) & loadMask; => high heap

[crusso]

Ok, then I think the explanation is this. The call to Prim.regionLoadNat64(region, offset) is inlined by the compiler and will produce an unboxed Nat64 on the stack before doing the & while the other version, which still involves a function call, may need to box the Nat64 when it is larger, hence more allocation.

[crusso]

I don't think Region.loadNat64(region, ...) from core 1.0.0 was actually as cheap as Prim.regionLoadNat64(region, ...) (from core 1.0.0). Are you sure it was?

[timohanke]

core 2.0.0:

public func loadNat8(self : Region, offset : Nat64) : Nat8 = Prim.regionLoadNat8(self, offset);

That's a function wrapper.

core 1.0.0:

public let loadNat64 : (region : Region, offset : Nat64) -> Nat64 = Prim.regionLoadNat64;

That's not a function wrapper.

The word func vs let is the difference, isn't it?

And we don't use let in core 2.0.0 because that doesn't trigger the self detection, is that right?