[Chimera-users] Feature request: parallel MatchMaker?

[Eric Pettersen]

I didn't actually have my thinking cap on straight when I replied yesterday.  Using multiple Python threads doesn't actually help here because Python doesn't actually run threads in parallel -- it simply will switch to another thread if one blocks due to I/O.  There is no blocking I/O in the MatchMaker computation.

Therefore, I would have to port the code to C/C++ -- at least the compute intensive part.  On the other hand, such a port would probably provide enough speed up that you wouldn't actually need to also parallelize the code.  Anyway, will keep it in mind.

--Eric

On Sep 8, 2014, at 8:45 PM, Jonathan Sheehan <jonathan.sheehan at gmail.com> wrote:

> Eric,
> 
> Yes, it always looks easy to the guy who doesn't have to do it. :-)
> I'm just glad to have it go into the queue. Thanks so much for looking
> into it!
> 
> Much appreciated,
> -Jonathan
> 
> 
> On Mon, Sep 8, 2014 at 5:36 PM, Eric Pettersen <pett at cgl.ucsf.edu> wrote:
>> Hi Jonathan,
>>        This is a good suggestion, but as you kind of guessed it's not completely trivial, particularly for the "best" matching choices where the results of multiple attempted matches have to be compared to each other in a thread-safe manner.  It's certainly not impossible though.  I will open a feature-request ticket for this enhancement.  It may be more likely to get into Chimera 2 than Chimera 1 though, since I will have to make changes to the MatchMaker code as I port it to Chimera 2 anyway.
>> 
>> --Eric
>> 
>> On Sep 8, 2014, at 8:31 AM, Jonathan Sheehan <jonathan.sheehan at gmail.com> wrote:
>> 
>>> Hi-
>>> 
>>> I'm a huge fan of Chimera, and I frequently need to superimpose a
>>> dozen or more comparative models onto a template protein using
>>> MatchMaker. At present, one cannot  even rotate the view until all
>>> matches have completed, which can take a few minutes on a single core.
>>> 
>>> Based on old messages[1], it sounds like you might be "interested in
>>> allowing use of
>>> multiple cores for specific compute intensive tasks," and this seems
>>> to me like a good candidate. This use case involves many matches,
>>> which I think are completely independent of one another. Also, these
>>> models have identical length and sequence, so the runtimes should be
>>> fairly close to one another (although that wouldn't necessarily be
>>> true in the general case).
>>> 
>>> I'm sure that adding multi-threading to a tool is not trivial, but it
>>> seems as though this feature might have a high "bang for the buck" on
>>> today's multicore machines.
>>> 
>>> Thanks for considering it,
>>> -Jonathan
>>> 
>>> 1. E.g.  http://www.cgl.ucsf.edu/pipermail/chimera-users/2011-January/005901.html
>>> 
>>> --
>>> Jonathan Sheehan, Ph.D.
>>> Computational Structural Biology
>>> Vanderbilt Univ. Ctr. for Struct. Biol.
>>> 5137 MRB3, 465 21st Avenue S.
>>> Nashville, TN 37232-8755
>>> 615-936-2516
>>> _______________________________________________
>>> Chimera-users mailing list
>>> Chimera-users at cgl.ucsf.edu
>>> http://plato.cgl.ucsf.edu/mailman/listinfo/chimera-users
>> 
> 
> _______________________________________________
> Chimera-users mailing list
> Chimera-users at cgl.ucsf.edu
> http://plato.cgl.ucsf.edu/mailman/listinfo/chimera-users