SBPF Syscall Extensions

[Lichtso]

A topic which came up during Breakpoint Singapore 2024 in a core dev meeting at the Jump office was the idea of putting additional instructions in the encoding space of the syscall opcode, an ISA extension so to speak. (Not to be confused with opcode prefix / suffix extensions)

This idea recently regained interest (referred to as "JIT Intrinsics") evident in an article by Blueshift:
https://blueshift.gg/research/accelerating-u128-math-with-libcalls-and-jit-intrinsics

I personally would not call it "JIT Intrinsics", because while they are intrinsics from the Rust front-end perspective down to LLVM they are not from the ISA / protocol perspective. Once lowered to SBPF in ELF they are indistinguishable from any other syscall.

Furthermore, the JIT is not the only execution mechanism, these syscalls need to be handled by the interpreter likewise. The fact that the codegen can be optimized for these is an implementation detail. Implementation wise I would not even implement them in the JIT directly but have them be syscalls which additionally register a codegen callback.

This discussion should revolve around which specific new syscalls we would want to introduce this way. Some ideas to kick off the discussion are:

• The PQR opcode class of SBPFv2 by SIMD-0174 which were removed in SBPFv3 again by SIMD-0377.
• https://gcc.gnu.org/onlinedocs/gccint/Integer-library-routines.html

[nagisa]

Did SIMD-0377 actually disable the PQR opcode class? The SIMD text only says "It reverts past ISA changes" in the summary, but does not come back to this point anywhere in the detailed design section neither directly, nor by referencing the SIMDs to be reverted, nor by referencing the relevant instruction classes AFAICT.

[Lichtso]

It does so by specifying that we implement the upstream eBPF ISA, which does not have these instruction classes and instead uses the encoding space for ALU32 (which we in turn did not have before).

[alnoki]

@Lichtso from discussion with @deanmlittle I'd like to see AVX libraries for things like single-CU pubkey compares

AVX2 is already required for validators: https://www.solanahcl.org/category/agave

AVX512f is also recommended, and would likely enable pubkey tuple compares at < 10% the cost compared with using chained sol_memcmp

[LucasSte]

This (along with pubkey copy) is such a common operation that I think it's reasonable to drive costs down using vector operations if possible or tweaking the CU schedule as you mentioned above

Yes, I agree with that. @Lichtso already summarized the issues with vector operations. In my view, BPF is very restrictive on that, and vector operations would only come if we switch to a more mature ISA that supports them, like wasm or RISC-V.

As in increasing CUs for stxdw and ldxdw?

Yes, exactly that. Every load and store (stxdw, stxw, stxh, stxb, stw, sth, stb, ldxdw, ldxw, ldxh, and ldxb) entails an address translation in the virtual machine. When that happens, we trap execution and call a separate function only to translate addresses, so each memory instruction is much more expensive than 1 CU for the validator.

At the same time, we need to trap for syscalls and perform address translations. Memops require three translations. Consequently, calling memcmp or memcpy for pubkeys is far more efficient for the validator (three translations each) than 8 loads (8 translations).

By reducing the base cost of memops to, for instance, 5 CUs, while increasing the price of load and store instructions, to, for example, 2 CUs, we fix the imbalance, while making pubkey copies and comparisons cheaper. As for the compiler side, this is simple tweak to emit the syscall instead of the load/store chain.

[alnoki]

@LucasSte I understand the rationale for effectively tying the CU schedule to wall-clock time, yet at the same time I recognize that the changes you suggest, in particular increasing any opcodes beyond 1 CU, would completely break any outstanding CU optimizations and likely have drastic changes on the cost to run existing programs

Would these CU schedule changes apply to all programs on mainnet after a feature gate activation, for example?

[LucasSte]

Would these CU schedule changes apply to all programs on mainnet after a feature gate activation, for example?

I understand the annoyance the feature gate may cause. I believe it would rational to propose the CU change for programs deployed after a certain epoch. After a year period, we could then increase the CUs for programs deployed before that epoch as well.

Does this sound reasonable?

[alnoki]

Would these CU schedule changes apply to all programs on mainnet after a feature gate activation, for example?

I understand the annoyance the feature gate may cause. I believe it would rational to propose the CU change for programs deployed after a certain epoch. After a year period, we could then increase the CUs for programs deployed before that epoch as well.

Does this sound reasonable?

@LucasSte Projected dates for (a) snapshot, (b) go-live, (c) forced deprecation?

[LucasSte]

Projected dates for (a) snapshot, (b) go-live, (c) forced deprecation?

I don't have such dates. Everything I suggested in this thread were ideas for discussion and analysis. If you are interested in going further with my suggestions, we should spawn a new discussion thread, where we will come up with the exact CU numbers, draft dates, and decide the activation method.

How does this sound to you?

[deanmlittle]

Sorry, we won’t be rebranding Blueshift’s original work on JIT intrinsics to satisfy your confusion about the interpreter targeting the JIT. Speculating on which intrinsics we should add without relevant performance metrics is not a productive approach. Either come to the table with concrete evidence of performance gains as we have, or put in the work to demonstrate them. This is not a guessing game.

[Lichtso]

Can you elaborate on what the confusion about "interpreter targeting the JIT" is?

Speculating on which intrinsics we should add without relevant performance metrics is not a productive approach.

Agreed and at no point did anybody suggest to add anything without the usual quality assurance: testing, fuzzing, benchmarking, reviews and security audits etc.

This is not a guessing game.

Well everything always starts out as one and can then evolve from there. Things to look into and measure still need to be come up with first. This SIMD discussion simply hosts a place to propose and present supporting evidence for these.