Enso Dev Blog — Friday 3rd July
Welcome to the second edition of the Enso dev blog. This update is from the sprint ending 3rd of July 2020. If you want to keep up with the development of Enso in real time, you can follow along on GitHub.
Integrated Development Environment
The Enso IDE will include everything an end-user needs to process data with Enso. The IDE will support a user in writing both visual and textual Enso, with the tools and convenience expected from a modern IDE, such as auto-complete and context sensitive search.
Developer documentation
Documentation for developers working on the IDE has now been added to the devdocs site. Documenting the IDE is a sizeable task, and this is just the start, but already an improvement in contributor accessibility.
The documentation site is a static site, built with Jekyll, and served via GitHub Pages. Documentation for each project (currently Engine or IDE) is pulled in via submodule, with the submodule contents kept up to date via GitHub Actions. This structure allows us to quickly add documentation from any repository to the docs site.
Nodes
In the last developer blog, we showcased some of the new interactions around connecting and disconnecting nodes. This sprint, further improvements and bug fixes have been made to edges when disconnecting.
Eventually, a graph of nodes will be collapsable into a single node, and a collapsed node entered to see the contained graph. In progress towards this, nodes that are method calls can now be entered. When entered, the graph of the invoked method will be seen. The visualizations are stack-aware: when inside a method, any visualizations properly use the method call arguments.
Project management
In the last developer blog, we covered that support for projects had been added to the IDE. Now, existing projects can be renamed from within the GUI.
Engine
The Enso Engine includes the compiler, runtime and language server, and will, in the future, include the type checker. It is used as the backend of the Enso IDE, but can also be used in isolation.
Java upgrade
Previously, the project was built upon GraalVM for Java 8. This has now been upgraded to GraalVM for Java 11. Aside from a lengthened support window, this upgrade gives us access to several new features, and early benchmarking suggests comparable if not slightly improved performance. Be sure to follow our updated contributing guide for guidance on building Enso and the needed dependencies.
Adventures in benchmarking and Graal inlining
During the upgrade to Java 11, we attempted to benchmark to ensure there was no loss in performance. Initially, results were disappointing, with JMH benchmarks showing a 2x decrease in performance. In exploring the decrease, the benchmarks were rewritten in pure Enso. Below is an example of the tested code:
The pure Enso benchmarks were a huge 20x slower than the Java benchmarks. Following some fiddling with the compiler, this was seemingly resolved by enabling Splitting, which you can read more about here.
However, the resulting benchmarks were only in the expected range (40ms) for the initial runs. Further interations result in 0ms. What’s happening here?
Graal is detecting that we’re running a pure function, and discarding the result. Below is the compiler graph before the detection:
The red lines represent control flow. Notice the loop between 11691 and 18516. This is the inlined body of sum_tcofrom the above test.
This is the graph after detection:
The whole loop is gone: Graal has detected that the same, pure function is being called, and has skipped it. A great feature for performance, not ideal for benchmarking. This was resolved by adding a function to prevent inlining of the argument function. Benchmarking after this addition shows results in line with what we expected, clearing the way for an upgrade to Java 11.
Parser
Performance issues with the existing parser are affecting work in both the Engine, and IDE. To tackle these issues, a new parser is being written in Rust. This sprint saw the groundwork laid for this project, and we hope to share more news in future developer blogs. For now, you can follow along with the progress on our GitHub. You can read more about the design of the parser, and the decision to migrate to Rust, in the developer docs.
More information
That’s all for this developer update. We’ll be back with more after the next sprint. You can continue to follow along with Enso development on GitHub, by joining our Discord server, or subscribing to updates on our developer mailing list.
