[quote=hj47;198468]Out of curiosity, does anyone know how a single LL performs on an i7 860 using all 8 threads?[/quote]
The [URL="http://www.mersenneforum.org/showthread.php?t=59&page=11"]benchmark thread[/URL] has some i7 benchmarks, which includes 8-threaded tests. I don't see any 860 models specifically, but you can probably find one with a similar GHz.

Ahhh I see.

Is there a rough calculation I can perform to see whether it would be faster to run a single LL test on 8 threads vs. 4 tests on 4 threads?

[quote=hj47;198490]Ahhh I see.

Is there a rough calculation I can perform to see whether it would be faster to run a single LL test on 8 threads vs. 4 tests on 4 threads?[/quote]
Unfortunately, no Prime95 benchmark will automatically test multiple tests at a time, and due to factors such as memory bandwidth it's not as simple as multiplying benchmark speeds. The best thing would be to try it for yourself.
But in general, you'll get more throughput with 4 tests on 4 threads than 1 test on 8 threads, and even more throughput by keeping 2 tests to low memory bandwidth work, like TF (e.g. worker 1/2/3/4 run LL/TF/LL/TF). You might get a little more throughput by having each worker use two logical cores (to try to use the hyperthreading). If you have an i7 with just 4 threads running, you might get more speed if you set the affinity of the workers with the AffinityScramble option.[code]You can arbitrarily change how the program assigns affinity to CPUs, to make sure no threads have to share a physical core.
The program makes its best guess at assigning workers and helper threads
to CPUs for optimal speed. However, new architectures or situations we
haven't considered may make different affinity setting desirable. In
local.txt set
AffinityScramble=string
Where the string "0123456789ABCDEFGHIJKLMNOPQRSTUV" is the "make no
changes" string. For example, let's say you have a system with 8 logical
cores with 4 workers each using a helper thread. The program would
ordinarily assign the worker and helper threads to [0,1], [2,3], [4,5], [6,7].
However, if you think [0,2], [1,3], [4,6], [5,7] would give better performance,
you would set AffinityScramble=02134657 to test out your theory.
[/code]

[quote=Prime95;198436] [B]Version 26[/B] will place more demands on the memory subsystem.[/quote]

Ho!Ho! Good news!
Any estimate as to the release date?
That could influence my upgrade schedule and architecture choices.

Version 26
 

[QUOTE=lycorn;198540]Ho!Ho! Good news!
Any estimate as to the release date?
That could influence my upgrade schedule and architecture choices.[/QUOTE]

And by chance a multi-threaded trial-factoring?

Luigi

[QUOTE=lycorn;198540]Any estimate as to the release date?[/QUOTE]

No time soon. I've rewritten a few of the FFTs between 2M and 4M. Left to do: rewrite all 2 pass FFTs, optimize for 64-bit, optimize for P4, K8, K10. A long, long, long vacation starting in January will slow development too.

I've changed the way the code is organized so that many different FFT implementations can be supported. The current FFT code remains as one of the FFT implementations, and I've been adding several other variations of radix-4 FFTs to study which ones might be faster.

[QUOTE=ET_;198551]And by chance a multi-threaded trial-factoring?[/QUOTE]

Highly unlikely. See previous post - my plate is pretty full.

[QUOTE=Prime95;198564]A long, long, long vacation starting in January...[/QUOTE]

Define "...long, long, long". :sleep:

Going anywhere specific? ... or taking one for the team, knowing there is a strong correlation between your vacations and Prme finds. :smile:

Enjoy the vacation :toot:

[QUOTE=petrw1;198566]Define "...long, long, long".[/QUOTE]

Nine weeks. South America.

[QUOTE=Prime95;198567]Nine weeks. South America.[/QUOTE]Time for a new prime!!!

[QUOTE=Prime95;198436]True for version 25. Version 26 will place more demands on the memory subsystem.[/QUOTE]

Because of CPU execution improvements, the balance between the CPU and memory being the bottleneck will be pushed more towards the memory? Just guessing here.

Oh, annoying feature request. Any way we can configure the thread/worker allocation in benchmarking? There's probably a way to fudge this. I just find that determining the optimal allocation for best throughput to be a lengthy PITA. I guess it's easy on the new Core-i chips, because, as you say, memory isn't an issue. Sadly not the case for my 3.2GHz C2Q. 8M of L2 just isn't enough and that slow FSB doesn't help, either. ;( On the other side, I have the Sempron 140 which has just as much memory BW, but a slower single core CPU. He's not memory starved. :)