forums.silverfrost.com

Kenneth_Smith · Posted: Mon Dec 04, 2017 10:07 pm Post subject: Using threads

A few of my applications use a genetic algorithm for optimisation purposes, a slightly modified version of the veritable F77 routine PIKAIA http://www.hao.ucar.edu/modeling/pikaia/pikaia.php. The major overhead with GAs is the evaluation of the fitness function, and I am am aware of timeconsuming interval searches (for an overall minimum of maximum) within my fitness functions which consume a lot of CPU time. These have become a larger burden as I've tired to solve more complex problems.

A few years ago there was some discussion on the forum about using threads and a few sample programs were posted. Looking back at these last week I wondered if there was an opportunity to speed up some of these time consuming interval searches. The code below is my first attempt at this.

Basically, I am looking for the local maximum in an interval search between s = 0 and s = 1 (this is a made up example - I know that this particular test function can be solved analytically for Tmax). There are two subroutines, one searches between 0 and 0.5 and the other searches between 0.5 and 1. In the first instance they are called one after the other, and then they are run in parallel as threads.

Can somebody confirm if I have got the locking and unlocking correct? I am making local copies of all global variables and using these locals in the thread. Is this a sensible approach?

The code appears to run correctly under Win32 release, although the results under x64 release are a little disappointing:

Kenneth_Smith · Posted: Mon Dec 04, 2017 10:10 pm Post subject:

The sample code:-

Kenneth_Smith · Posted: Mon Dec 04, 2017 11:39 pm Post subject:

Interestingly compiling and running the code on a different machine produces the following timing results:-

PaulLaidler · Posted: Tue Dec 05, 2017 2:46 pm Post subject:

The results on my machine are similar to your first set.

I am using an Intel i7-4500U @ 1.80GHz.

The code for 64 bit LOCK@ etc. is identical to that for 32 bits.

The overall slowness of 64 bits might relate to the processing of complex expressions in this program but one would expect/hope for a similar comparative improvement with 2 threads and this appears not to be the case.

Kenneth_Smith · Posted: Tue Dec 05, 2017 3:44 pm Post subject:

Thanks Paul, It is indeed an unexpected result which you have confirmed.
The first set to timings were on an machine with Intel I5-2410 @ 2.3 GHz, the second Intel I5-3340 @ 2.7 GHz.

A third set of timings from a machine with Intel I7-5506 @ 2.4 GHz are:-

Kenneth_Smith · Posted: Tue Dec 05, 2017 9:40 pm Post subject:

Below is a simplified version of my earlier code, in which there is no manipulation of complex variables. Running this code suggests that the overall slowness of 64 bits is not related to the processing of complex expressions, as the issues identified in my earlier post are still apparent.

PaulLaidler · Posted: Wed Dec 06, 2017 3:36 pm Post subject:

I am using a 2 core CPU and both cores are apparently being used for 64 bits as for 32 bits.

At the moment I don't know why the 64 bit case shows no improvement when multi-threading.

DanRRight · Posted: Wed Dec 06, 2017 7:53 pm Post subject:

Kenneth_Smith · Posted: Sun Dec 10, 2017 12:33 pm Post subject:

John,

I'm using 8.2, so clearly there is a difference with the earlier release. It may be the call lock@(ithread) and call unlock@(ithread)

Try changing all of these to call lock@(data_lock) and call unlock@(data_lock)

and add integer,parameter::IO_LOCK = 1, data_lock = 2 to the global definitions in the module.

As I said, this is all new to me and I'm slowly trying work out how to do this. With 4 threads I can get a speed up of 3.4 times (two dual core processors), with Win32 and /optimise.

Ken

JohnCampbell · Joined: 16 Feb 2006 Posts: 2585 Location: Sydney

Ken,

I tried your examples using FTN95 Ver 8.20 and fond /64 to be faster for second test but slower for first (COMPLEX) test.

I made a few changes to provide some more statistics.

1) the timers record both elapsed and CPU time, to give an indication of the threading efficiencies.
2) you only need local (non saved) copies of variables that change in the thread calculation.
ds, r1,x1,ns etc don't need local copies as they are never changed,
while s_loc, tmax_loc, t_loc, k_loc and i_loc need to have local copies.
3) can demonstrate multi-thread without routine search2, as search1 is thread safe. (reduces code size, which is critical for this forum)

My batch file to test different compile options is

JohnCampbell · Joined: 16 Feb 2006 Posts: 2585 Location: Sydney

JohnCampbell · Joined: 16 Feb 2006 Posts: 2585 Location: Sydney

results include

jalih · Joined: 30 Jul 2012 Posts: 196

Anyone tested results with lock free code? Locking is expensive. IO should be taken out from threads and memory structures should be organized to allow lock free code.

PaulLaidler · Posted: Mon Dec 11, 2017 11:45 am Post subject:

John has correctly identified the source of the problem...

CLOCK@ gives the elapsed time for 32 bits but the CPU time for 64 bits.
The CPU time combines the times for both threads.

The treading is working correctly and the reduction in elapsed time is comparable between 32 bits and 64 bits.

One way to correctly calculate the elapsed time is to call SYSTEM_CLOCK.

We should probably treat the issue with CLOCK@ as a bug in the 64 bit library although this will only be apparent when using threading.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2585 Location: Sydney

The following is an example where the number of threads can be varied more easily.
The same routine is called for multiple threads, with the "arg" indicating which thread is being called.
It appear to work, giving the same answer.