next up previous index
Next: Parallelism and Side Effects Up: Parallel Execution Previous: Parallel Programming Constructs   Index

Subsections

Controlling and Analysing the Execution

Which worker executes this code?

Although the parallelism is controlled automatically, during program development it is useful to find out how the system actually behaves. In the following example we use get_flag/2 to find out which worker finds which solution:
[eclipse 1]: fork(10,X), get_flag(worker,W).

X = 6
W = 4     More? (;) 

X = 7
W = 2     More? (;)
The solution X=6 has been found on worker 4 and X=7 on worker 2. In a parallel session, the number identifying the worker is greater or equal to 1, in a sequential session it is 0.

Measuring Runtimes

Measuring runtimes of parallel executions is especially tricky, since the processes involved have their own local timers, e.g. for measuring cputime. The simplest way is to measure true elapsed time instead of cputimes, and use an otherwise unloaded machine. The primitive that should be used to read the clock is
statistics(session_time, T)
where T is the number of seconds elapsed since the start of the parallel session.

Amount of Parallelism

On hardware that provides a high-precision low-overhead timer, the predicate par_statistics/0 from the par_util library can be used. It prints a compact summary information about where the different workers spent their time, together with some other data about the parallel execution. For example:
[eclipse 7]: par_statistics_reset, queens(10), par_statistics.
 Wrkr Jobs Prun Published Copy      Copied  Idling Working Copying Scheduling
   ID    #    # cpts alts    #       bytes      ms      ms      ms      ms

    1   24    0   34   34   11       30208      50    7591      10     157
    2   24    0   16   16   15       29088     147    7638       8      18
    3   35    0   38   38   18       39656     134    7604      38      35
    4   30    0   25   25   13       36668     192    7519      34      24

Adding and Removing Workers

Workers in a parallel ECLiPSe session can be in one of two states: active (awake) or asleep. As one would expect, only active workers take part in any computation. A newly created worker's default state is active. New workers can be added and the number of active workers can be altered using the worker manager interface. These actions are performed asynchronously, thus the configuration can be altered even during parallel execution: a newly added worker will join the computation and when a worker is sent to sleep, it will stop working at an appropriate point of the execution. Note that the worker manager interface be started either using the -wmi command-line option or via the wm_set/2 builtin.

Worker management is also possible under program control. Use the builtins wm_get/2 to inquire about, and wm_set/2 to affect the worker configuration. For example, to enquire about the number of workers currently active:

[eclipse 1]: wm_get(workers(Host), Awake+Asleep).

Host = "turing"
Awake = 2
Asleep = 1
yes.

This means that the there are a total of 3 workers on the machine ``turing'', out of which 2 are active. In the above example, if one wanted to have only one worker active:

[eclipse 2]: wm_set(workers(turing),1), wm_get(workers(turing),Status).

Status = 1 + 2
yes.


next up previous index
Next: Parallelism and Side Effects Up: Parallel Execution Previous: Parallel Programming Constructs   Index

1999-08-06