1 |
This is my very brief second report. |
2 |
|
3 |
I have begun to code the benchmark suite. As case study, I have |
4 |
written a Python script for BLAS implementations. Given a dictionary |
5 |
containing information on which package to test with which |
6 |
environment, the script emerges the package with the given |
7 |
environment, installs it in the given directory (alternative root), |
8 |
tests the implementation and stores the results. In this way, the |
9 |
non-root user can also independently test the BLAS implementations and |
10 |
the main system remains unaffected. The same package can be tested |
11 |
with different environment states (e.g. blas-reference with |
12 |
FC=gfortran or with FC=ifort) and the results will be treated |
13 |
separately. |
14 |
|
15 |
I don't have yet a testing suite. My mentor and I are trying to adapt |
16 |
the BTL testing suite. We are also trying to solve a problem with the |
17 |
dynamic linking of blas-reference which has emerged during the tests. |
18 |
|
19 |
I'm writing a minimal Python interface to portage using the command |
20 |
line: the script makes use of the functions in this interface in order |
21 |
to install and remove packages. As soon as I can I will change the |
22 |
implementation of these functions using the existing APIs (gentoolkit |
23 |
and public_api), without the need to change anything in the main |
24 |
script. |
25 |
|
26 |
Next objectives (1-2 weeks): |
27 |
* Interpret the user's input about the libraries to be tested. |
28 |
* Construct a test suite for BLAS. |
29 |
* Split from the script the test-dependent code. The script has to be |
30 |
general, while external modules will give information on how to |
31 |
install and test the implementation packages. |
32 |
* Make the portage interface better, possibly using the existing APIs. |
33 |
|
34 |
-- |
35 |
Best regards |
36 |
Andrea Arteaga |