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

Encapsulating array-like data and operations into a single package #7544

Merged
merged 41 commits into from
Aug 15, 2023

Conversation

JaroslavTulach
Copy link
Member

@JaroslavTulach JaroslavTulach commented Aug 10, 2023

Pull Request Description

Fixes #6299 by:

  • moving all array-like data classes into a single package - Done in 2201637
  • removing all public methods of Vector & Array - Done
  • hiding the classes from direct public access (Done in 1dd97a8 & 4c3e383)
  • offering ArrayLikeLengthNode and ArrayLikeAtNode & co. to access them - Done
  • simplify all other code by using those nodes - like in f128f8b and 1dd97a8 - Done

Important Notes

Checklist

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

  • Make sure all Enso objects subclass EnsoObject and check for that
  • All code follows the style guides.
  • All code has been tested:
    • Unit tests have been written where possible.
    • Benchmarks show no regressions

@JaroslavTulach JaroslavTulach self-assigned this Aug 10, 2023
@JaroslavTulach JaroslavTulach marked this pull request as draft August 10, 2023 10:23
@JaroslavTulach JaroslavTulach added the CI: No changelog needed Do not require a changelog entry for this PR. label Aug 10, 2023
@JaroslavTulach
Copy link
Member Author

JaroslavTulach commented Aug 11, 2023

Current state seems to be stable. Let's do a bit of benchmarking. On par, except:

  • probably ArrayProxyBenchmarks_sumOverVectorBackedByDelegatingProxy
  • VectorBenchmarks_averageOverSlice
  • WarningBenchmarks_noWarningsVecSum and randomElementsVecSum
  • both VectorBenchmarks_averageOverArrayProxy*
  • maybe AtomBenchmarks_benchSumListMethods
  • certainly IfVsCaseBenchmarks

Let's delay querying length until really needed: 359a608 and let's try new benchmark - some improvements are visible, but there is still some work to do on:

  • ArrayProxyBenchmarks_sumOverVectorBackedByDelegatingProxy
  • WarningBenchmarks_noWarningsVecSum and randomElementsVecSum - improved, but used to be better
  • VectorBenchmarks_averageOverArrayProxy* - improved, but used to be better
  • IfVsCaseBenchmarks - improved, but used to be better
  • AtomBenchmarks_benchSumListMethods - still

Running new benchmarks check based on 4c3e383 - assuming it is no worse we'll need to find out how to speed the ones listed above up...

@JaroslavTulach
Copy link
Member Author

JaroslavTulach commented Aug 13, 2023

6181b10 introduces Vector.EnsoOnly that is likely to speed up the IfVsCase benchmarks. Which has happened... IfVsCase benchmarks are no longer slow. Benchmarks seem to be fine.

Copy link
Member

@Akirathan Akirathan left a comment

Choose a reason for hiding this comment

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

Good job. I have written some minor comments.

type Array_Proxy
## PRIVATE
Value ignore
Copy link
Member

Choose a reason for hiding this comment

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

What is the reason for this ignored field?

Copy link
Member Author

Choose a reason for hiding this comment

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

Removing the Value ignore constructor turns Array_Proxy into a singleton and fails:

[error] Test org.enso.interpreter.test.MetaIsATest.typesAreNotInstancesOfThemselves failed: java.lang.AssertionError: 
[error] Type Array_Proxy shall not be instance of itself expected:
[error]     at org.enso.interpreter.test.MetaIsATest.typesAreNotInstancesOfThemselves(MetaIsATest.java:238)

I decided to add a constructor to "silent" this tests.

The proper fix is to remove the type Array_Proxy altogether, I think. It is not a type anyway. It is just a place for the new and from_proxy_object methods. However I happily leave this for @jdunkerley, @radeusgd and for another pull request.

Comment on lines +3 to +7
import org.enso.interpreter.node.expression.builtin.meta.TypeOfNode;
import org.enso.interpreter.runtime.callable.atom.Atom;
import org.enso.interpreter.runtime.callable.atom.AtomConstructor;
import org.enso.interpreter.runtime.data.Type;
import org.enso.interpreter.runtime.type.TypesGen;
Copy link
Member

Choose a reason for hiding this comment

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

minor: Are these imports reordered with sbt enso/javafmt or is it your IDE doing this? I am asking because your setup seems to create inconsistent import ordering - in this file, org.enso imports are before com.oracle.truffle, whereare, in GetStackTraceNode.java it is the other way around.

I have seen a lot of import reordering in your recent PRs. I just want to make sure that we are on the same page and ensure whose setup is the prefered one.

Copy link
Member Author

Choose a reason for hiding this comment

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

VSCode (with Apache NetBeans based plugin) is configured to clean imports aggressively. For example it expands * imports to individual ones, removes unnecessary imports, etc. However the order is then finally set by javafmtAll.

I have seen a lot of import reordering in your recent PRs.

Yeah, I've noticed that myself as well.

on the same page and ensure whose setup is the preferred one.

javafmtAll is the final check, however it may be too "forgiving". I can change my settings to instruct the IDE to not touch imports automatically.

@JaroslavTulach
Copy link
Member Author

JaroslavTulach commented Aug 14, 2023

Another benchmark run to check the effect of ArrayBuilder builtin.

Copy link
Contributor

@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.

Mostly fine, apart from the warnings bit


@BuiltinMethod(
type = "Vector",
type = "Array_Like_Helpers",
name = "at",
description = "Returns an element of Vector at the specified index.")
Copy link
Contributor

Choose a reason for hiding this comment

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

probably needs an update as well

Copy link
Member Author

Choose a reason for hiding this comment

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

What kind of update would you suggest, @hubertp?

@Specialization(guards = "interop.hasArrayElements(values)")
Vector fromArrayWithArrayLikeObject(
Array vec,
private static EnsoObject insertBuiltin(
Copy link
Contributor

Choose a reason for hiding this comment

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

Could probably just move this method to fromObject?

Copy link
Member Author

Choose a reason for hiding this comment

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

Done in 80a74d9e49

@JaroslavTulach JaroslavTulach changed the title Moving all array-like data classes into the same package Encapsulating array-like data classes & operations into a single package Aug 15, 2023
@JaroslavTulach JaroslavTulach changed the title Encapsulating array-like data classes & operations into a single package Encapsulating array-like data and operations into a single package Aug 15, 2023
@JaroslavTulach JaroslavTulach merged commit 7a272ec into develop Aug 15, 2023
23 checks passed
@JaroslavTulach JaroslavTulach deleted the wip/jtulach/ArrayNodes_6299 branch August 15, 2023 11:00
@JaroslavTulach
Copy link
Member Author

benchmark_results.pdf show the state of the benchmarks at the time of merging. Mostly improvements or on par. Slight regression at:

  • about 30% in WarningBenchmarks_randomElementsVecSum
  • 13% in VectorBenchmarks_averageOverArrayProxy... and VectorBenchmarks_averageAbstractList and VectorBenchmarks_averageOverArray

I merged anyway to avoid further conflicts. We can address the slowdowns in follow up issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI: No changelog needed Do not require a changelog entry for this PR.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Unify & speed access to array-like objects behind ArrayXyzNode
4 participants