sc/source/core/data/formulacell.cxx | 5 -----
1 file changed, 5 deletions(-)
New commits:
commit a0e27322bebf5443ef895cb4c43d9288bcf13f9f
Author: Luboš Luňák <l.lu...@collabora.com>
AuthorDate: Thu Nov 25 12:05:39 2021 +0100
Commit: Luboš Luňák <l.lu...@collabora.com>
CommitDate: Thu Nov 25 17:34:17 2021 +0100
use even hyper-thread cores for Calc threading
I assume the threading was originally limited only to real cores
because that's how many FPUs there are in the CPU. But Calc
dynamically allocates many data structures (ScFormulaCell most
notably), which means they end up scattered all over the memory,
and processing them often stalls on memory reads, leaving time
for other HT core to run. For data-heavy documents (such as using
VLOOKUP) using HT cores saves 30%, but I can see 10+% gains
even for compute-heavy documents.
Change-Id: I302b17e55f27541606d922a1f0b27005ce0f0ba8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125801
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lu...@collabora.com>
diff --git a/sc/source/core/data/formulacell.cxx
b/sc/source/core/data/formulacell.cxx
index 7299ba705ab6..44f0f7acdf2b 100644
--- a/sc/source/core/data/formulacell.cxx
+++ b/sc/source/core/data/formulacell.cxx
@@ -4831,8 +4831,6 @@ bool
ScFormulaCell::InterpretFormulaGroupThreading(sc::FormulaLogger::GroupScope
bDependencyComputed = true;
- const static bool bHyperThreadingActive = cpuid::hasHyperThreading();
-
// Then do the threaded calculation
class Executor : public comphelper::ThreadTask
@@ -4886,9 +4884,6 @@ bool
ScFormulaCell::InterpretFormulaGroupThreading(sc::FormulaLogger::GroupScope
comphelper::ThreadPool&
rThreadPool(comphelper::ThreadPool::getSharedOptimalPool());
sal_Int32 nThreadCount = rThreadPool.getWorkerCount();
- if ( bHyperThreadingActive && nThreadCount >= 2 )
- nThreadCount /= 2;
-
SAL_INFO("sc.threaded", "Running " << nThreadCount << " threads");
o3tl::sorted_vector<ScFormulaCellGroup*> aFGSet;
