Divide and conquer less threads

[Programmer-Magnus]

Describe the PR
Divide and conquer can use 'this' thread instead of creating a second thread and then wait for the two new ones to finish their tasks.

Test Cases
I only run the normal ojAlgo tests and only the testReading1BRC failed as it did for me before this patch.
I hope this will improve benchmarks slightly, but I do not know which to run.

[apete]

I did evaluate this before, and got better throughput by "waisting" threads like this. (Maybe I was mistaken or maybe things have changed, it was a long time now – could re-investigate this.)

Perhaps it's time to run some of the (subclasses of) AbstractThresholdTuner benchmarks again.

In the end, I suppose, it's the results of the benchmarks in https://github.com/optimatika/ojAlgo-linear-algebra-benchmark that matter.

[Programmer-Magnus]

I agree, accepting it should depend on the benchmark results produced. Result might depend on what java version the benchmark use. I will look at those tests you mention.

[cursor]

Bug: Inconsistent Exception Handling in DivideAndConquer

The commit introduces inconsistent exception handling in the DivideAndConquer class. The second part of the operation is now called directly, while the first part remains asynchronous via a Future. Previously, all exceptions were consistently wrapped in ExecutionException and re-thrown as RuntimeException. Now, unchecked exceptions from the directly called second part bypass the catch block (which only handles InterruptedException and ExecutionException), propagating unwrapped. This creates inconsistent error handling compared to the first part, which still wraps exceptions in RuntimeException.

src/main/java/org/ojalgo/concurrent/DivideAndConquer.java#L89-L95

ojAlgo/src/main/java/org/ojalgo/concurrent/DivideAndConquer.java

Lines 89 to 95 in 61bd57e

	try {
	DivideAndConquer.call(executor, split, limit, threshold, nextWorkers, conquerer);
	firstPart.get();
	} catch (final InterruptedException | ExecutionException cause) {
	throw new RuntimeException(cause);
	}

Fix in Cursor

---

Was this report helpful? Give feedback by reacting with 👍 or 👎