bug: actual threads usage differs from the announced one

[Eldar]

With the latest MARK:
gfortran(Win64) Vers. 7.0 Sep 2012 under Windows 7 64 bit I am getting following problem at 2 independent workstations under absolutely different models.
in the out file Mark says:
" This problem will use 1 of 24 possible threads."
But it actually uses all 24 and even not -1 as it should use if the "threads" were not set.
Is there a way to solve it?
Thanks,
Eldar

[cooch]

Try latest version of MARK - just posted last night. Minor threads bug fixed - might influence what you're seing.

[Eldar]

Unfortunately it did not.
Am I the only person that has got this problem or the only person on Windows machine?
Eldar

[jlaake]

Eldar-

I'm using windows and if I use -1 it appears to work. You may want to uninstall MARK and then reinstall to make sure nothing is being left from a previous version. Here is the output header for my run with threads=2

Program MARK - Survival Rate Estimation with Capture-Recapture Data
gfortran(Win64) Vers. 7.0 Sep 2012 19-Feb-2013 09:06:09 Page 001
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

This version was compiled by GCC version 4.8.0 20120422 (experimental) using the options
-m64 -mtune=generic -march=x86-64 -mthreads -O2 -fimplicit-none -fbounds-check -funroll-loops -ftree-vectorize -fopenmp.
This problem will use 2 of 8 possible threads.

--jeff

[Eldar]

Jeff,
I have the same output header, but if you'll try to run model that takes time and check actual threads usage (or total load) you will see that Mark uses all possible threads. Could you check if I am right please?
Thanks,
Eldar

[jlaake]

I have verified the behavior that Eldar has described. I was fooled at first because it shows thread=1 until it starts to do the iterations. Then it jumped to 8 even though I set it to 2 and it reported 2 of 8 in the output.
I'm using Sept 2012 version but it sounds like the same is happening with most recent version for Eldar. Note that I'm using threads= option on the command line and not in the input file, if that makes a difference.

--jeff

[cooch]

I have verified the behavior that Eldar has described. I was fooled at first because it shows thread=1 until it starts to do the iterations. Then it jumped to 8 even though I set it to 2 and it reported 2 of 8 in the output.
I'm using Sept 2012 version but it sounds like the same is happening with most recent version for Eldar. Note that I'm using threads= option on the command line and not in the input file, if that makes a difference.

--jeff

Several things. First, 'threads' is not the same thing as 'cores'. See the following for a reasonable discussion:"

http://wiki.answers.com/Q/What_is_Diffe ... nd_threads


Second, because of what *is* and what is *not* being run in parallel in MARK (Gary has discussed this elsewhere), using things like Task Manager in Windows (or, worse, the little desk applet that shows 'CPU use' for Windows Vista/7 don't really tell you much.

[gwhite]

Try the February 2013 version....

Gary

[jlaake]

The 19 Feb 2013 version works correctly. Thanks Gary. --jeff

[cooch]

I've done a fair bit of testing of the new code, and it does seem to work as advertized. Mean wall-clock speed scales roughly linearly to number of cores - meaning running with 4 cores is ~2x faster than 2 cores...and so on.

Having said that, the realized benchmark for any given 'run' seems to be fairly strongly impacted by 'other events' on your computer. This is more likely the case under Windows than under Linux (I'll confirm at some point). While the mean wall-clock times scale as described above, the variation around the mean can be pretty impressive. For example, here are the times (in seconds) for a long-ish benchmark that I ran 10 times in succession (using a .bat file executed and calling mark64.exe from the command line):

162.42
252.41
205.68
197.31
175.88
178.75
210.83
183.68
177.49
264.67