Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement and benchmark ArrowOperationPlus node #10150

Merged
merged 43 commits into from
Jun 11, 2024

Conversation

JaroslavTulach
Copy link
Member

@JaroslavTulach JaroslavTulach commented Jun 3, 2024

Pull Request Description

Prototype of #10056 showing + operation implemented in the Arrow language.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

  • All code follows the
    Java,
  • Unit tests have been written where possible.
  • Benchmarks are looking good

@JaroslavTulach JaroslavTulach added CI: No changelog needed Do not require a changelog entry for this PR. -compiler labels Jun 3, 2024
@JaroslavTulach JaroslavTulach self-assigned this Jun 3, 2024
@JaroslavTulach JaroslavTulach marked this pull request as draft June 3, 2024 05:29
@JaroslavTulach JaroslavTulach linked an issue Jun 3, 2024 that may be closed by this pull request

@BeforeClass
public static void initEnsoContext() {
ctx =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use ContextUtils and declare dependency runtime-language-arrow/Test --> test-utils. Being able to use context and project utils from test-utils was the main motivation to move test-utils into separate project in #10112

@JaroslavTulach
Copy link
Member Author

With 68d9306 we are at

[info] Benchmark                              Mode  Cnt   Score    Error  Units
[info] Arrow_Arithmetic_1000000.Plus_Fitting  avgt    3  34.328 ± 52.472  ms/op

There is a bunch of computations related to RoundingUtil.

RoundingUtil

That surprising as as they should be constant... but one has to tell the compiler a static int field is final: 1dbbae1 - then this rounding util part of the IGV graph disappears - alas, it has little impact as the computation was done one in the root anyway.

@JaroslavTulach JaroslavTulach changed the title PoC: Implement and benchmark + operation in the _Arrow language_ Implement and benchmark + operation in the _Arrow language_ Jun 8, 2024
@JaroslavTulach JaroslavTulach marked this pull request as ready for review June 8, 2024 10:02
@JaroslavTulach JaroslavTulach requested a review from Akirathan June 8, 2024 10:03
@JaroslavTulach JaroslavTulach changed the title Implement and benchmark + operation in the _Arrow language_ Implement and benchmark ArrowOperationPlus node Jun 8, 2024
@JaroslavTulach JaroslavTulach added CI: Clean build required CI runners will be cleaned before and after this PR is built. CI: Keep up to date Automatically update this PR to the latest develop. labels Jun 9, 2024
@JaroslavTulach
Copy link
Member Author

The simplest one million of long numbers addition - e.g. the Plus_Fitting benchmarks:

Column_Arithmetic_1000000_Plus_Fitting

Arrow_Arithmetic_1000000_Plus_Fitting

seem to be fine. The Arrow.+ implementation is on par or slightly faster.

@JaroslavTulach
Copy link
Member Author

One million of long additions with two hundered thousand of overflowing seems fine as well:

Column_Arithmetic_1000000_Plus_Overflowing

Arrow__Arithmetic_1000000_Plus_Overflowing

@JaroslavTulach JaroslavTulach removed the CI: Keep up to date Automatically update this PR to the latest develop. label Jun 10, 2024
Comment on lines +97 to +99
Runtime.assert ((column_arithmetic_plus_fitting data . to_vector) == (arrow_arithmetic_plus_fitting data)) "Column and arrow correctness check one"
Runtime.assert ((column_arithmetic_plus_overflowing data . to_vector) == (arrow_arithmetic_plus_overflowing data)) "Column and arrow correctness check two"
Runtime.assert ((column_arithmetic_plus_nothing data . to_vector) == (arrow_arithmetic_plus_nothing data)) "Column and arrow correctness check three"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I really miss . should_equal & co. when writing benchmarks. How are we supposed to know it computes the right values?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we could use should_equal? It will just throw a panic if it fails.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since #8778 we probably could use should_equal. Still I am not sure how to do write such tests properly to avoid:

  • initialization overhead
  • slowing down the benchmarks

This current Runtime.assert relies on the fact that runEngineDistribution -run test/Benchmarks runs with enabled assertions and thus it will check the assert. While when running benchmarks on the CI as well as std-benchmarks/bench the assertions are disabled and thus this testing code isn't executed at all.

I think it works, but it is a bit fragile.

Copy link
Member

@radeusgd radeusgd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Enso benchmarks look good.

I don't really understand how the engine part works. I'm not sure if I have to, but maybe the interactive PR review you suggested in some discussion could work well in this kind of PR? As I imagine it would be useful to get a high-level explanation of the decisions here. Without it I'm guessing and I'm not really sure what is happening in this code.

Copy link
Member

@radeusgd radeusgd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving the Enso benchmark changes, assuming @hubertp will look over the engine part.

Copy link
Collaborator

@hubertp hubertp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Arrow optimizations look really good. Thanks for doing the investigation

Co-authored-by: Radosław Waśko <[email protected]>
@JaroslavTulach JaroslavTulach force-pushed the wip/jtulach/PocArrowPlus10056 branch from 37343e4 to 807fd6d Compare June 11, 2024 09:14
put.putNull(builder.buffer, cachedUnit);
return;
}
var number = valueNode.executeAdjust(cachedUnit, value);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unlike the previous version that was converting and calling putXyz at once place the executeAdjust just converts value to appropriate java.lang.Number and then we use the PutNode to place that value into the buffer.

Truffle gives us a way to separate concerns for operations without loosing the speed - the whole switch will be compiled away and at the end will look just like the old one, but in source it is more structured into individual nodes.

@JaroslavTulach JaroslavTulach added the CI: Ready to merge This PR is eligible for automatic merge label Jun 11, 2024
@mergify mergify bot merged commit aaaebca into develop Jun 11, 2024
37 checks passed
@mergify mergify bot deleted the wip/jtulach/PocArrowPlus10056 branch June 11, 2024 12:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-compiler CI: Clean build required CI runners will be cleaned before and after this PR is built. CI: No changelog needed Do not require a changelog entry for this PR. CI: Ready to merge This PR is eligible for automatic merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Benchmark Truffle "add" for arrow-language and Column.+
4 participants