Home Demos Forum Research Guide
Viewing topic in forum 'announcements'
back to topic list

Dana v200
Dana v200 represents a major redesign of our fundamental interpreter model, resulting in a performance speedup of up to 4x for all Dana programs. We’ve also taken the opportunity to further refine and simplify Dana’s adaptation model, and to provide a range of other language enhancements. This is a big update - and one that we’re rather proud of! - so we’ll cover the main changes in some detail here.

The interpreter and multi-threading

Raw performance is something we’ve wanted to focus on for a while, and our winter break seemed like the perfect time to make some progress here. Dana is now hardware-accelerated far more deeply than in any previous version, representing a major redesign in how Dana’s interpreter works. We’re confident that this is a great design direction for the future, and we’ll see further performance gains over the next months as a result. Right now all programs are a minimum of 2x faster than in Dana v175, and in some cases programs are up to 4x faster.

On top of this, Dana is now multi-threaded at the OS level and so can use multiple processor cores. For programs with a multi-threaded design, this delivers further performance gains above the base 2-4x speedup mentioned above – a multi-threaded program could be up to 16x faster on a 4-core CPU.

The one sacrifice we’ve made here is on how threads are scheduled; in previous versions of Dana multi-threading was perfectly fair and was also compartmentalised so that one component with hundreds of threads wouldn’t slow down any other components with just one or two threads. We’ve had to move away from this design for now, leaving thread scheduling to the OS level, but we might revisit this again in the future…

Runtime adaptation

We’re always looking for ways to further improve our adaptation support – which after all is one of Dana’s primary missions – and we’ve made a few small adjustments here for v200.

The first is that we’ve removed “adaptation constructors”. These proved to be confusing in practice as it was unclear where they fit into the adaptation workflow, causing a lot of bugs. In v200, all adaptation behaviour is based around the AdaptEvents interface, with the AdaptEvents:active function call now solely used to trigger any constructor-style behaviour.

Second, we’ve adjusted the way that inter-component wiring is done. In previous versions of Dana we used an overloaded assignment operator, i.e. comA :> Interface = comB :< Interface. This has now become a syntactic oddity compared to the way in which the rest of the language has evolved and so we’ve changed this to use the new operator:

dana.rewire(comA :> Interface, comB :< Interface)


Third, components (i.e. IDC’s) are now reference counted and are automatically unloaded when they are no longer being used and no more references to them exist. We’ve made this change partly to simplify the use of loading / unloading and reduce unintended memory leaks, and partly because Dana’s new interpreter design internally creates references to various data types that are non-obvious, such that trying to explicitly unload a component would often fail due to it still being referenced by an internal interpreter subsystem, even if the component has no explicit references at the language level.

Mutex types

This change is one that we tried hard to avoid, but the more we thought about it the more sense it made to do it. In previous Dana versions, Mutex types were a special type that didn’t fit into the rest of the type system; they could be declared and could only really be used in mutex(){} expressions, with very unclear semantics around things like assignment and comparison.

In v200, any Data type can be used in a mutex(){} expression, and the Mutex type itself is just a pseudo-subtype of Data. This change means that you must now instantiate a Mutex using new Mutex() before you can actually use it, otherwise you’ll get a null pointer exception. The benefit of this change is that data types are typically what you want to lock, and so you don’t now need to declare a separate mutex for each data instance in order to lock it. It also simplifies Dana’s type system, and because you can’t lock a data instance that’s read-only to you, we get to manage concurrency control fully internally to components.

Standard library changes

The above changes come with a range of minor tweaks to our standard library APIs. The most notable is that the composition.Loader interface has been removed and replaced with the core Loader interface. This interface is implemented directly by the Dana VM, a necessity due to our new interpreter design. Aside from this we’ve done some house cleaning of “dana.” operations, removing getVPUType(), getHostType(), joinAllThreads(), load() and unload(), all of which are either now redundant or are provided by other standard library APIs.

That’s all for now – check out our documentation over the coming days for updates!

Happy coding :-)
by barry on 2017-03-03 10:46:22 (0 replies)

© Francis Research Ltd. 2018