[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d459c0da363ada6df1b0cd4b5fb05c08@smtp.hushmail.com>
Date: Thu, 8 Aug 2013 01:05:36 +0200
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: --fork using different OpenCL devices
On 7 Aug, 2013, at 21:45 , Lukas Odzioba <lukas.odzioba@...il.com> wrote:
> 2013/8/7 magnum <john.magnum@...hmail.com>:
>> The idea is to have -fork pick a different device (starting from 0 or picking from a given list) for each child. Picture having two 7990 cards for a total of four devices. Using "-fork=4" with an OpenCL format would pick device 0 for the mother process, device 1 for first child and so on. Only very fast formats [where set_key() is a bottleneck] would benefit.
Actually key generation (ie. the cracking mode except for mask mode) is often a worse bottleneck so maybe this would be a pretty good option to have.
>
> What would be the speed of slower+faster device combination? 2*slower?
> For homogenous system it is good solution anyway.
The faster device would run at full speed but that process will complete earlier because the job would be split in half. This is the same problem as when running MPI with heterogenous nodes. It is possible to mitigate using some option that internally converts to -node functionality, ie. the slower device is node 1 of 3 and the faster one is nodes 2 and 3 of 3. The only hard part in implementing that would be what option syntax to use...
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.
