<div dir="ltr">Thank you for your answers. I wrote a detailed proposal on the GSoC page, and I tried to make it so everything can be run locally (on one machine), but the results will be able to be sent to a central website as well. My proposal is here: <a href="https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/noughmad/74002">https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/noughmad/74002</a>. <br>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/4/25 Christian Engwer <span dir="ltr"><<a href="mailto:christian.engwer@uni-muenster.de" target="_blank">christian.engwer@uni-muenster.de</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Miha,<br>
<div class="im"><br>
> I know this topic already got some interest, so let me be the first to<br>
> write a proposal here. I will add it to Google's site as soon as I get some<br>
> feedback. I would mostly like some clarifications on the infrastructure<br>
> (hardware) side of things.<br>
<br>
</div>regarding the hardware there is nothing to rely on. First of all you<br>
should be able to run test on a given machine with given hardware<br>
(just one seq. process). Later we might want to extend this to<br>
parallel tests.<br>
<br>
I'd say the best bet is to assume a stable hardware and clear the<br>
history when the hardware changes, as it is nearly impossible to get<br>
comparable results on different hardware (remember the bogomips?)<br>
<br>
> *Introduction*<br>
<div class="im">><br>
> My name is Miha Čančula and I'm a Physics student from Slovenia. I am<br>
> interested in Dune, especially the software testing project.<br>
><br>
> My field is computational physics, so I write a lot of numerical code, but<br>
> I've never heard about Dune until the GSoC listing. This is too bad,<br>
> because I could probably use it for school projects. Apart from physics, I<br>
> like programming free software, and have a special fondness for software<br>
> testing. I write code in a variety of languages (in rough order of<br>
> preference: C++, Python, Octave, Java, JavaScript, ..., VBA, BibTeX<br>
> Anonymous Forth-Like Language).<br>
><br>
> I have participated in GSoC for the last two years, once providing<br>
> visualizations for a data mining program, and once adding a unit testing<br>
> module to the KDevelop IDE.<br>
><br>
</div>> *The Project<br>
<div><div class="h5">><br>
> *<br>
> This projects consists of four basic parts: A number of example benchmarks<br>
> to run, a script to run them and store results, a web-based dashboard for<br>
> statistics and reporting, and infrastructure for running the performance<br>
> tests.<br>
><br>
> The first part is most integral to DUNE, but is probably the easiest. I<br>
> will create some executables that make use of various features of DUNE.<br>
> This includes various allocations, common linear algebra operations, etc.<br>
> As I get more familiar with DUNE, I will be able to come up with other<br>
> examples. Some of the existing tests are good candidates.<br>
><br>
> The test running environment will measure spent time and consumed memory<br>
> while both compiling and running these benchmarks. I am a long-time Linux<br>
> user, so I have a lot of experience with Linux tools. However, in order to<br>
> allow testing on other systems, I will try to make the script<br>
> cross-platform. The results will be then stored in a database where the<br>
> web-based dashboard can collect them.<br>
><br>
> A web dashboard would be similar to the existing one at<br>
> <a href="http://autobuild.dune-project.org/buildlog" target="_blank">http://autobuild.dune-project.org/buildlog</a>. Unfortunately, the current site<br>
> is very slow, and I don't know why that it. Apart from simply displaying<br>
> the results, the performance testing dashboard will also need to perform<br>
> basic statistics on the results. This means extracting trends and<br>
> identifying outliers, but also comparisons between different architectures<br>
> and some measure of scalability. I have some web programming experience,<br>
> but only with Python and Django. I would prefer to write a dashboard in<br>
> Python, because it has great numerical tools, but could also adapt to<br>
> writing in Perl if really needed.<br>
<br>
</div></div>regarding the buildlog, a phd in Heidelberg wanted to give this a<br>
more little love. And in general I don't see a problem in having an<br>
other tool for the performance test. Actually I'd even prefer having<br>
something seperate and preferably such that it is possible to run it<br>
easily on a local machine, to allow developers of other modules to use<br>
it them selfs.<br>
<div class="im"><br>
> I do not know how busy the autobuild machines are at the moment, but<br>
> performance testing would definitely involve more system load that plain<br>
> unit testing.<br>
<br>
</div>not necessarily<br>
<div class="im"><br>
> I would like to re-use the same testing machines for<br>
> performance testing as well. Unfortunately, it only has GCC at the moment.<br>
> I don't know how those machines are administered, but I hope installing at<br>
> least different versions of GCC and CLang is possible. I also have no idea<br>
> how your project is funded, so I can't really say what would be the best<br>
> infrastructure for this. Alternatively, the tests could run on developers'<br>
> machines. This way there is surely more diverse data (a lot more<br>
> configurations), but there could hardly be continuous testing this way.<br>
> There is also a third way of powering on a couple of virtual machines<br>
> periodically, however I don't like this, because it's expensive and<br>
> resources sharing may affect performance.<br>
<br>
</div>We should first get things in a good shape then we can easily add more<br>
test-setups and more compilers.<br>
<br>
Running test on developer machines should definitely be an option. Perhaps<br>
the developer could collect statistics in some local DB (e.g. sqlite)<br>
and generate stic html pages to inspect the performance plot?!<br>
<br>
> *Questions*<br>
<div class="im">><br>
> I think I have the first three part roughly worked out. Of course I will<br>
> probably need help, and I welcome any input now. I will also add some<br>
> details, as well as a projected timeline, before adding the proposal to<br>
> Google's site.<br>
><br>
> But I would like to know more about the infrastructure part. Could anyone<br>
> tell me what kind of machines are currently in use? Do you have any plans<br>
> to add new ones, either actual machines or virtual?<br>
<br>
</div>In the first part we would not add more machines, but the system<br>
itself should be able to handle changing setups. The current buildlog<br>
system does not keep a configuration of the different platforms, but<br>
generates the list on-the-fly. One issue is that some of the machines<br>
are virtual, so time measurement is a bit more tricky.<br>
<br>
For really short test (very short unit-tests) it might even be<br>
interesting to run tests using the callgrind tool of valgrind and<br>
count cpu instructions.<br>
<div class="im"><br>
> Finally, do you have any other tips for me?<br>
<br>
</div>Not directly ;-) Keep in mind, that you not only have to convince us,<br>
but google also has to grant the slot.<br>
<br>
Cheers Christian<br>
</blockquote></div><br></div>