1999
DOI: 10.1007/978-3-642-58360-5_28
|View full text |Cite
|
Sign up to set email alerts
|

Avoiding Algorithmic Obfuscation in a Message-Driven Parallel MD Code

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
1
1

Citation Types

0
2
0

Year Published

1999
1999
2024
2024

Publication Types

Select...
3
1
1

Relationship

1
4

Authors

Journals

citations
Cited by 5 publications
(2 citation statements)
references
References 7 publications
0
2
0
Order By: Relevance
“…While the integration algorithm is the clearly visible "outer loop" in a serial program, NAMD's message-driven design could have resulted in much obfuscation (as was experienced even in the simpler NAMD 1.X [4]). This was averted by using Charm++ threads to write a top-level function that is called once for each patch at program start and does not complete until the end of the simulation [101]. This design has allowed pressure and temperature control methods and even a conjugate gradient minimizer to be implemented in NAMD without writing any new code for parallel communication.…”
Section: Goals Design and Implementationmentioning
confidence: 99%
“…While the integration algorithm is the clearly visible "outer loop" in a serial program, NAMD's message-driven design could have resulted in much obfuscation (as was experienced even in the simpler NAMD 1.X [4]). This was averted by using Charm++ threads to write a top-level function that is called once for each patch at program start and does not complete until the end of the simulation [101]. This design has allowed pressure and temperature control methods and even a conjugate gradient minimizer to be implemented in NAMD without writing any new code for parallel communication.…”
Section: Goals Design and Implementationmentioning
confidence: 99%
“…Also, a reactive and event-driven style of programming obscures the description of the life-cycle of an object. For example, a program would specify that when this message A arrives, execute method F; when B arrives, execute G, but can not specify that the object is going to repeatedly process A and B messages in alternating sequence k times [23]. Structured Dagger (SDAG) [15] is an effort to remedy this problem.…”
Section: Event-driven Objectsmentioning
confidence: 99%