<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 28, 2013 at 9:58 PM, Szilárd Páll <span dir="ltr">&lt;<a href="mailto:szilard.pall@cbr.su.se" target="_blank">szilard.pall@cbr.su.se</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Indeed, and I was hoping that such concrete aspects of a split will be<br></div>
brought up in this discussion - instead of claims of this being a<br>
non-issue (at least not a timely one).<br>
<br>
Having spent only a couple of minutes thinking about what could be<br>
obviously moved out of a potential libgromacs_core, here are a couple<br>
of things:<br></blockquote><div><br></div><div>Some comments inline on some.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

- use of exceptions: I was going to say that we could make<br>
libgromacs_core exception-free, but that&#39;s probably not going to be a<br>
popular suggestions; however, outside of libgromacs_core exceptions<br>
could possibly be used in a more liberal manner.<br></blockquote><div><br></div><div>While in principle possible, I think this requires someone to write a lot of code; see the main point at the end of the e-mail. What could be more doable is to make it _possible_ to compile this part without exceptions (but not the default), but with some reduced functionality (like, program immediately terminates on errors, and some context information for the error message is lost).</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- fancy containers vs flat arrays for generic storage (e.g coordinates, forces).<br></blockquote><div><br></div><div style>std::vector is a flat array. ;) But if we want to have control over the allocation strategy, we may need a custom container. But still, basic C++ containers make writing the code a lot easier.</div>
<div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- cache-friendly and concurrent data-structures (required in core<br>
probably not in tools).<br>
- AoS vs SoA.<br>
<br>
I know these suggestions are rather vague, so I think here&#39;s the point<br>
where a  bit of brainstorming could help.<br>
<div><br>
&gt; was discussed, I think I wrote a long e-mail (or perhaps a comment in<br>
&gt; Redmine, can&#39;t remember) to enumerate some points that need to be<br>
&gt; considered, with the result that the discussion died immediately... I can<br>
&gt; try to look that up if people are really interested.<br>
<br>
</div>Please do. I have probably not commented much (if at all) - sorry about that.<br></blockquote><div><br></div><div>Couldn&#39;t find that with a bit of searching, so perhaps faster to write it again. I&#39;m quite sure I&#39;ve mentioned at least of some of this somewhere to someone earlier, though. ;)</div>

<div><br></div><div>The first point is that there are really two concerns, and we should be clear which one we are trying to address by which proposals:</div><div><div><ol style><li style>Are we concerned that the code will be difficult to compile at all? Here, it is very difficult to predict what some future compiler may or may not support. The standard has a concept of a limited free-standing implementation for embedded systems, but I think that it allows a very stripped-down standard library, not skipping support for any language features.</li>
<li style>Or are we concerned that C++ code will be difficult to get efficient? For the efficiency, it is overly zealous to prevent using even basic C++98 features in code that has no impact on performance. Examples being code that parses command-line options or prints out &#39;mdrun -h&#39; or such. About the only C++ feature for which you may pay a performance penalty even in code where you don&#39;t use it is exceptions: early compiler implementations incurred some overhead by just turning exception handling on. But it should be perfectly fine to compile the kernels and some other low-level code in C if that is a major concern. And/or add an option to build without exceptions as mentioned above.</li>
</ol></div><div style>That brings me to my main point: there is a lot of code that is shared by mdrun and tools. Examples are command-line parsing and many kinds of file I/O. If we want to be strict about the split, and the tools need features in there that is not allowed by our stricter rules for mdrun, then we somehow need to duplicate the code. This means either<br>
</div><div style><div><ol style><li style>having duplicate, independent implementation for the same thing on both sides, or</li><li style>having a complex layered system with a core implementation for these features, and then wrapper (at least for the tools, but possibly also for mdrun) to add fancier features on top of that.</li>
</ol></div>The current implementation may serve as a basis for 1., but not really for 2., since it is littered with gmx_fatal() calls, and the tool code really wants to have proper error handling. I haven&#39;t seen much enthusiasm to put a lot of effort into such work that this would require, which is why I think this will be the main hurdle.</div>
<div style><br></div><div style>Finally, my mention of &quot;limited features&quot; for such reduced mdrun were more directed towards all this shared support code rather than actual mdrun features. For example, &quot;do we need mdrun -h in the reduced mdrun?&quot; (this could be directly shared with tool code, but it&#39;s a lot easier to write it with less strict rules), or &quot;do we need exactly the same error messages, with all nice-to-have context information, in the reduced mdrun?&quot;.</div>
<br></div><div style>Best regards,</div><div style>Teemu</div></div></div></div>