1 |
I forgot to say that an important feature that has been added to the |
2 |
script is the capability to generate an HTML report that contains the |
3 |
plots resulting from the tests. |
4 |
|
5 |
Moreover, an objective for the next week is the implementation of an |
6 |
accuracy test for LAPACK, and the support for CBLAS besides BLAS. |
7 |
|
8 |
Best regards |
9 |
Andrea Arteaga |
10 |
|
11 |
2011/7/3 Andrea Arteaga <andyspiros@×××××.com>: |
12 |
> After my absence, the development is restarted very productively. The |
13 |
> work done in the last week: |
14 |
> |
15 |
> * A very basic ebuild was done and the repository has now a |
16 |
> portage-tree structure, making the project installable using layman. |
17 |
> * Many lots of bugs were solved. Now the script is much more stable and usable. |
18 |
> * Some improvement in the output, which is now clearer. A summary of |
19 |
> the operations is printed at the beginning and the nesting of the |
20 |
> messages is correct. |
21 |
> * Everything is now logged. Emerge commands, suite compilations and |
22 |
> executions are logged into /var/log/benchmarks, which makes easy for |
23 |
> the user to understand what happens in case of error (or just for |
24 |
> awareness). |
25 |
> * blas, cblas and lapack are fully supported. |
26 |
> * A completely new module "blas_accuracy" has been added: this module |
27 |
> tests the implementations of blas for result correctness. |
28 |
> * The "clean code" work continues. |
29 |
> |
30 |
> For blas, cblas and lapack libraries, I was using a modified version |
31 |
> of BTL as benchmarking suite. This approach is very good some such |
32 |
> libraries, but it won't be possible for everything. For example, in |
33 |
> order to test the numerical correctness of libraries, BTL is not the |
34 |
> right tool to use. Therefore, a different Python module which does not |
35 |
> rely on BTL has been introduced. Nevertheless, as much code as |
36 |
> possible is shared between BTL-modules and no-BTL-modules, |
37 |
> demostrating that the script now is sufficiently generic to support |
38 |
> different kinds of modules. This is important, as in the following I |
39 |
> plan to support libraries that require a very different approach from |
40 |
> blas-like libraries (e.g. fftw). |
41 |
> |
42 |
> For the next week, I want to provide at least a basic support for: |
43 |
> |
44 |
> * Introducing the support for fftw (maybe other fft libraries) |
45 |
> * Constructing a basic benchmarking suite for distributed numerical |
46 |
> libraries (PBLAS, ScaLAPACK, ...) |
47 |
> * Enhancing the ebuild so that the project honors the Gentoo standard |
48 |
> |
49 |
> Best regards. |
50 |
> Andrea Arteaga |
51 |
> |