koffi 0.9.33 → 0.9.34

package/README.md

@@ -1,14 +1,14 @@
 # Table of contents
 
 - [Introduction](#introduction)
+- [Benchmarks](#benchmarks)
+  * [atoi results](#atoi-results)
+  * [Raylib results](#raylib-results)
 - [Installation](#installation)
   * [Windows](#windows)
   * [Other platforms](#other-platforms)
 - [Get started](#get-started)
 - [Tests](#tests)
-- [Benchmarks](#benchmarks)
-  * [atoi results](#atoi-results)
-  * [Raylib results](#raylib-results)
 
 # Introduction
 
@@ -27,12 +27,13 @@ The following platforms __are officially supported and tested__ at the moment:
 * FreeBSD ARM64 Little Endian
 * macOS x86_64
 
-The following platforms will __soon be officially supported__:
+The following platforms will __soon be officially supported__, when I can get my hand on a machine...:
 
 * macOS ARM64
 
 The following platforms __may be supported__ but are not tested:
 
+* Linux ARM32 (full software FP) Little Endian
 * NetBSD x86_64
 * NetBSD ARM64
 * OpenBSD x86_64
@@ -40,6 +41,65 @@ The following platforms __may be supported__ but are not tested:
 
 This is still in development, bugs are to expected. More tests will come in the near future.
 
+# Benchmarks
+
+In order to run it, go to `koffi/benchmark` and run `../../cnoke/cnoke.js` (or `node ..\..\cnoke\cnoke.js` on Windows) before doing anything else.
+
+Once this is done, you can execute each implementation, e.g. `build/atoi_cc` or `./atoi_koffi.js`. You can optionally define a custom number of iterations, e.g. `./atoi_koffi.js 10000000`.
+
+## atoi results
+
+This test is based around repeated calls to a simple standard C function atoi, and has three implementations:
+- the first one is the reference, it calls atoi through an N-API module, and is close to the theoretical limit of a perfect (no overhead) Node.js > C FFI implementation.
+- the second one calls atoi through Koffi
+- the third one uses the official Node.js FFI implementation, node-ffi-napi
+
+Because atoi is a small call, the FFI overhead is clearly visible.
+
+### Linux
+
+The results below were measured on my x86_64 Linux machine (AMD® Ryzen™ 7 5800H 16G):
+
+Benchmark     | Iterations | Total time  | Overhead
+------------- | ---------- | ----------- | ----------
+atoi_napi     | 20000000   | 1.10s       | (baseline)
+atoi_koffi    | 20000000   | 1.91s       | x1.73
+atoi_node_ffi | 20000000   | 640.49s     | x582
+
+### Windows
+
+The results below were measured on my x86_64 Windows machine (AMD® Ryzen™ 7 5800H 16G):
+
+Benchmark     | Iterations | Total time  | Overhead
+------------- | ---------- | ----------- | ----------
+atoi_napi     | 20000000   | 1.94s       | (baseline)
+atoi_koffi    | 20000000   | 3.15s       | x1.62
+atoi_node_ffi | 20000000   | 640.49s     | x242
+
+## Raylib results
+
+This benchmark uses the CPU-based image drawing functions in Raylib. The calls are much heavier than in the atoi benchmark, thus the FFI overhead is reduced. In this implemenetation, the baseline is a full C++ version of the code.
+
+### Linux
+
+The results below were measured on my x86_64 Linux machine (AMD® Ryzen™ 7 5800H 16G):
+
+Benchmark       | Iterations | Total time  | Overhead
+--------------- | ---------- | ----------- | ----------
+raylib_cc       | 100        | 4.14s       | (baseline)
+raylib_koffi    | 100        | 6.25s       | x1.51
+raylib_node_ffi | 100        | 27.13s      | x6.55
+
+### Windows
+
+The results below were measured on my x86_64 Windows machine (AMD® Ryzen™ 7 5800H 16G):
+
+Benchmark       | Iterations | Total time  | Overhead
+--------------- | ---------- | ----------- | ----------
+raylib_cc       | 100        | 8.39s       | (baseline)
+raylib_koffi    | 100        | 11.51s      | x1.37
+raylib_node_ffi | 100        | 31.47s      | x3.8
+
 # Installation
 
 ## Windows
@@ -251,94 +311,4 @@ Each machine is configured to run a VNC server available locally, which you can
 
 ```sh
 node test.js info debian_x64
-```
-
-# Benchmarks
-
-At this stage, two benchmarks are implemented:
-* The first one is based around repeated calls to atoi, and has four implementations: one in C++, one calling atoi through an NAPI module, one using Koffi, and one with node-ffi-napi. This is a simple function, thus the JS and FFI overhead is clearly visible.
-* The second one is based around Raylib, and will execute much more heavier functions repeatdly. Also in three versions: Koffi, node-ffi-napi and C code.
-
-In order to run it, go to `koffi/benchmark` and run `../../cnoke/cnoke.js` (or `node ..\..\cnoke\cnoke.js` on Windows) before doing anything else.
-
-Once this is done, you can execute each implementation, e.g. `build/atoi_cc` or `./atoi_koffi.js`. You can optionally define a custom number of iterations, e.g. `./atoi_koffi.js 10000000`.
-
-## atoi results
-
-Here are some results from 2022-04-24 on Linux on my machine (AMD® Ryzen™ 7 5800H 16G):
-
-```sh
-$ build/atoi_cc
-Iterations: 20000000
-Time: 0.24s
-
-$ ./atoi_napi.js
-Iterations: 20000000
-Time: 1.10s
-
-$ ./atoi_koffi.js
-Iterations: 20000000
-Time: 1.91s
-
-# Note: the Node-FFI version does a few setTimeout calls to force the GC to run (around 20
-# for the example below), without which Node will consume all memory because the GC never appears
-# to run, or not enough. It's not ideal but on the other hand it counts as another limitation
-# to Node-FFI performance.
-$ ./atoi_node_ffi.js
-Iterations: 20000000
-Time: 640.49s
-```
-
-And on Windows on the same machine (AMD® Ryzen™ 7 5800H 16G):
-
-```sh
-$ build\atoi_cc.exe
-Iterations: 20000000
-Time: 0.25s
-
-$ node atoi_napi.js
-Iterations: 20000000
-Time: 1.94s
-
-$ node atoi_koffi.js
-Iterations: 20000000
-Time: 3.15s
-
-$ node atoi_node_ffi.js
-Iterations: 20000000
-Time: 267.20s
-```
-
-## Raylib results
-
-Here are some results from 2022-04-24 on Linux on my machine (AMD® Ryzen™ 7 5800H 16G):
-
-```sh
-$ build/raylib_cc
-Iterations: 100
-Time: 4.14s
-
-$ ./raylib_koffi.js
-Iterations: 100
-Time: 6.25s
-
-$ ./raylib_node_ffi.js
-Iterations: 100
-Time: 27.13s
-```
-
-And on Windows on the same machine (AMD® Ryzen™ 7 5800H 16G):
-
-```sh
-$ build\raylib_cc.exe
-Iterations: 100
-Time: 8.39s
-
-$ node raylib_koffi.js
-Iterations: 100
-Time: 11.51s
-
-$ node raylib_node_ffi.js
-Iterations: 100
-Time: 32.47s
-```
+```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "koffi",
-  "version": "0.9.33",
+  "version": "0.9.34",
   "description": "Fast and simple FFI (foreign function interface) for Node.js",
   "keywords": [
     "foreign",

package/src/call_arm32.cc

@@ -39,6 +39,7 @@ extern "C" HfaRet ForwardCallXDDDD(const void *func, uint8_t *sp);
 
 static bool IsHFA(const TypeInfo *type)
 {
+#ifdef __ARM_PCS_VFP
     if (type->primitive != PrimitiveKind::Record)
         return false;
 
@@ -54,6 +55,9 @@ static bool IsHFA(const TypeInfo *type)
     }
 
     return true;
+#else
+    return false;
+#endif
 }
 
 bool AnalyseFunction(InstanceData *, FunctionInfo *func)
@@ -107,17 +111,23 @@ bool AnalyseFunction(InstanceData *, FunctionInfo *func)
             case PrimitiveKind::Float64: {
                 Size need = param.type->size / 4;
 
-                if (param.variadic) {
-                    if (need <= gpr_avail) {
-                        param.gpr_count = need;
-                        gpr_avail -= need;
+#ifdef __ARM_PCS_VFP
+                bool vfp = !param.variadic;
+#else
+                bool vfp = false;
+#endif
+
+                if (vfp) {
+                    if (need <= vec_avail) {
+                        param.vec_count = need;
+                        vec_avail -= need;
                     } else {
                         started_stack = true;
                     }
                 } else {
-                    if (need <= vec_avail) {
-                        param.vec_count = need;
-                        vec_avail -= need;
+                    if (need <= gpr_avail) {
+                        param.gpr_count = need;
+                        gpr_avail -= need;
                     } else {
                         started_stack = true;
                     }
@@ -136,7 +146,7 @@ bool AnalyseFunction(InstanceData *, FunctionInfo *func)
                         vec_avail = 0;
                         started_stack = true;
                     }
-                } else if (param.type->size) {
+                } else {
                     int gpr_count = (param.type->size + 3) / 4;
 
                     if (gpr_count <= gpr_avail) {

package/src/ffi.cc

@@ -284,7 +284,7 @@ static Napi::Value TranslateVariadicCall(const Napi::CallbackInfo &info)
         return env.Null();
     }
 
-    for (Size i = func.parameters.len; i < info.Length(); i += 2) {
+    for (Size i = func.parameters.len; i < (Size)info.Length(); i += 2) {
         ParameterInfo param = {};
 
         param.type = ResolveType(instance, info[i], &param.directions);
@@ -585,7 +585,6 @@ static Napi::Object InitBaseTypes(Napi::Env env)
     RegisterPrimitiveType(instance, "float", PrimitiveKind::Float32, 4, alignof(float));
     RegisterPrimitiveType(instance, "double", PrimitiveKind::Float64, 8, alignof(double));
     RegisterPrimitiveType(instance, "string", PrimitiveKind::String, RG_SIZE(void *), alignof(void *));
-    RegisterPrimitiveType(instance, "str", PrimitiveKind::String, RG_SIZE(void *), alignof(void *));
 
     Napi::Object types = Napi::Object::New(env);
     for (TypeInfo &type: instance->types) {

package/vendor/node-addon-api/CODE_OF_CONDUCT.md

@@ -1,4 +0,0 @@
-# Code of Conduct
-
-The Node.js Code of Conduct, which applies to this project, can be found at
-https://github.com/nodejs/admin/blob/HEAD/CODE_OF_CONDUCT.md.

package/vendor/node-addon-api/CONTRIBUTING.md

@@ -1,93 +0,0 @@
-
-# Developer's Certificate of Origin 1.1
-
-By making a contribution to this project, I certify that:
-
- (a) The contribution was created in whole or in part by me and I
-     have the right to submit it under the open source license
-     indicated in the file; or
-
- (b) The contribution is based upon previous work that, to the best
-     of my knowledge, is covered under an appropriate open source
-     license and I have the right under that license to submit that
-     work with modifications, whether created in whole or in part
-     by me, under the same open source license (unless I am
-     permitted to submit under a different license), as indicated
-     in the file; or
-
- (c) The contribution was provided directly to me by some other
-     person who certified (a), (b) or (c) and I have not modified
-     it.
-
- (d) I understand and agree that this project and the contribution
-     are public and that a record of the contribution (including all
-     personal information I submit with it, including my sign-off) is
-     maintained indefinitely and may be redistributed consistent with
-     this project or the open source license(s) involved.
-
-# **node-addon-api** Contribution Philosophy
-
-The **node-addon-api** team loves contributions. There are many ways in which you can
-contribute to **node-addon-api**:
-- Source code fixes
-- Additional tests
-- Documentation improvements
-- Joining the Node-API working group and participating in meetings
-
-## Source changes
-
-**node-addon-api** is meant to be a thin convenience wrapper around Node-API. With this
-in mind, contributions of any new APIs that wrap around a core Node-API API will
-be considered for merge. However, changes that wrap existing **node-addon-api**
-APIs are encouraged to instead be provided as an ecosystem module. The
-**node-addon-api** team is happy to link to a curated set of modules that build on
-top of **node-addon-api** if they have broad usefulness to the community and promote
-a recommended idiom or pattern.
-
-### Rationale
-
-The Node-API team considered a couple different approaches with regards to changes
-extending **node-addon-api**
-- Larger core module - Incorporate these helpers and patterns into **node-addon-api**
-- Extras package - Create a new package (strawman name '**node-addon-api**-extras')
-that contain utility classes and methods that help promote good patterns and
-idioms while writing native addons with **node-addon-api**.
-- Ecosystem - Encourage creation of a module ecosystem around **node-addon-api**
-where folks can build on top of it.
-
-#### Larger Core
-This is probably our simplest option in terms of immediate action needed. It
-would involve landing any open PRs against **node-addon-api**, and continuing to
-encourage folks to make PRs for utility helpers against the same repository.
-
-The downside of the approach is the following:
-- Less coherency for our API set
-- More maintenance burden on the Node-API WG core team.
-
-#### Extras Package
-This involves us spinning up a new package which contains the utility classes
-and methods. This has the benefit of having a separate module where helpers
-which make it easier to implement certain patterns and idioms for native addons
-easier.
-
-The downside of this approach is the following:
-- Potential for confusion - we'll need to provide clear documentation to help the
-community understand where a particular contribution should be directed to (what
-belongs in **node-addon-api** vs **node-addon-api-extras**)
-- Need to define the level of support/API guarantees
-- Unclear if the maintenance burden on the Node-API WG is reduced or not
-
-#### Ecosystem
-This doesn't require a ton of up-front work from the Node-API WG. Instead of
-accepting utility PRs into **node-addon-api** or creating and maintaining a new
-module, the WG will encourage the creation of an ecosystem of modules that
-build on top of **node-addon-api**, and provide some level of advertising for these
-modules (listing them out on the repository/wiki, using them in workshops/tutorials
-etc).
-
-The downside of this approach is the following:
-- Potential for lack of visibility - evangelism and education is hard, and module
-authors might not find right patterns and instead implement things themselves
-- There might be greater friction for the Node-API WG in evolving APIs since the
-ecosystem would have taken dependencies on the API shape of **node-addon-api**
-

package/vendor/node-addon-api/appveyor.yml

@@ -1,37 +0,0 @@
-environment:
-  # https://github.com/jasongin/nvs/blob/HEAD/doc/CI.md
-  NVS_VERSION: 1.4.2
-  matrix:
-    - NODEJS_VERSION: node/10
-    - NODEJS_VERSION: node/12
-    - NODEJS_VERSION: node/14
-    - NODEJS_VERSION: nightly
-
-os: Visual Studio 2017
-platform:
-  - x86
-  - x64
-
-install:
-  # nvs
-  - git clone --branch v%NVS_VERSION% --depth 1 https://github.com/jasongin/nvs %LOCALAPPDATA%\nvs
-  - set PATH=%LOCALAPPDATA%\nvs;%PATH%
-  - nvs --version
-  # node.js
-  - nvs add %NODEJS_VERSION%/%PLATFORM%
-  - nvs use %NODEJS_VERSION%/%PLATFORM%
-  - node --version
-  - node -p process.arch
-  - npm --version
-  # app
-  - npm install
-
-test_script:
-  - npm test
-
-build: off
-
-version: "{build}"
-
-cache:
-  - node_modules

package/vendor/node-addon-api/benchmark/README.md

@@ -1,47 +0,0 @@
-# Benchmarks
-
-## Running the benchmarks
-
-From the parent directory, run
-
-```bash
-npm run-script benchmark
-```
-
-The above script supports the following arguments:
-
-* `--benchmarks=...`: A semicolon-separated list of benchmark names. These names
-    will be mapped to file names in this directory by appending `.js`.
-
-## Adding benchmarks
-
-The steps below should be followed when adding new benchmarks.
-
-0. Decide on a name for the benchmark. This name will be used in several places.
-   This example will use the name `new_benchmark`.
-
-0. Create files `new_benchmark.cc` and `new_benchmark.js` in this directory.
-
-0. Copy an existing benchmark in `binding.gyp` and change the target name prefix
-    and the source file name to `new_benchmark`. This should result in two new
-    targets which look like this:
-
-    ```gyp
-      {
-        'target_name': 'new_benchmark',
-        'sources': [ 'new_benchmark.cc' ],
-        'includes': [ '../except.gypi' ],
-      },
-      {
-        'target_name': 'new_benchmark_noexcept',
-        'sources': [ 'new_benchmark.cc' ],
-        'includes': [ '../noexcept.gypi' ],
-      },
-    ```
-
-    There should always be a pair of targets: one bearing the name of the
-    benchmark and configured with C++ exceptions enabled, and one bearing the
-    same name followed by the suffix `_noexcept` and configured with C++
-    exceptions disabled. This will ensure that the benchmark can be written to
-    cover both the case where C++ exceptions are enabled and the case where they
-    are disabled.

package/vendor/node-addon-api/benchmark/binding.gyp

@@ -1,25 +0,0 @@
-{
-  'target_defaults': { 'includes': ['../common.gypi'] },
-  'targets': [
-    {
-      'target_name': 'function_args',
-      'sources': [ 'function_args.cc' ],
-      'includes': [ '../except.gypi' ],
-    },
-    {
-      'target_name': 'function_args_noexcept',
-      'sources': [ 'function_args.cc' ],
-      'includes': [ '../noexcept.gypi' ],
-    },
-    {
-      'target_name': 'property_descriptor',
-      'sources': [ 'property_descriptor.cc' ],
-      'includes': [ '../except.gypi' ],
-    },
-    {
-      'target_name': 'property_descriptor_noexcept',
-      'sources': [ 'property_descriptor.cc' ],
-      'includes': [ '../noexcept.gypi' ],
-    },
-  ]
-}