[QUOTE=Praz;118009]Thank you. Downloading now. :smile:[/QUOTE]

Praz, I've not uploaded a fixed Windows version. The only uploaded fix is for Garo.

Ok, I will test it later today and report back to you.

[quote=Prime95;118015]Praz, I've not uploaded a fixed Windows version. The only uploaded fix is for Garo.[/quote]
LOL. I discovered that when I forced one of the cores to fail. Thanks for looking into this.

John

Hi George, I am getting a gzip error when I try to decompress the later tarball that you uploaded.
Thanks

Garo, I uploaded again. Sorry for the trouble.

Got it thanks, but no dice. Changing priorities through nice has no affect on the proportion of CPU taken. If it helps, I'm running v24 in a separate directory at the same time and v24 is getting about 85% of the CPU (it has a nice value of 10). v25 gets about 7-8% when Priority=1 in prime.txt and another program is taking the next.

Just to repeat, if I change the priority in prime.txt it does have an affect on the CPU% taken. But nicing on the command line has no impact (other than to change the values showed by ps and top).

[QUOTE=garo;118052]Just to repeat, if I change the priority in prime.txt it does have an affect on the CPU% taken. But nicing on the command line has no impact (other than to change the values showed by ps and top).[/QUOTE]

OK, this is what I would expect. I thought v24 behaved roughly the same way.

Mprime takes the prime95 priority and maps it into linux priorities independent of any command line nice settings.

In v25 I ran two worker threads. I then did a "ps -Lfly" and saw the main thread and timer thread running at priority 0. The worker threads were running at priority 19. I repeated the same test using "nice ./mprime -m" and the worker threads again ran at priority 19 while the main thread and timer thread ran at priority 10.

Is there a better/more-desirable way to handle priorities? Instead of mapping prime95 priorities from 0 to 19, should I map them into initial-process-priority to 19??

Ok. Looks like the problem is not in the mapping of priorities at all. As you can see, a renice changed the priority of the main thread but not the worked thread. Since v24 has only one thread, the renice will change the priority of that thread and cause it to use less CPU. Here is what ps -Lfly gives me:
[CODE]R garo 5125 5124 5125 76 1 95 10 10776 4047 - Oct25 ? 10-16:48:19 ./mprime -d
S garo 9429 5600 9429 0 3 78 -1 2904 8903 futex_ 14:52 pts/1 00:00:00 ./mprime -d
S garo 9429 5600 9430 0 3 75 0 2904 8903 futex_ 14:52 pts/1 00:00:00 ./mprime -d
R garo 9429 5600 9432 6 3 99 19 2904 8903 - 14:52 pts/1 00:06:54 ./mprime -d
[/CODE]

The first line is for v24 and the next three for the v25 main, comm (edit: timer) and worker threads. As you can see, nicing the v25 process to -1 (very high priority) has no impact on the worker thread which continues at a lower priority than the v24 process.

What I would recommend is simply this: get the worker thread to inherit the priority from the main thread when it is reniced. You are doing the mapping from prime.txt at start up. But make sure that the nicing percolates to the worker threads too.

[QUOTE=Prime95;118006]I also noticed a hyperthreading affinity bug. I'll need benchmarks from hyperthreaded machines for the next release.
[/QUOTE]

I'm using a P4-2.6 Northwood. Just let me know what you need done....

[QUOTE=harlee;118080]I'm using a P4-2.6 Northwood. Just let me know what you need done....[/QUOTE]

I have a P4 Prescott 3.4 Ghz hyperthreaded.

Prime95-64 under Vista64 doesn't seem to release as much memory as I think it should when stopping all worker threads. I'm running 2 ECM threads. #1 is on stage2 and using 464MB (according to the worker thread), #2 is on stage 1 and using a presumably negligible amount of RAM. TaskManager shows 517MB in use (~53MB by stage2 + Prime95 itself). However, when I stop all worker threads, memory usage (according to Task Manager) only drops to 234MB. Why is Prime95 hanging onto so much memory?