mersenneforum.org - TortureHyperthreading, does it help for stability testing?

Is there any meaningful difference for a torture test regarding stability testing if you activate [FONT=Lucida Console]TortureHyperthreading[/FONT] in prime.txt or not?

I.e. for single core stability testing with two threads, and manually setting the affinity to one specific core, is there a difference if you let Prime95 run with
[CODE]
prime.txt
----------
TortureHyperthreading=1

local.txt
---------
NumThreads=1
WorkerThreads=1[/CODE]

vs.

[CODE]
prime.txt
----------
TortureHyperthreading=0

local.txt
---------
NumThreads=2
WorkerThreads=2[/CODE]

In both cases one core is fully utilized with two threads. The second option is the "old" behavior until up to version 30.6, in 30.7 the new [FONT=Lucida Console]TortureHyperthreading[/FONT] setting was introduced. So I wonder, does it somehow affect the outcome of the stability test (better? harder?)?

As far as I can see, when the setting is activated Prime95 uses two distinct threads for anything up to an FFT size of 240k, and for 256k and up it uses one thread spread across two cores.

Unfortunately this introduces inconsistencies in the log file, where for the first part, it writes two log entries for each FFT size, and for the second part only one line, which makes parsing the log file rather cumbersome:
[code]
[Thu Sep 8 16:51:56 2022]
Self-test 224K (thread 2 of 2) passed!
Self-test 224K (thread 1 of 2) passed!
Self-test 240K (thread 2 of 2) passed!
Self-test 240K (thread 1 of 2) passed!
Self-test 256K passed!
[Thu Sep 8 16:53:11 2022]
Self-test 288K passed!
Self-test 320K passed!
Self-test 336K passed!
Self-test 384K passed!
[/code]

Which is why I reverted back to the "old" mechanism for now for [url=https://github.com/sp00n/corecycler]CoreCycler[/url], but if [FONT=Lucida Console]TortureHyperthreading[/FONT] does offer a valuable improvement over the previous implementation, I would adjust my log parser for it.