(Please note I spent many years working on JSC)

I was more surprised at the interpreter only perf - JSC has always prioritized that, and was maintaining that interpreter-execution-first model for years prior to V8 even adding an interpreter - this is because while long running JS perf is important, the overwhelming majority of webpages do not do that, even for sites with long running JS today there is a large amount of single or short run JS during the early page load and the cost of JIT compilation is significantly larger than just running the code in the interpreter.

The RegExp one is weird, I wonder what bun might be doing that causes that? Oh, do you recall the benchmark the was run on bun? IIRC the various RegExp tests in the V8 and sun spider benchmark suites are really susceptible to caching, so this could be JSC having slower codegen, or over prioritizing interpreter based regex evaluation, etc if such caching does not apply.

DeltaBlue requires a large amount of very specific optimization work that simply is not representative of real world JS, I don’t recall if JSC has ever been faster than V8 at DeltaBlue - I recall JSC beating or getting close to a bunch of the original V8 benchmarks relatively quickly, even the GC "heavy" ones while still using a single generation conservative mark/sweep collector. For the numeric heavy benchmarks the performance was possible as JSC has done a lot of work to just void gc allocation of numbers, but for other benchmarks there were architectural differences the reduced a lot of the costs that V8 had.

An extremely large part of V8’s original perf delta (vs both SM and JSC) was the decision to ignore the ecmascript spec when dealing with integer property names. At the time for non-Array objects integer properties were no different from any other property, so something like

var object = {};
object[0] = "a"
object[2] = "b"
object[1] = "c"
for (var c in object)
log(c)

Was required to produce "a", "c", "b". So for existing engines these indexed properties were hash table lookups, storing them required tracking insertion order, practically it required converting the integers into strings, etc. V8 simply treated them as being array like properties so was violating the spec but you can imagine the perf delta on that. At least on of the V8 benchmarks included tests used indexed properties on non-array objects, which meant without also violating the JS spec it was literally impossible for other engines to ever get close to that level of performance (this perf win could be trivially measured simply by replacing the array-like object with an array object). The spec has since been changed to make these the correct semantics simply because it was clear that no engine would ever revert to the original behaviour because it was not possible. In hindsight this was the first example of Chrome’s IE model.