How to try Static Hermes

[philipheinser]

Are there binaries distributed to try out Static Hermes or should you build it by yourself from the branch?

[shihabmridha]

I cloned the repo, switched to static_h branch, and built the project using this document. It generates hermes and shermes in the build/bin/ directory. But, when I run the following code using the hermes index.js command I get the following error.

> hermes index.js
LLVM ERROR: Generating HBC bytecode disabled in Static Hermes

You can execute static-hermes bin though using the command below.

> shermes -typed -exec ./index.js
6 ms, 3.7330486176528693e+164

Code I tried to execute:

function bench (lc, fc) {
    var n, fact;
    var res = 0;
    while (--lc >= 0) {
        n = fc;
        fact = n;
        while (--n > 1)
            fact *= n;
        res += fact;
    }
    return res;
}

let t1 = Date.now();
var res = bench(4e6, 100);
print(Date.now() - t1, "ms,", res);

Unrelated (without the print function call):
time shermes -typed -exec index.js
0.12s user 0.09s system 22% cpu 0.938 total
time node index.js
0.42s user 0.03s system 85% cpu 0.532 total
time bun index.js
0.30s user 0.03s system 89% cpu 0.363 total

[tmikov]

time shermes -typed -exec index.js

Just want to point out that this is measuring the time to compile and link a native binary on disk.

[tmikov]

There are no binaries, and be warned: it is not ready to be tried out, since what works or doesn't is not documented, or it may even change or regress from commit to commit.

With that said, if you insist on trying it, you need to build it.

[gauravgautamapptile]

Hello, I am also very curious about static hermes. I tried to compile it and run it and was able to do some things. I noted down my steps here: https://medium.com/@gautam1168/compiling-typescript-to-native-code-0238d69ca582

I am not sure if sharing this is not appreciated since I am obviously not familiar with hermes and so might have done many things that could mislead someone. If that is the case you can delete my comment or I will if you tell me to.

[tmikov]

We absolutely welcome posts like this and thank you for sharing it.

I would add just a few clarifications:

1. The instructions in your blog post compile Static Hermes in debug mode, so it will be very slow.
2. The C output is a temporary feature to simplify our development (C code is easier to understand than LLVM IR). You can use -g to annotate it with #line directives, which actually enable you to partially debug the original JS in a native debugger.
3. TypeScript support is experimental and incomplete (but we are always improving it).

[thejustinwalsh]

I was able to get the benchmarks building using the following...

cmake -S hermes/benchmarks -B build_benchmarks -DHERMES_BUILD=/absolute/path/to/hermes/build -DHERMES_SRC=/absolute/path/to/hermes
cmake --build ./build_benchmarks 

The raytracer benchmark is a wonderful example of a full application using shermes, as it has bindings to ImGui, and uses sokol to get a window and rendering context setup.

I was going to take a stab at some Raylib bindings after I dig into ffigen a bit deeper.

[tmikov]

Really cool! BTW, we are still working on the performance of that benchmark, it will get faster.

[gauravgautamapptile]

Hello, I had not even expected that my post will be read by so many people including yourself. This email made my morning. I will update my post tonight to note how to compile in release mode. And I was going to try debugging using visual studio. I will attempt to get the typescript code to show up in my native debugger. Thankyou for that pointer. Yours sincerely, Gaurav Gautam

…

On Thu, 5 Oct 2023 at 23:15, Tzvetan Mikov ***@***.***> wrote: We absolutely welcome posts like this and thank you for sharing it. I would add just a few clarifications: 1. The instructions in your blog post compile Static Hermes in debug mode, so it will be very slow. 2. The C output is a temporary feature to simplify our development (C code is easier to understand than LLVM IR). You can use -g to annotate it with #line directives, which actually enable you to partially debug the original JS in a native debugger. 3. TypeScript support is experimental and incomplete (but we are always improving it). — Reply to this email directly, view it on GitHub <#1137 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBZ6O4CSECQVWXDZS4AHJJTX53W27AVCNFSM6AAAAAA5N3XTHCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TEMBRGUZTS> . You are receiving this because you commented.Message ID: ***@***.***>

[thejustinwalsh]

I spent an evening creating a turn-key example of using shermes with typescript here:
https://github.com/thejustinwalsh/sh-raylib

I tried my best to automate a bunch of concepts found in the other examples...

• CMake generates the raylib ffi files and concats the results with the includes as a part of the build process
• Using FetchContent for both hermes and raylib to make it easier to setup the workspace
• VSCode creature comforts

hello-world: https://github.com/thejustinwalsh/sh-raylib/blob/main/src/hello-world/hello-world.ts

bunny-mark: https://github.com/thejustinwalsh/sh-raylib/blob/main/src/bunny-mark/bunny-mark.ts

Not for the faint of heart, but lots of fun to hack on!
If you are familiar with C/C++ and CMake, you will feel right at home. I had to refactor my bunny-mark.ts code a few times to work around things that were not implemented or produced unexpected results.

I still don't understand a good strategy for managing the lifetimes of the heap allocations vs the JS objects that rely on them.

I hope this helps anyone else who is interested in hacking on it.
If there are ways that you would prefer I contribute back, LMK, at this point, I am not sure if making extra noise with bugs and failing tests is warranted.

[thejustinwalsh]

@tmikov 🥳

Runtime	FPS	CPU	GPU	Memory
C	90	68%	84%	48 MB
Static Hermes	90	70%	84%	53 MB

