about summary refs log tree commit diff
path: root/benchtests
Commit message (Collapse)AuthorAgeFilesLines
* Add benchmark inputs for cos and tanSiddhesh Poyarekar2013-04-177-1/+78
|
* Define NOT_IN_libc when compiling benchmark programsSiddhesh Poyarekar2013-04-161-0/+6
|
* Add target bench-cleanSiddhesh Poyarekar2013-04-161-0/+3
|
* Write to bench.out-tmp only onceSiddhesh Poyarekar2013-04-151-4/+4
| | | | | | | | | | | Appending benchmark program output on every run could result in a case where the benchmark run was cancelled, resulting in a partially written file. This file gets used again on the next run, resulting in results being appended to old results. It could have been possible to remove the file before every benchmark run, but it is easier to just write the output to bench.out-tmp only once.
* Rebuild benchmark sources when Makefile is updatedSiddhesh Poyarekar2013-04-151-1/+3
| | | | | | | | Benchmark programs are generated using parameters from the Makefile, so it is necessary to rebuild them whenever the parameters in the Makefile are updated. Hence, added a dependency for the generated C source on the Makefile so that it gets regenerated when the Makefile is updated.
* Move bench target to benchtestsSiddhesh Poyarekar2013-04-121-0/+34
| | | | The bench target will only be used within the benchtests directory.
* Add benchmark inputs for atanSiddhesh Poyarekar2013-04-034-1/+39
| | | | Add separate inputs for slow and fast paths of atan
* Add benchmark inputs for sinSiddhesh Poyarekar2013-04-024-1/+47
|
* Add benchmark tests for slowpow and slowexpSiddhesh Poyarekar2013-04-027-6/+64
| | | | | | | Separate benchmarks for the fast and slow implementations of pow and exp since measuring both together doesn't make sense. Adjust the iterations for pow and exp accordingly so that they run long enough for the measurements to be meaningful.
* PowerPC: remove branch prediction from rint implementationAdhemerval Zanella2013-04-012-1/+10
| | | | | | | | The branch prediction hints is actually hurts performance in this case. The assembly implementation make two assumptions: 1. 'fabs (x) < 2^52' is unlikely and 2. 'x > 0.0' is unlike (if 1. is true). Since it a general floating point function, expected input is not bounded and then it is better to let the hardware handle the branches.
* Framework for performance benchmarking of functionsSiddhesh Poyarekar2013-03-154-0/+136
See benchtests/Makefile to know how to use it.