[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 1 May 2013 23:04:32 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: MPI vs. --fork
On 30 Apr, 2013, at 16:33 , magnum <john.magnum@...hmail.com> wrote:
> My goal is to have MPI and -fork so very similar that a forked run can be resumed with MPI, or vice versa. The contest branch was almost there.
I will start this for real tomorrow but here are some loose plans:
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.
Simple is beatyful. I think the above will basically do the trick (though the devil may be in the details). BTW for combinations like this:
./john -fork=4 -node=5-8/12 ...
in the contest branch, this could also be done with MPI as in:
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!
magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
