src: use thread defaults provided by v8::platform

[tomgco]

By passing const int thread_pool_size = 0 to CreateDefaultPlatform
we allow v8 to choose sensible defaults based on the currently online
processors.

Benchmarking on my local machine saw no performance regressions; however it is dual core and hyper-threaded and would of used the same thread count as previously - I assume that this will benefit machines with more online processors; however I am curious if this would affect machines with only one core.

[bnoordhuis]

I have no real opinion on whether this is better or worse but for background, the reason I chose 4 is that:

1. I guesstimated that the average machine has 8 cores, and
2. libuv's thread pool is also 4 threads big by default.

(4 + 4 technically actually overcommits because of the main thread but a little overcommit seems like a decent trade-off vs. under-utilization.)

One glorious day we'll be able to service libuv and V8 from a single thread pool but until then, we need to strike a balance that doesn't starve one or the other.

Aside, the way to benchmark this is to:

1. Have a lot of functions that get promoted to the optimized tier around the same time, and
2. Execute a decent number of (asynchronous) file-based operations, like writing numerous small chunks to a bunch of on-disk files.

Those combined will overload both thread pools to the point that they need to queue up work items and then it's a matter of measuring throughput and latency.

Aside aside, as a stop-gap measure we could tweak node to divide the cores between the two thread pools at start-up.

[jasnell]

How aggressive is V8 at consuming the available cores when the default is set to 0? I definitely think that we should look at benchmarking this more before making changes here.

[bnoordhuis]

How aggressive is V8 at consuming the available cores when the default is set to 0?

It varies. V8 allocates up to three threads for concurrent sweeping; any remaining threads are used for concurrent recompilation and on-stack replacement. It depends on the performance profile of the application whether those threads have work to do.

[jasnell]

Would it be possible / desirable to run benchmarks across machines with variable numbers of cores and use that to determine a more algorithmic way of determining the reasonable defaults?

[jasnell]

Here's one idea: rather than guessing at this, perhaps add a CLI flag to allow the default to be overridden? e.g. node --v8-default-thread-pool-size=0. The flag would likely not be used extensively so we could just add it to the man page but omit it from the node --help output. Having it would allow someone to go through and experiment with benchmarks using different values to figure out what is optimum.

[tomgco]

Here's one idea: rather than guessing at this, perhaps add a CLI flag to allow the default to be overridden? e.g. node --v8-default-thread-pool-size=0. The flag would likely not be used extensively so we could just add it to the man page but omit it from the node --help output. Having it would allow someone to go through and experiment with benchmarks using different values to figure out what is optimum.

Sounds like a good idea, however I don’t like having undocumented features. Another approach could be to have an --advanced-options flag, much like we currently have for --v8-options and include --v8-default-thread-pool-size=0 under that?

[jasnell]

That's certainly a possibility but not sure it's ideal until we have more than one flag that would fall under that kind of category. Adding it to the --help output would be fine.

[tomgco]

Here's one idea: rather than guessing at this, perhaps add a CLI flag to allow the default to be overridden? e.g. node --v8-default-thread-pool-size=0. The flag would likely not be used extensively so we could just add it to the man page but omit it from the node --help output. Having it would allow someone to go through and experiment with benchmarks using different values to figure out what is optimum.

Ok, I am working on this at the moment.

[fhinkel]

Is this PR still being worked on?

ping @tangxinfa

[bnoordhuis]

It's been subsumed by PR #4344. I'll close this one.