Not convinced an async API is necessary for async data

[dead-claudia]

I know this seems bold, but here's why I say this:

• It's naturally CPU bound, so there's nothing to be gained by deferring it. It's exclusively taking up CPU time no matter what, so all rescheduling is going to do is move the CPU load around (doesn't actually speed anything up) and add extra CPU load for the sake of promise scheduling.
• It's relatively straightforward with SIMD to parse at multiple gigabytes per second (even Chrome's conventional one parses at about 1.5 GB/s per the below paper), and there's many implementations to be found across many architectures for this. This research paper also came within margin of error of a literal memcpy using AVX-512 specifically, achieving claimed speeds of around 40 GB/s. Just to put that into perspective:
  • 1 Gbps = 125 MB/s (high-end residential and standard server)
  • 5 Gbps = 625 MB/s (typical standard cloud bandwidth offerings)
  • 10 Gbps = 1.25 GB/s (typical high-end server bandwidth)
  • 25 Gbps = 3.125 GB/s (highest bandwidth most clouds offer)
  • 40 Gbps = 5 GB/s (normally only seen in network appliances)
  • 100 Gbps = 12.5 GB/s (normally only seen in network appliances)
  • Anything extra only saves energy - it doesn't normally impact performance.

[bakkot]

I agree it probably doesn't need to be async.

That said, I disagree with

It's naturally CPU bound, so there's nothing to be gained by deferring it

The advantage of making it async is that the engine can break up the work to allow other higher-priority to stuff to happen before it finishes, like running the UI.

[dead-claudia]

The advantage of making it async is that the engine can break up the work to allow other higher-priority to stuff to happen before it finishes, like running the UI.

That's a fair point.

[bakkot]

This proposal isn't going to include an async version. It's possible to chunk up work in userland, though kind of annoying.