feat: increased performance with Rust/Napi rs

[Moumouls]

!!! Idea canceled after some benchmarking here: #393
I found that the pure JS version is faster with same precision.

Hi @bennycode,

I currently use your package into a project where i perform many calculations.
Since this lib do heavy calculations, here i think that switching the fast implementation from native number to a Rust with Napi RS could increase performance significantly.

Here i would like to get your point of view about this idea applied to your lib.

As an open source contributor and curious about the new trend about making some NodeJS lib faster with Rust, i found that your lib could be a perfect project to learn Node to Rust stuff in a useful way for me.

Feel free to tell me what you think about this ?

I'll be happy to take a look and check architectural details to try/benchmark a first part of the lib.

[Moumouls]

Okay thanks @bennycode, i missed the discussion panel for this kind of proposal.

Here napi rs doc: https://napi.rs/

Based on some readings on google and this blog post: https://www.lohika.com/node-js-n-api-implementation-and-performance-comparison

And also NextJS experience saying Compilation using Rust is 17x faster than Babel and enabled by default using Next.js 12

Since this lib performs mainly mathematical calculations ,on NodeJs side using Rust could run may be 10-20x faster.

[bennycode]

@Moumouls, my friend @ffflorian and I made some experiments and improved the performance of Wire's desktop app using Rust in 2017. In order to gain performance, you have to make sure that the communication between React and JS is less complex than doing the calculation entirely in JS. Otherwise the communication overhead will ruin all performance you hope to gain.

I can imagine that it will be beneficial to use Rust behind the scenes for functions that take a lot of candles at once (like SMA.getResultFromBatch). You can give it a try, it would be great to have faster implementations that follow the same interface. I know that the tulind library achieved something similar by providing C++ bindings for the famous Tulip Indicators.

[Moumouls]

Thanks for your experience feedback @bennycode . Does your Wire's desktop experiment used the native NodeJS addon system (N-API) or Webassembly ?

Here i'll focus on the NodeJS addon, Napi RS has planned to support WASM in v3 so improvement will be also available on browser side.

I'll keep you updated 🙂

[bennycode]

Our experiment was based on https://neon-bindings.com/ - You can find the archived code here: https://github.com/wireapp/libsodium-neon

[Moumouls]

So @bennycode i'm back with my tiny experiment on EMA.

I implemented the EMA class in Rust then i exposed the Rust EMA to JS. Here the result

The test:

       fit('calculates the Exponential Moving Average over a period of 50', () => {
      const ema = new EMA(50);
      const fasterEMA = new FasterEMA(50);
      const rsEMA = new RSEMA(50);
      const randomArray = Array.from({length: 5000}).map(() => Math.random());
      const emas = [ema, fasterEMA, rsEMA];
      emas.forEach((e, i) => {
        console.time(i.toString());
        randomArray.forEach(v => {
          e.update(v);
        });
        console.timeEnd(i.toString());
        console.log(`Result ${i}: ${e.getResult().toFixed(64)}`);
      });
    });

The result:

0: 11.978s
Result 0: 0.5537229640408674745381545548306987394969647797333170932363391512
1: 6.348ms
Result 1: 0.5537229640408679598451158199168276041746139526367187500000000000
2: 1.845ms
Result 2: 0.5537229640408679598451158199168276041746139526367187500000000000

The precision seems to be the same at this point 0.553722964040867

Currently the EMA Rust use internally f64, on macOS using f128 do not work properly at build time (quadmath issue): https://docs.rs/f128/0.2.9/f128/index.html

EMA Rust is 3,5 times faster than FasterEMA at same precision

The performance gain on the simple EMA use case is significant, the lib on server side could achieve massive improved performance.

It seems that f64 is sufficient, i found a comment on a Rust discussion about f128:

f64 has just shy of 16 decimal digits of precision. That's precise enough to measure the radius of Earth in nanometers.

Here my Rust code

#![deny(clippy::all)]
use std::cell::Cell;

#[macro_use]
extern crate napi_derive;

pub struct InternalEMA {
  pub prices_counter: Cell<f64>,
  pub weight_factor: f64,
  pub result: Cell<f64>,
  pub interval: f64,
  pub initialized: Cell<bool>,
}

impl InternalEMA {
  pub fn new(interval: f64) -> Self {
    Self {
      prices_counter: Cell::new(0.0),
      weight_factor: (2.0 / (interval + 1.0)),
      result: Cell::new(0.0),
      initialized: Cell::new(false),
      interval,
    }
  }
  pub fn update(&self, price: f64) -> f64 {
    self.prices_counter.set(self.prices_counter.get() + 1.0);
    if !self.initialized.get() {
      self.result.set(price);
      self.initialized.set(true);
    }
    let result = price * self.weight_factor + self.result.get() * (1.0 - self.weight_factor);
    self.result.set(result);
    self.result.get()
  }
  pub fn get_result(&self) -> f64 {
    if self.prices_counter.get() < self.interval {
      return 0.0;
    }
    self.result.get()
  }
}

#[napi(js_name = "EMA")]
pub struct EMA {
  engine: InternalEMA,
}

#[napi]
impl EMA {
  #[napi(constructor)]
  pub fn new(interval: f64) -> Self {
    Self {
      engine: InternalEMA::new(interval),
    }
  }
  #[napi]
  pub fn update(&self, price: f64) -> f64 {
    self.engine.update(price)
  }
  #[napi]
  pub fn get_result(&self) -> f64 {
    self.engine.get_result()
  }
}

[Moumouls]

Here some DEMA result

Started
Big JS: 26.205s
Result 0: 59.1091834121009917415269232865350520584908800906306088938883263949
JS: 7.546ms
Result 1: 59.1091834121009753744147019460797309875488281250000000000000000000
NAPI-RS: 1.559ms
Result 2: 59.1091834121009753744147019460797309875488281250000000000000000000

NAPI-RS is 4,8 times faster than JS

At this point i think NAPI-RS implementation will be even more faster compared to JS in more complex calculations.

[Moumouls]

Here MACD Result

Started
Big: 28.710s
Result 0: 2.6080693624
JS (i implemented this one also): 12.529ms
Result 1: 2.6080693624
NAPI-RS: 6.063ms
Result 2: 2.6080693624

It looks interesting; the performance for MACD is now just 2 times faster than JS.

Okay i found the bottleneck, the NAPI translation for objects returns looks to take some times. I implemented a method fastUpdate on Rust that just return a bool, then performance are now blazing fast !

Started
0: 27.618s
Result 0: 2.6173261478
1: 13.828ms
Result 1: 2.6173261478
2: 1.609ms
Result 2: 2.6173261478

NAPI-RS is 9 times faster than JS if rust do not return object at each update

[bennycode]

Hi @Moumouls, thank you for putting all the effort in and keeping me updated. Much appreciated! 👍 I have seen that you closed your PR as the performance didn't seem to be much better than the existing number-based implementation.

What would be interesting to find is the "tipping point"... I think a Rust-binding will always be slower than casual JavaScript when updating the indicator for each and every price but I could imagine that running a calculation on a batch of prices / candles can be more performant with a Rust-binding when using a certain amount of candles.

There is a static SMA.getResultFromBatch function which accepts multiple prices at once. Can you test how fast a Rust-based SMA implementation is when passing 10_000 numbers to it from JavaScript?

Wishing you a great 2022! 🚀

Best,
Benny