Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6999d011fd4990752d54dc8cee0a8f58@smtp.hushmail.com>
Date: Thu, 2 May 2013 00:52:26 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: MPI vs. --fork

On 2 May, 2013, at 0:34 , Solar Designer <solar@...nwall.com> wrote:
> 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?

That a session started with --fork can be resumed with MPI instead. And vice versa.

>> 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.

Does it imply that? I don't think so, especially since I'm planning to rely on core code as far as possible. "./john -fork=4" and "mpirun -np 4 ./john" should practically do the same thing, except the latter may run on up to four different hosts.

> 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).

I need to think it over and test it in reality. But again, I'm thinking that "mpirun -np 4" should behave exactly the same as "-fork=4" in regards to things like this.

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.