The thing about the LOCALDEFS
Setting up the LOCALDEFS is hard work and seems to be an endless journey through system-manuals and websites with processor-informations. But this work is really NECESSARY to run the project properly. If you are connected to the database and look at online informations, you want to see, which compiler is used, which processor, but also maybe the kind of memory which is installed. Others want to compare their systems to yours too (if you allow them to, which can be done via the homepage...)! So, if you want their information, be fair and share yours.
When having set up LOCALDEFS, the rest is pretty easy.
Compiling a kernel
when you run
a lot of things happen (automatically ;) ) starting the local COMPILE.SH file of the kernel:
- starting tools/configure
- all variables setted in the <hostname>-file of the LOCALDEFS are exported
- everything in LOCALDEFS is started (here you can load modules ;) )
- the local PARAMETERS are exported (started)
- the whole environment (which means all environment variables) is appended to the environment-hashing file (bienvhash.template). The new file is called bienvhash.c
- the fileversion.c is compiled and started for getting the actual version of benchit
- the rest of the COMPILE.SH-Script is runned
- rest of COMPILE.SH
- here you set your compiler and stuff and compile your kernel
- Remarks to compiler
- BENCHIT_COMPILER or BENCHIT_LOCAL_KERNEL_COMPILER is written to the output-file as compiler
- BENCHIT_COMPILERFLAGS or BENCHIT_LOCAL_KERNEL_COMPILERFLAGS is written to the output-file as compilerflags
- the whole file will be linked and written to (in this case) bin/numerical.matmul.C.0.0.double.($BENCHIT_FILE_COMMENT)
Starting a kernel
When starting a kernel by
this will be done:
- running the tools/configure Script
- setting up the PARAMETERS to those, described in the local file PARAMETERS (in this case: kernel/numerical/matmul/C/0/0/double/PARAMETERS) (look for the flag --no-parameter-file to prevent this)
- getting informations from LOCLADEFS
- setting up variables for the ENVIRONMENT and run the kernel by starting the script for the selected ENVIRONMENT (which will start the kernel)
- known issues: be careful, that the ENVIRONMENT doesn't delete files you are using for an other run.
The problemsizes can be set at different times and places.
First - when compiling the kernel.
When compiling without the flag --no-parameter-file, the environment-settings from the kernels PARAMETERS files are stored in the binary.
When compiling with this flag, the parameters are not stored in the binary, but if environment variables with the corresponding names exist, they are stored.
Second - when running the kernel.
Use the flag -p to define a specific PARAMETERS-File to use
Use the flag --no-parameter-file to get the parameters from the environment
Use no flag to use the PARAMETERS-file from the specific kernel
When one environment variable isn't found by the kernel, it uses the variable from the compile-
The System is running a kernel
When the System runs a kernel.
- First the bi_init() procedure is called. Set your kernel-specific description here. (Look at the examples, how it is done)
- You also allocate some memory here! Don't forget
- AND you set the maximal problemsize here. Meant is the NUMBER OF DIFFERENT problemsizes, the bi_entry() procedure is called with!
- then the bi_entry() is called wih all problemsizes
- If you have set $BENCHIT_RUN_LINEAR, the problemsizes will encrease by one from 1 to the sette maximal problemsize (bi_init)
- If NOT, first the half problemsize is started, then those at 1/4th and 4/4th after that tose problemsizes at 1/8th, 3/8th ... and so on, until the difference between the points is small enough. Then the rest is runned linear. This feature is pretty important, to get an overview about the behaviour, if the kernel stops before having measured everything.
- IMPORTANT: You should compute your "REAL" problemsize here (e.g. for logarithmic encreasing of problemsizes)!
- IMPORTANT: The x-value (real problemsize) for this callshould be written to results, the following y-values (measured performance...) should be written to results and following. Look at the skeleton files for more information.
- IMPORTANT: Every problemsize will be measured $BENCHIT_ACCURACY+1 times (if setted to 2 (default) 3 times)
- Then the bi_exit() procedure is called. Here you may free your structures end PAPI-measurment and so on
- At last, the output is computed (exact values for min and max of axis (round values)) and written to the files
- IMPORTANT: this also contains the reading of the LOCALDEF-files <hostname>_input_architecture and <hostname>_input_display for the actual hostname! If these files cannot be read, BenchIT may stop at this point!