Hacker News new | ask | show | jobs
by zamalek 1344 days ago
> Deno is a multi-threaded server that utilizes in this test almost 2x the CPU-time while Bun is running single-threaded utilizing only 1x the CPU-time.

So we should intentionally handicap Deno? This is complete nonsense. If Bun wants to come out ahead of Deno, then they should also consider scaling with the number of CPU cores.

Single core CPUs are few and far between those days. Real-world performance is what matters.

3 comments

And a real-world deployment of a single-threaded interpreter just runs multiple instances of it, so do and compare that. No need to "handicap" anything.
My gut would say that you're paying 2x the overhead for a JS runtime. Of course, such a benchmark (edit: N instances of Bun and N instances of Deno) would be much more realistic/relevant.
But then you need twice the initial app memory. This can be substantial for larger apps.

There are definitely benefits of using multiple cores at once on a single app.

Sure. not an excuse to not benchmark it that way - if it struggles due to memory it'll show up after all.
Copy on write fork mitigates some of that.
There was a recent post about a new Ruby server implementation. The author pointed out that for interpreted languages, forking quickly deviates and gains very little benefit from copy-on-write. However! Pre-warming the first instance and then forking afterwards brought the memory savings back down to compiled levels. No real point to my comment except that it was new knowledge to me, and that efficiency of forking really depends on the implementation of what/when you're forking.
It's not clear what OP is saying. I assumed multiple container instances, but even then, CoW isn't as efficient.
> Single core CPUs are few and far between those days.

I would not be surprised if it's more common to run on a single CPU machine today than 10 years ago due to cloud VM instances.

There is plans for multi core in the future already. They (bun) just aren’t there yet.