bruh, i've been telling y'all. it's literally just skill issues all the way down. always has been. 😭

It's obvious why Quasar is beating Anchor, but a lot of people are also asking "why is Quasar beating Pinocchio on some CU benchmarks?" I personally really dislike the framing of the question, as it appears to draw an incorrect conclusion. It is certainly not the case that @0x_febo neglected to optimize a bunch of things and we managed to beat him to it. Quite the opposite, in fact! Pinocchio, and now by extension, the newer versions of Solana SDK, are actually *so* optimal that the only way we have found to significantly reduce CUs any further is by introducing additional context in the form of a framework. Comparing a library to a framework is not an apples-to-apples comparison. There are many program-specific optimizations that are trivial to implement when you have enough context, but extremely difficult to generalize into a program-agnostic library. Allow me to explain one such case: In 2024, @cavemanloverboy introduced solana-nostd-entrypoint and solana-nostd-invoke. This was the first serious attempt to address some of the absolute worst Solana SDK code consumed by every single onchain program. Within this crate, Cavey introduced a technique called "nodup" entrypoint, where instead of burning CUs to manage duplicate accounts, you simply error out the moment you encounter one. This technique stacks well with some other optimizations that I'll get into later. Unfortunately, due to the nature of how the Solana entrypoint was originally designed to be both global for all instructions in a program, and require full parsing of many variable length inputs to achieve any situational awareness, all it takes is for one instruction in your program to have a potential duplicate account for the entire program to be unable to take advantage of this technique. Last year, I floated an idea to Febo, Cavey and @alessandrod: What if, in addition to register 1 pointing to the start of the serialized input region, we also instantiated the VM with a pointer to the first byte of our instruction data in register 2? This would enable us to create per-instruction entrypoints, allowing us to safely and performantly take advantage of techniques like nodup. @realbuffalojoe picked up the idea, wrote the SIMD and agave implementation, and pushed a whole bunch of insane PRs to our mainnet compatibility tooling to ensure this would be safe for all currently deployed programs and clusters. The feature is now active on testnet and devnet, and is due to be activated on mainnet within the next week or so. That's when Quasar officially achieves mainnet compatibility. As a result of all of us working together, a new optimization emerged: When operating under the assumption that you have immediate access to the instruction discriminator via r2, it is now possible to know: - exactly how many accounts your instruction expects, and - whether they will be a signer, mutable, executable or duplicate Due to how the account flags are encoded in a contiguous 4 byte sequence, rather than having to perform four individual checks (is_duplicate(), is_signer(), is_mutable(), is_executable()), we can actually stack these into a single u16 or u32 comparison. This means that not only is the r2 entrypoint able to safely and optimally utilize nodup; it also typically gives us our signer/mutable/executable checks for free! We're still on our day zero "unrelease", grinding away trying to stabilize the API and put out our first official version, but we'll be sure to put out some proper research detailing some of the techniques we've discovered along the way once we're done. One thing is for sure: Enabling an efficient Solana program framework was not just a @blueshift effort. We stand on the shoulders of giants. 🙏

the most based thing about the terafab presentation other than a literal electromagnetic catapult yeeting ai satellites off the moon was @elonmusk pluralizing "optimus" as "optimi".