Your changes have made this demo run at native speed. This is next level, amazing! 🚀

For the audience:

• I assumed I could only use a class with babel-transform plugins like the ones used in @react-native/babel-preset, as the docs have it listed as planned on Hermes main. This is closer to the original implementation as well, so it is a better 1:1 comparison.
• I didn't know about _sh_ptr_write_c_uint and my first attempt at this code failed when I was attempting to do pointer math with the wrong helpers. This is the way.
• This is more concise and carries the intention better, love it.

TLDR; Static Hermes is fast!

[quadband]

What does the “inline” literal expression do in the makeColor function? What is interpreting it?

[tmikov]

It marks the function as inline, so it will be inlined at every call site, regardless of its size or other heuristics.

[quadband]

Thank you. Is this Hermes Static only? I spent the last half hour trying to find a reference to it and didn’t have any luck. I appreciate you answering.

[tmikov]

Yes, it is Static Hermes only, but does no harm in other engines. It will be documented eventually, when we are close to release.

[jerrygreen]

I really want some npm install -g shermes or something.

[tmikov]

I can probably figure out a way to not depend on the new Function thing anymore, which I now know I will have to do if I want the benefits of types in those parts that are run by those functions.

FWIW, new Function() will continue to work and be supported, just don't count on it being super fast, especially the first time it is executed. We will probably end up implementing type support to it as well, but not in the short to medium term.

That sounds like what JIT compilers do. At some future point I'd like to read about how hermes does this, and whether its similar to the speculation in webkit as described by the post https://webkit.org/blog/10308/speculation-in-javascriptcore/.

No, not at all. There is no speculation of any kind. Hermes is not a speculative JIT. If a value with type any is used, it is treated as a regular untyped JS value. The value can also be converted to a sound type by performing a checked cast, similar to Java. Simple example:

function foo(x: any) {
   console.log((x as number) + 10); // Will throw TypeError if x is not a number 
}

I am a bit out of my depth here, but I suppose iOS will not let developers ship a native compiler regardless of practicality.

Yes, that is one of the reasons. On iOS we have to stick to generating bytecode at runtime. However on Android devices, which are typically less powerful, we will eventually do simple JIT, but only for statically typed bytecode, to make up some of the difference.

[merlindru]

Just to give a data point, I (and many others, I imagine) want to run Static Hermes for server workloads (mainly web servers and data crunching stuff), not tied to RN at all

This is a crazy project and could change how we write server-side stuff. I'm really curious to whether Static Hermes will be used in this capacity, but I could totally see people flocking over to writing loads of stuff in it (and JavaScript) where other engines weren't fast enough before

Either way, thank you so much for building static hermes and taking on something this ambitious (and ridiculously hard to solve I imagine :D)

[HarunaMahjong]

@tmikov

Is there any plan to support Multiple Dispatch like Julia language?

If you do so, fast execution would be ensured even for any type.

[tmikov]

@tmikov

Is there any plan to support Multiple Dispatch like Julia language?

If you do so, fast execution would be ensured even for any type.

@HarunaMahjong, thank you for your question. It's important to understand a couple of key differences between Julia and JavaScript, particularly in the context of Hermes as an Ahead-Of-Time (AOT) compiler.

• AOT vs. JIT Compilation: Hermes is designed as an AOT compiler, which means it compiles JavaScript code into optimized bytecode or machine code before execution. This approach is fundamentally different from Just-In-Time (JIT) compilation used by Julia, which specializes and optimizes code at runtime based on the types of arguments. Implementing a JIT within Hermes would fundamentally change its design and undermine the benefits of AOT compilation, such as improved startup time and reduced runtime overhead.

• Static Type System Requirement: Multiple dispatch, as implemented in Julia, is conceptually simple, because it relies on a static type system that is fully defined at compile time. Julia uses its rich type system to determine the appropriate method to dispatch based on the types of all arguments. In regular JavaScript, on the other hand, types are not fixed or known until runtime. Worse, compatible types may have different layouts and change on the fly. This dynamic nature of untyped JavaScript makes it incompatible with the static type requirements needed for efficient multiple dispatch in Julia.

• Binary code size: Julia relies on the LLVM JIT, which is many times larger than the entirety of Hermes.

Even if we did add an advanced JIT to Hermes, the above points would still make implementing Julia-like multiple dispatch impractical. JavaScript’s dynamic typing does not provide the necessary compile-time type information that multiple dispatch relies on for optimization.

In summary, while multiple dispatch is a powerful feature in Julia that leverages its JIT compiler and static type system, it is not applicable to JavaScript, especially within the constraints of Hermes as an AOT compiler.

[HarunaMahjong]

AOT vs. JIT Compilation: Hermes is designed as an AOT compiler, which means it compiles JavaScript code into optimized bytecode or machine code before execution. This approach is fundamentally different from Just-In-Time (JIT) compilation used by Julia, which specializes and optimizes code at runtime based on the types of arguments. Implementing a JIT within Hermes would fundamentally change its design and undermine the benefits of AOT compilation, such as improved startup time and reduced runtime overhead.

@tmikov, thank you so much for your answer. By the way, do you mean that Hermes converts JavaScript code into bytecode and then just interprets it without any JIT compilation?

Sorry, but I can't understand why there is no runtime difference between bytecode from untyped JavaScript code and native code from untyped JavaScript code. Is there no time consumption at interpreting bytecode?