IntersectMBO / plutus

The Plutus language implementation and tools
Apache License 2.0
1.57k stars 479 forks source link

Evaluating an AST node costs too much MEM? #6584

Open effectfully opened 1 month ago

effectfully commented 1 month ago

@nau reported some stats and they suggest that evaluating AST nodes consumes 96.66% of MEM, which is an absurdly huge amount compared to the 3.34% that builtins consume. Does it really have to be that way? And if it does, should we prioritize working on solutions making MEM consumption lower by evaluating fewer AST nodes or producing fewer evaluation frames? For example by adding fix (issue) or let (issue) to the AST.

nau commented 1 month ago

Attaching the statistics stats.csv

image
michele-nuzzi commented 1 month ago

@effectfully will the let node allow for multiple variables?

eg

(let a b c d
  body
)

instead of

(let a
  (let b
    (let c
      (let d
        body
      )
    )
  )
)

Otherwise case and constr are only 2 nodes of difference

(case
  (constr 0 a b c d)
  (lam a
    (lam b
      (lam c
        (lam d
          body
        )
      )
    )
  )
)
effectfully commented 1 month ago

will the let node allow for multiple variables?

I'm not sure if that'll buy us much (or even anything at all) in terms of size or performance. Or can you think of something?

Otherwise case and constr are only 2 nodes of difference

The issue with constr is that you need those arguments to get fed into lambdas one by one and it's just less efficient to evaluate applied lambdas than it is to evaluate let nodes, especially in the current Haskell VM. Plus lets are more readable and I'd rather make UPLC readable if I can help it.

michele-nuzzi commented 1 month ago

the cost of nodes evaluation will be the same right?

the number of lambdas is the same of the number of let

michele-nuzzi commented 1 month ago

I'm not sure if that'll buy us much (or even anything at all) in terms of size or performance

Why this is not a problem for case and constr, which both have unbounded number of children?

effectfully commented 1 month ago

the cost of nodes evaluation will be the same right?

the number of lambdas is the same of the number of let

You're asking an interesting question, I'll bring it up to the team.

Why this is not a problem for case and constr, which both have unbounded number of children?

Those have to have them, it wouldn't make much sense to only allow constructors with a single argument. Single lets on the other hand are perfectly reasonable.