The browser hang with 0 CPU load.

[Moonchild]

If this is right... does that mean this was using 12 parse threads before my old quad core started having an application freeze with a fresh profile, and backing off to 11 was what made it rock solid stable for me?

If it is a 4 core 8 HT CPU, then yes, you were trying to parse 12 things in parallel on a CPU that would have a capacity of ~5-6 cores worth of power, so effectively you hit the deadlock hitting a load of twice the capacity of what your CPU could handle at 100%. Considering the complexity of parsing JS, that isn't really a surprise.

[__Sandra__]

Well, actually I turned up something interesting here.

HT was made to transparently increase the number of processor cores in the system for programs. It seems logical to tell the program about all the cores in the system, without specifying their nature.

[__Sandra__]

Reverted the changes and ended up doing it this way, which should work fine on all hardware:

Code: Select all

static size_t
ThreadCountForCPUCount(size_t cpuCount)
{
    // Create additional threads on top of the number of cores available, to
    // provide some excess capacity in case threads pause each other.
    // Note that cpuCount here is the number of logical processors and threadCount
    // calculated here just adds some extra capacity on top. Use threadCount
    // with care as it may end up deadlocking.
    static const uint32_t EXCESS_THREADS = 4;
    return cpuCount + EXCESS_THREADS;
}

Variable "threadCount" is used in other places to determine load distribution. There will be the same logic of “overloading” small processors and “underloading” large ones. It might be worth changing the calculation for allocating “additional load (extra capacity)”?

[Moonchild]

Variable "threadCount" is used in other places to determine load distribution. There will be the same logic of “overloading” small processors and “underloading” large ones. It might be worth changing the calculation for allocating “additional load (extra capacity)”?

For simpler tasks like decompression and the like, that isn't a problem, but parsing/interpreting/compiling is a whole different beast and you can't just arbitrarily "load it up".

You may have missed the point Athenian was trying to make in that cpuCount is already dynamically scaling to the logical processors, and threadCount just adds some extra; you don't necessarily want to scale that up as it doesn't scale linearly in hardware and you'd be disproportionately loading the CPU scheduler if you add more over-capacity on higher core count CPUs, so just having a set amount makes sense there. We were just put on the wrong foot what "cpu" and "thread" actually means in the code.

[__Sandra__]

How can you tell if multi-threaded rendering actually works? According to my observations, when running most performance tests and rendering regular pages, the processor load (I have 2 cores + HT - 4 logical processors) rarely exceeds 25-30%, as if only one computation thread is actively working.