Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Virtual machine performance: excessive re-allocation and garbage collection + no caching #145

Open
bitjson opened this issue Sep 22, 2024 · 0 comments

Comments

@bitjson
Copy link
Member

bitjson commented Sep 22, 2024

Just opening an issue to document some long-standing performance issues related to Libauth's very unusual, sometimes-obsessive (😆), combinator-function-based approach to implementing virtual machines like the Bitcoin Cash VM.

I've made huge, ~100x performance improvements this year (identified by the benchmarks from the VM Limits & BigInt CHIPs 🚀), but there are still other performance issues based on how often we copy and/or re-create stack items.

It's easy to see where these issues are across the benchmarks: almost everything higher than Transaction validation benchmarks: Within BCH_2023_05 standard limits, 1-of-3 bare multisig input, 1 output (ECDSA signature, bottom slot) (nonP2SH) is spending the majority of it's time on garbage collection. For example, the worst case – y54lkh (Transaction validation benchmarks: Within BCH_2025_05 P2SH/standard, single-input limits, maximize OP_ADD operand bytes (P2SH20)):

Screenshot 2024-09-21 at 9 08 37 PM

You can see something like 75% of the time is spent on Javascript-y silliness, and if we really wanted to, we could cut that bigIntToVmNumber cost down to nearly zero by compiling BCHN's bigInt stuff to WASM. And honestly, there are probably ways to make it faster just in JS, but I haven't tried much.

Even this truly terrible case (y54lkh) is only ~2x worse than the comparably terrible vzvufaTransaction validation benchmarks: Within BCH_2023_05 standard limits, packed 1-of-3 bare multisig inputs, 1 output (all ECDSA signatures, top slot) (nonP2SH). For that one, the root cause of terrible performance is a complete lack of simple caching behaviors: all portions of signing serialization hashing can be cached, and signature validation can be both deferred and results cached.

These have pretty straightforward optimizations, but I don't plan to work on them in the immediate future, just wanted to note that someone could, if anyone cared to make Libauth VMs even faster (they're plenty fast enough for per-keypress evaluation in Bitauth IDE, the most intense use right now). In so far as I needed to use the Libauth VM to verify the worst-case performance of various things in a naive, JS-based implementation (i.e. empirically verifying the Limits CHIP), Libauth has a great little VM, and I'm done now. 😂

Another probably better alternative, is to simply compile the BCHN virtual machine to WASM and expose it via Libauth – which I would love to do, both for testing purposes and as the basis for reasonably fast, in-browser, pruned nodes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant