Cascade <| functions is slow

[JaroslavTulach]

Analysis of "if then else cascade slowdown" concluded that not only we want to continue to convert the conditional statement into if_then_else builtin (and run it as fast as #6255 does), but we also want regular, user written functions like <| or other control flow functions (with no local variables) to run as fast as the if_then_else builtin.

Checklist

• Write a benchmark comparing cascade of <| functions
• Improve the speed of any functions that has no local variables by implementing InlineableRootNode
• Verify unit tests continue to work
• Verify benchmarks are faster

Dependencies

• Speed cascade of if statements up #6255

Follow Up

• Speed functions like <| up without forcing it to be builtin #6394
• Improve inlining of <| on GraalVM CE #6416

[JaroslavTulach]

Benchmark shows that cascade of <| is indeed slow - 20x slower than the same code without <|.

[enso-bot]

Jaroslav Tulach reports a new STANDUP for yesterday (2023-04-21):

Progress: - benchmark: #6269 (comment)

• debugging <| builtin
• why we have the <| twice? discussion: https://discord.com/channels/@me/948519891961544714/1098973102756610190
• 360 review
• meeting Marcin It should be finished by 2023-04-25.

Next Day: Continue with <| functions

Discord

Discord - A New Way to Chat with Friends & Communities

Discord is the easiest way to communicate over voice, video, and text. Chat, hang out, and stay close with your friends and communities.

[JaroslavTulach]

The idea of inlining "regular functions" cannot be implemented right now:

• the first thing a function does is to convert arguments into VirtualFrame "slots"
• that means we need own VirtualFrame even for functions with just parameters
• or we need to modify the logic to read the local arguments directly from Object[] of arguments
• however that would complicate the logic[1] and
• it is not going to work for arguments with default values

Luckily it has been found that <| is implemented as ApplicationOperator builtin - e.g. we can speed it up using similar trick as in #6255 - alas the operator takes VirtualFrame as its argument - ironically that means we may need - # #6293

It has also been concluded that we want to move as much of these <<, >>, <| functions to Function and not have it in Any.enso.

[1] We would need to define our own:

interface CallFrame {
  Object[] getArguments();
  VirtualFrame getFrame();
}

and use it everywhere we use VirtualFrame. That's too much changes for current phase of the release.

[enso-bot]

Jaroslav Tulach reports a new STANDUP for yesterday (2023-04-24):

Progress: - PR for <| ready for review: #6384

• discussing InlinedCallNode with Truffle's Christian Humer
• New issue "vol. 2" reported: Speed functions like <| up without forcing it to be builtin #6394
• evaluation of When picking a Boolean value via the dropdown doesn't recalculate correctly. #6221 (comment)
• enso_project discussion: https://discord.com/channels/@me/948519891961544714/1099944720182030457
• standup, meetings, demo meetings It should be finished by 2023-04-25.

Next Day: Integrate <| function improvements

Discord

Discord - A New Way to Chat with Friends & Communities

Discord is the easiest way to communicate over voice, video, and text. Chat, hang out, and stay close with your friends and communities.