run module on node error

[louisvangeldrop]

The sample from run_module_on_node results in the following error:

Import #144 module="libdyntype" function="dyntype_get_keys" error: function import requires a callable]

dyntype_get_keys is not defined in import_object.js. Maybe that causes the error.

[xujuntwt95329]

Hi, thanks for reporting the issue.

I've fixed it through #43

BTW, we are developing and validating features based on WAMR (iwasm_gc), and then gradually add support for node and browser, so the run_module_on_node lacks some features and is not well tested, please feel free to raise issue or directly contact us if you encounter any problems.

[louisvangeldrop]

Thx for the update.
In the meantime I already updated the import_object.js with empty dyntype_get_keys function in order to do some performance comparison between nodejs with the mandelbrot.js and nodejs with mandelbrot.wasm. Both use roughly the same cpu-time. I have set the iteration to 10000000.
4.922 sec vs 5.004

[xujuntwt95329]

Glad to know you can successfully execute the benchmark!

We don't expect a significant performance improvement when comparing to NodeJS (V8 JavaScript engine), because:

1. the JIT compiler in V8 is well optimized, and the benchmarks in our repo doesn't really change the type frequently, so the JIT compiler can generate highly optimized code.
2. currently we don't pay much attention to performance tuning, in mandelbrot benchmark we already know that there are bottleneck in array index processing because we use f64 (double) to represent number, every array element access will involve a f64(double) to i32(int) conversion, this involves lots of overhead

But on some other environment where JIT is not possible, e.g. embedded devices, the wasm based solution can introduce significant performance improvement. (I measured mandelbrot.wasm on iwasm_gc and mandelbrot.js on QuickJS and node --jitless, the result is: 2.424s/8.780s/9.180s), And we can further apply ahead of time compilation (AoT) for the wasm module to achieve even higher execution efficiency.

[louisvangeldrop]

That looks promising. Very often one need microsecond response times in order to run a driver. E.g. a DHT22 temperature/humidity sensor operates at 20-80 microseconds intervals.
See: https://www.waveshare.com/wiki/DHT22_Temperature-Humidity_Sensor
I hope that the app-framework of the bytealliance/wamr solution could offer that functionality by providing an event with the timing info between the pulses sent by a sensor.

[louisvangeldrop]

That looks promising. Very often one need microsecond response times in order to run a driver. E.g. a DHT22 temperature/humidity sensor operates at 20-80 microseconds intervals.
See: https://www.waveshare.com/wiki/DHT22_Temperature-Humidity_Sensor
I hope that the app-framework of the bytealliance/wamr solution could offer that functionality by providing an event with the timing info between the pulses sent by a sensor.