Performance of Devicescript

[louisvangeldrop]

How fast will the compiled code run in comparison to native C/C++ ?

[mmoskal]

Here is a paper we did on a previous project that was compiling TS to native ARM code.

https://www.microsoft.com/en-us/research/uploads/prod/2019/09/static-typescript-draft2.pdf

DeviceScript is using a VM interpreter which is slower (but portable - we currently run on RISC-V, ARM, Xtensa, x86, WASM, and probably much more).

For low level manipulations I would guess anything between 10x-100x.

Also note that high performance is not the primary goal here - the goal is good developer experience. We'll work on perf when it becomes a problem (possibly using methods from the article linked above).

[louisvangeldrop]

I have read the article you mentioned in the past and therefore I was wondering if the performance of Devicescript was like the STS- or the VM-figures. I assume that the performance will be close to the VM data.
WASM is designed as being close to native performance. It is right to assume that if Devicescript is compiled to the WASM instruction-set, that its performance will also be close to native?

[louisvangeldrop]

I fully agree with your goal of developer experience in respect to performance. Will the performance be good enough to develop e.g. an STS-based DHT22-driver with interrupt-intervals in the order of 20-80 microseconds?

[mmoskal]

You're right, DeviceScript will be closer to the VM numbers from the STS paper. We only compile the DeviceScript interpreter to WASM, not the bytecode, and this only happens on a desktop system anyways. WASM is indeed designed to run at near native speeds but only on a desktop system, not a microcontroller...

As for 20-80 microseconds, you would need to write the driver in C and expose it as a Jacdac service. The driver could either run on the same MCU as DeviceScript or it be on a separate MCU communicating via Jacdac protocol.

[louisvangeldrop]

I assume that I am a little bit misled by the positive performance figures of WAMR (ByteAlliance) as they looked very promising for an MCU-independent VM.
I just wonder how to write a Devicescript based driver service with direct access to a Gpio-pin?

[mmoskal]

In DeviceScript types do not influence the semantics of the program (except for tree-shaking). In other words, we essentially have a JavaScript runtime, it just uses TypeScript compiler as a front-end. This offers the most familiar experience to TypeScript developers (eg., you don't have to do anything special to compile generics).

Note that WASM is not a particularly good target to compile JavaScript to, eg., a + b would need to call a runtime function that decides what + does depending on runtime types of a and b. In DeviceScript bytecode this is implicit (so the generated code is compact).

OTOH Static TypeScript uses type information for semantics, or at least optimization, which is less compatible with JavaScript, harder to port but faster.

[louisvangeldrop]

You are right. Performance-wise there is no use to compile Javascript to WASM for MCU devices. If you want to run Javascript in WASM, then running a Javascript interpreter within Wasm will do. ATOH the WAMR-project is as far as I know considering a Ts2Wasm project.
With respect to Devicescript, I wrongly assumed that Devicescipt was the same as STS, which is better suited for writing drivers thanks to its better performance.
The Espruino interpreter has two functions -setWatch and digitalPulse that take care of handling microseconds actions. I hope Devicescript will have an equivalent of it in the future.

[louisvangeldrop]

If subscribeDigital would in addtion to the "value" also return the "drift" of the last statuschange, then it comes close the setWatch functionality.

[pelikhan]

@louisvangeldrop how do you define drift?

[louisvangeldrop]

It is the time difference between the pin changed state and the last time the pin changed state.