mirror of
https://github.com/Zenithsiz/ftmemsim-valgrind.git
synced 2026-02-04 02:18:37 +00:00
b05a2a18d7
following improvements: - Arch/OS/platform-specific files are now included/excluded via the preprocessor, rather than via the build system. This is more consistent (we use the pre-processor for small arch/OS/platform-specific chunks within files) and makes the build system much simpler, as the sources for all programs are the same on all platforms. - Vast amounts of cut+paste Makefile.am code has been factored out. If a new platform is implemented, you need to add 11 extra Makefile.am lines. Previously it was over 100 lines. - Vex has been autotoolised. Dependency checking now works in Vex (no more incomplete builds). Parallel builds now also work. --with-vex no longer works; it's little use and a pain to support. VEX/Makefile is still in the Vex repository and gets overwritten at configure-time; it should probably be renamed Makefile-gcc to avoid possible problems, such as accidentally committing a generated Makefile. There's a bunch of hacky copying to deal with the fact that autotools don't handle same-named files in different directories. Julian plans to rename the files to avoid this problem. - Various small Makefile.am things have been made more standard automake style, eg. the use of pkginclude/pkglib prefixes instead of rolling our own. - The existing five top-level Makefile.am include files have been consolidated into three. - Most Makefile.am files now are structured more clearly, with comment headers separating sections, declarations relating to the same things next to each other, better spacing and layout, etc. - Removed the unused exp-ptrcheck/tests/x86 directory. - Renamed some XML files. - Factored out some duplicated dSYM handling code. - Split auxprogs/ into auxprogs/ and mpi/, which allowed the resulting Makefile.am files to be much more standard. - Cleaned up m_coredump by merging a bunch of files that had been overzealously separated. The net result is 630 fewer lines of Makefile.am code, or 897 if you exclude the added Makefile.vex.am, or 997 once the hacky file copying for Vex is removed. And the build system is much simpler. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10364
=============================================================================
Notes about performance benchmarks
=============================================================================
For each benchmark, here is a brief description and notes about its
strengths and weaknesses.
-----------------------------------------------------------------------------
Artificial stress tests
-----------------------------------------------------------------------------
bigcode1, bigcode2:
- Description: Executes a lot of (nonsensical) code.
- Strengths: Demonstrates the cost of translation which is a large part
of runtime, particularly on larger programs.
- Weaknesses: Highly artificial.
heap:
- Description: Does a lot of heap allocation and deallocation, and has a lot
of heap blocks live while doing so.
- Strengths: Stress test for an important sub-system; bug #105039 showed
that inefficiencies in heap allocation can make a big
difference to programs that allocate a lot.
- Weaknesses: Highly artificial -- allocation pattern is not real, and only
a few different size allocations are used.
sarp:
- Description: Does a lot of stack allocation and deallocation.
- Strengths: Tests for a specific performance bug that existed in 3.1.0 and
all earlier versions.
- Weaknesses: Highly artificial.
-----------------------------------------------------------------------------
Real programs
-----------------------------------------------------------------------------
bz2:
- Description: Burrows-Wheeler compression and decompression.
- Strengths: A real, widely used program, very similar to the 256.bzip2
SPEC2000 benchmark. Not dominated by any code, the hottest
55 blocks account for only 90% of execution. Has lots of
short blocks and stresses the memory system hard.
- Weaknesses: None, really, it's a good benchmark.
fbench:
- Description: Does some ray-tracing.
- Strengths: Moderately realistic program.
- Weaknesses: Dominated by sin and cos, which are not widely used, and are
hardware-supported on x86 but not on other platforms such as
PPC.
ffbench:
- Description: Does a Fast Fourier Transform (FFT).
- Strengths: Tests common FP ops (mostly adding and multiplying array
elements), FFT is a very important operation.
- Weaknesses: Dominated by the inner loop, which is quite long and flatters
Valgrind due to the small dispatcher overhead.
tinycc:
- Description: A very small and fast C compiler. A munged version of
Fabrice Bellard's TinyCC compiling itself multiple times.
- Strengths: A real program, lots of code (top 100 blocks only account for
47% of execution), involves large irregular data structures
(presumably, since it's a compiler). Does lots of
malloc/free calls and so changes that make a big improvement
to perf/heap typically cause a small improvement.
- Weaknesses None, really, it's a good benchmark.