Alexander Meißner

Why not go straight for the newest (vendor independent) `VK_KHR_ray_tracing` extension? https://www.khronos.org/news/press/khronos-group-releases-vulkan-ray-tracing

One of the dependencies of `VK_KHR_ray_tracing` is `VK_KHR_buffer_device_address`. Which requires the host to know the physical addresses (pointers) inside the device. However, it seems that Metal does not expose that...

Yes, the commit traded sorting stability for performance. The sorting order of the keys is still correct though (not just an approximation) and value order is irrelevant to the application...

The second is so that it is interface compatible with JIT compiled programs upon entry in a syscall. The syscall helper wrapper in program.rs does expect the CU metering to...

I have been thinking, that instead of adding a few new instructions and removing some others from BPF, it might be better to go with a [portable-code](https://en.wikipedia.org/wiki/Bytecode) approach directly. We...

For the current BPF to x86-64 conversion it is really hard to do any optimizations, because most rely on static analysis that would not be necessary if that information was...

> What does this mean in practical terms? > redefine the BPF instruction set completely? What I suggest is not to fork & modify BPF any further but use something...

> SPIR-V also requires a different programming model. It seems one cannot take an arbitrary rust program and compile it for execution on SPIR-V. Definitely, while there have been some...

> is it to reduce the code size of on-chain programs? Yes, I think the BPF 8-byte fixed instruction size is terribly wasteful. It might not be a concern for...

> Register allocation is expensive That depends on the quality you want. But for ahead-of-time, maximum performance I agree. Then again, in that case, we don't need to compile often...