987466 - Implement a GetCoreCount

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine: JIT, defect)

Description

[Shu-yu Guo [:shu]]

For PJS, since we are saturating all the cores, we want to avoid spinning up more threads than we have physical cores for to avoid extra overhead on hyper-threaded systems.

We should implement a GetCoreCount to return the number of physical cores, and perhaps rename GetCPUCount to GetHardwareThreadCount or something.

Comment 1

[Shu-yu Guo [:shu]]

Attachment: Implement GetCoreCount on top of hwloc

WIP: still needs a manual LDFLAGS=-lhwloc to compile.

I did some research on how to properly detect the # of cores (i.e., CPU
topology). It is pretty damn complicated, such that it's not worth it to
reimplement it ourself, and we might as well use hwloc, which is part of the
OpenMPI implementation.

Comment 2

[Lars T Hansen [:lth]]

IMO we should have two functions, numCores() and numHardwareThreads(), where the latter pretty much returns the value numThreads() returned previously.

The reason is that some workloads will benefit from hyperthreading and some won't.  I suspect (data below) that long-running workloads benefit most from hyperthreading while short-running workloads benefit most from fast worker startup; common sense suggests the same.  I think we'll want to play around with both kinds of thread count, and we'll want to consider how we can make dynamic decisions about the number of threads, or whether we can/should expose primitives provide advice to the PJS engine about a workload.

As (limited) evidence I offer the Mandelbrot benchmark (bug 983864), which benefits from threads==hyperthreads, and the short-work-item convolution benchmark (Bug 985887,  https://bugzilla.mozilla.org/show_bug.cgi?id=985887#c1), which benefits from threads==cores.

Comment 3

[Shu-yu Guo [:shu]]

(In reply to Lars T Hansen [:lth] from comment #2)
> IMO we should have two functions, numCores() and numHardwareThreads(), where
> the latter pretty much returns the value numThreads() returned previously.
> 
> The reason is that some workloads will benefit from hyperthreading and some
> won't.  I suspect (data below) that long-running workloads benefit most from
> hyperthreading while short-running workloads benefit most from fast worker
> startup; common sense suggests the same.  I think we'll want to play around
> with both kinds of thread count, and we'll want to consider how we can make
> dynamic decisions about the number of threads, or whether we can/should
> expose primitives provide advice to the PJS engine about a workload.
> 
> As (limited) evidence I offer the Mandelbrot benchmark (bug 983864), which
> benefits from threads==hyperthreads, and the short-work-item convolution
> benchmark (Bug 985887, 
> https://bugzilla.mozilla.org/show_bug.cgi?id=985887#c1), which benefits from
> threads==cores.

Agreed.

The terminology used in CPU topologies is pretty confusing (to me). I've left the existing GetCPUCount function untouched, and indeed in other code I've read "CPU count" seems to == "hardware thread count". So with this patch, yes, we do have both.

Comment 4

[Lars T Hansen [:lth]]

Apparently this functionality has come in via the jit, to guide compilation policy.  So we don't need this patch.