You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

154 lines
6.3 KiB

  1. Bench Template Library
  2. ****************************************
  3. Introduction :
  4. The aim of this project is to compare the performance
  5. of available numerical libraries. The code is designed
  6. as generic and modular as possible. Thus, adding new
  7. numerical libraries or new numerical tests should
  8. require minimal effort.
  9. *****************************************
  10. Installation :
  11. BTL uses cmake / ctest:
  12. 1 - create a build directory:
  13. $ mkdir build
  14. $ cd build
  15. 2 - configure:
  16. $ ccmake ..
  17. 3 - run the bench using ctest:
  18. $ ctest -V
  19. You can run the benchmarks only on libraries matching a given regular expression:
  20. ctest -V -R <regexp>
  21. For instance:
  22. ctest -V -R eigen2
  23. You can also select a given set of actions defining the environment variable BTL_CONFIG this way:
  24. BTL_CONFIG="-a action1{:action2}*" ctest -V
  25. An exemple:
  26. BTL_CONFIG="-a axpy:vector_matrix:trisolve:ata" ctest -V -R eigen2
  27. Finally, if bench results already exist (the bench*.dat files) then they merges by keeping the best for each matrix size. If you want to overwrite the previous ones you can simply add the "--overwrite" option:
  28. BTL_CONFIG="-a axpy:vector_matrix:trisolve:ata --overwrite" ctest -V -R eigen2
  29. 4 : Analyze the result. different data files (.dat) are produced in each libs directories.
  30. If gnuplot is available, choose a directory name in the data directory to store the results and type:
  31. $ cd data
  32. $ mkdir my_directory
  33. $ cp ../libs/*/*.dat my_directory
  34. Build the data utilities in this (data) directory
  35. make
  36. Then you can look the raw data,
  37. go_mean my_directory
  38. or smooth the data first :
  39. smooth_all.sh my_directory
  40. go_mean my_directory_smooth
  41. *************************************************
  42. Files and directories :
  43. generic_bench : all the bench sources common to all libraries
  44. actions : sources for different action wrappers (axpy, matrix-matrix product) to be tested.
  45. libs/* : bench sources specific to each tested libraries.
  46. machine_dep : directory used to store machine specific Makefile.in
  47. data : directory used to store gnuplot scripts and data analysis utilities
  48. **************************************************
  49. Principles : the code modularity is achieved by defining two concepts :
  50. ****** Action concept : This is a class defining which kind
  51. of test must be performed (e.g. a matrix_vector_product).
  52. An Action should define the following methods :
  53. *** Ctor using the size of the problem (matrix or vector size) as an argument
  54. Action action(size);
  55. *** initialize : this method initialize the calculation (e.g. initialize the matrices and vectors arguments)
  56. action.initialize();
  57. *** calculate : this method actually launch the calculation to be benchmarked
  58. action.calculate;
  59. *** nb_op_base() : this method returns the complexity of the calculate method (allowing the mflops evaluation)
  60. *** name() : this method returns the name of the action (std::string)
  61. ****** Interface concept : This is a class or namespace defining how to use a given library and
  62. its specific containers (matrix and vector). Up to now an interface should following types
  63. *** real_type : kind of float to be used (float or double)
  64. *** stl_vector : must correspond to std::vector<real_type>
  65. *** stl_matrix : must correspond to std::vector<stl_vector>
  66. *** gene_vector : the vector type for this interface --> e.g. (real_type *) for the C_interface
  67. *** gene_matrix : the matrix type for this interface --> e.g. (gene_vector *) for the C_interface
  68. + the following common methods
  69. *** free_matrix(gene_matrix & A, int N) dealocation of a N sized gene_matrix A
  70. *** free_vector(gene_vector & B) dealocation of a N sized gene_vector B
  71. *** matrix_from_stl(gene_matrix & A, stl_matrix & A_stl) copy the content of an stl_matrix A_stl into a gene_matrix A.
  72. The allocation of A is done in this function.
  73. *** vector_to_stl(gene_vector & B, stl_vector & B_stl) copy the content of an stl_vector B_stl into a gene_vector B.
  74. The allocation of B is done in this function.
  75. *** matrix_to_stl(gene_matrix & A, stl_matrix & A_stl) copy the content of an gene_matrix A into an stl_matrix A_stl.
  76. The size of A_STL must corresponds to the size of A.
  77. *** vector_to_stl(gene_vector & A, stl_vector & A_stl) copy the content of an gene_vector A into an stl_vector A_stl.
  78. The size of B_STL must corresponds to the size of B.
  79. *** copy_matrix(gene_matrix & source, gene_matrix & cible, int N) : copy the content of source in cible. Both source
  80. and cible must be sized NxN.
  81. *** copy_vector(gene_vector & source, gene_vector & cible, int N) : copy the content of source in cible. Both source
  82. and cible must be sized N.
  83. and the following method corresponding to the action one wants to be benchmarked :
  84. *** matrix_vector_product(const gene_matrix & A, const gene_vector & B, gene_vector & X, int N)
  85. *** matrix_matrix_product(const gene_matrix & A, const gene_matrix & B, gene_matrix & X, int N)
  86. *** ata_product(const gene_matrix & A, gene_matrix & X, int N)
  87. *** aat_product(const gene_matrix & A, gene_matrix & X, int N)
  88. *** axpy(real coef, const gene_vector & X, gene_vector & Y, int N)
  89. The bench algorithm (generic_bench/bench.hh) is templated with an action itself templated with
  90. an interface. A typical main.cpp source stored in a given library directory libs/A_LIB
  91. looks like :
  92. bench< AN_ACTION < AN_INTERFACE > >( 10 , 1000 , 50 ) ;
  93. this function will produce XY data file containing measured mflops as a function of the size for 50
  94. sizes between 10 and 10000.
  95. This algorithm can be adapted by providing a given Perf_Analyzer object which determines how the time
  96. measurements must be done. For example, the X86_Perf_Analyzer use the asm rdtsc function and provides
  97. a very fast and accurate (but less portable) timing method. The default is the Portable_Perf_Analyzer
  98. so
  99. bench< AN_ACTION < AN_INTERFACE > >( 10 , 1000 , 50 ) ;
  100. is equivalent to
  101. bench< Portable_Perf_Analyzer,AN_ACTION < AN_INTERFACE > >( 10 , 1000 , 50 ) ;
  102. If your system supports it we suggest to use a mixed implementation (X86_perf_Analyzer+Portable_Perf_Analyzer).
  103. replace
  104. bench<Portable_Perf_Analyzer,Action>(size_min,size_max,nb_point);
  105. with
  106. bench<Mixed_Perf_Analyzer,Action>(size_min,size_max,nb_point);
  107. in generic/bench.hh
  108. .