Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 2 May 2013 02:34:23 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: MPI vs. --fork

On Wed, May 01, 2013 at 11:04:32PM +0200, magnum wrote:
> This will happen when an MPI build is actually running on more than one node:
> * Early on, it will clear john_main_process for all but node 0.
> * When starting a new session, it will reject the --fork option.
> * But it will write a fake "-fork=x" entry in the rec file.
> * And when resuming, it will ignore any "-fork=x" entry in the rec file. Actually it will demand one but ignore it's original meaning - and it will verify that x == number of nodes and bail out otherwise.

Of the four items above, what do the last two buy us?

> mpirun -np 4 ./john -node=5-8/12 ...
> 
> The contest-branch code for this MPI-specific case is hard to follow. If my unification of MPI & fork goes well, this will now be supported basically just using present core code. Less differences, less maintenance, much more reliable!

The "mpirun -np 4 ./john -node=5-8/12 ..." syntax implies that if you
omit mpirun in an MPI-enabled build and run with a --node option like
this, it will work differently from a non-MPI build - namely, it will
run like --node=5/12 instead of like --node=5-8/12.  I think this is bad.

When --node is used with a range yet --fork is not specified, core and
bleeding (when MPI is not enabled) will now do the work of those
multiple nodes (within the range) inside one process.  This is useful
when the nodes are of non-equal speed - e.g., an OpenMP-enabled build
running on a quad-core may use 4 node numbers without --fork, and
another one running on a dual-core as part of the same distributed
attack may use 2 node numbers also without --fork, or either/both may
use these node numbers with --fork (the invocation is the same except
for the optional use of --fork).

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