Q: PARSEC does not build on my system. What do I have to do?

A: First, make sure that your build configuration correctly specifies which
compilers, arguments and other build tools to use. If you still get errors you
should expect to fix those yourself. We did a lot of testing to make minimize
the number of problems but every system is different. A large number of people
use PARSEC, please understand that we can't offer any support. If you identify
and fix any problems on your platform then please consider sending us a patch.
Alternatively, you can also use our precompiled binaries if they are available
for your platform.


Q: I use my simulator to simulate to first x billion instructions of a PARSEC
benchmark, but the characteristics I get are very different from the ones
reported for the workload. What's going on?

A: Don't do that! You will get wrong results. Most workloads have multiple
computational phases with different characteristics. In most cases simply
simulating the first x billion instructions will not reach all these phases,
so your measurements will not capture the full range of behavior of the
benchmark. Even in very simple cases where the workload has only one
computational phase, you might run into the issue that simulating an
insufficient number of instructions will give you incorrect results because
certain effects such as reuse of data in large caches only show up during
later stages of the program. Sampling is a better solution to get accurate
results without having to simulate the full program (see other questions).


Q: My simulator takes way too long to run the PARSEC benchmarks with input
simsmall / simmedium / simlarge. Can't you make it smaller?

A: Unfortunately that isn't possible. The problem is that reducing the amount
of computation for an input also usually scales down the working set sizes and
the amount of parallelism available. A program needs to touch all data in a
working set at least once for it to get loaded into the cache, which means that
the computational complexity grows at least linearly with the working set sizes.
In other words, scaling up the working set sizes of a workload from 1 MB to 100
MB will typically increase the computational demands by at least two orders of
magnitude. We already took advantage of all possible ways to minimize run time
without distorting the characteristics too much when we created the simulation
inputs. If you are constrained by simulation time then you might want to
consider sampling (see other questions).


Q: I don't get good speedups for the PARSEC workloads on my machine. Why?

A: You probably use the simulation inputs and measure the execution time of the
whole program. You should only measure the execution time of the Region-of-
Interest (ROI) instead. The simulation inputs have a significantly reduced
parallel phase that exaggerates the proportions of the serial initialization
and shutdown phase. This causes an artificial reduction of the achievable
speedup due to Amdahl's Law. The inflation of the initialization and shutdown
phase relative to the size of the parallel phase is a scaling artifact that
should be compensated for.


Q: I would like to measure speedups or characteristics using the entire
execution time of the workloads, not just the Region-of-Interest. What can I do?

A: You should use the native inputs for that. They provide input data more
similar to real program problem sizes so that the serial initialization and
shutdown phases of the program don't matter, at least as long as you don't run
performance experiments with very large numbers of cores.


Q: Which simulators can I use with PARSEC?

A: PARSEC is simulator-agnostic, which means that you can use it with everything
that is able to execute or interpret binaries. That includes real machines as
well as all types of simulators or hardware emulators.


Q: Which simulators do you recommend?

A: We don't give recommendations for simulators because it really depends on
the individual requirements what makes sense. There is no one-size-fits-all
simulator. However, we do recommend to use the bigger simulation inputs for
your experiments, which means you will have to use something that is very, very
fast. We know of three methods that are feasible for that:

a) Native execution

This method runs the programs directly on real machines. Measurements can be
obtained with profiling, performance counters or a similar method.

b) Less detailed simulation / emulation

This approach sacrifices accuracy for speed. There are a number of tools which
are able to run binaries only a little slower than a real machine.

c) Cycle-accurate simulation with sampling

This type of simulators uses a method known as sampling which simulates only
a small subset of the whole instruction stream. The simulator is able to
identify which parts of the program need to be simulated in detail and which
parts can be skipped. By simulating only the necessary program parts very high
simulation speeds can be achieved without sacrificing much accuracy. Sampling
can reduce simulation time by several orders of magnitude.

Unfortunately the majority of detailed simulators does not support sampling,
but there are some which already implement this method.


Q: When I try to build PARSEC on Sparc + Solaris I get an error message which
says that there are only 32 registers. The error message looks about as follows:

/var/tmp/cc6dYs2Q.s: Assembler messages:
/var/tmp/cc6dYs2Q.s:165: Error: Illegal operands: There are only 32 
single precision f registers; [0-31]
/var/tmp/cc6dYs2Q.s:187: Error: Illegal operands: There are only 32 
single precision f registers; [0-31]
/var/tmp/cc6dYs2Q.s:203: Error: Illegal operands: There are only 32 
single precision f registers; [0-31]
/var/tmp/cc6dYs2Q.s:1591: Error: Illegal operands: There are only
32 single precision f registers; [0-31]
/var/tmp/cc6dYs2Q.s:1605: Error: Illegal operands: There are only
32 single precision f registers; [0-31]
...

A: You are using a broken version of the GNU binutils assembler as. You need
to install a new version of the GNU binutils and recompile gcc so that it uses
the assembler of the new binutils version. Unfortunately the current versions of
the binutils of the popular SFW consolidation project is affected by this. The
assembler and linker of the GNU binutils version 2.18 and 2.19.51 worked fine
for us, but 2.19.51 has a buggy version of ar and ranlib (see next question).


Q: When I try to build PARSEC on Sparc + Solaris I get an error message which
says that one of the static libraries is not a valid archive. The error message
looks about as follows:

mklib: Making SunOS static library:  libGL.a
gar: /home/cbienia/parsec-2.0/pkgs/libs/mesa/obj/sparc-solaris.gcc/src/mesa/libmesa.a is not a valid archive
 x - api_arrayelt.o
 x - api_loopback.o
 x - api_noop.o
 x - api_validate.o
gmake[4]: *** [../../../../lib/libGL.a] Error 1

A: You are using a broken version of the GNU ar, ranlib and strip utility. You
need to install a different version of the GNU binutils and update your PARSEC
build configuration so that the new tools are used. Unfortunately the latest
version of the GNU binutils is affected by this. Use an older version instead.
The binutils version currently distributed by the SFW consolidation project
(version 2.15) work, as does version 2.18. Simply edit your build configuration
and update the variables AR, RANLIB and STRIP so they point to the desired
binaries.


Q: When I try to build PARSEC on Sparc + Solaris I get an error from the linker
which says that the `-R' flag is unknown.

A: You are using the Sun linker which is incompatible with some of the build
systems of some PARSEC packages. We recommend to use the linker of the GNU
binutils instead. You need to rebuild your compiler to change the linker.


Q: I have trouble compiling gcc on Sparc + Solaris. How can I get a working
version of gcc?

A: You need a reasonably recent version of gcc to build PARSEC (at least version
4.2). The gcc binaries installed by default and currently available from the SFW
consolidation project are too old. We recommend to build your own version of
gcc, which can be a little tricky. There are reports that the most up to date
versions of gcc do not compile on Solaris. We were successful with gcc 4.2.1.

You need to build gcc in a directory that is different from the source tree, and
you must provide a few flags pointing the build system to the correct versions
of the GNU assembler and linker distributed with the GNU binutils. The following
configuration line worked for us:

../gcc-4.2.1/configure --with-gnu-as --with-as=/usr/local/binutils-2.18/bin/as --with-gnu-ld --with-ld=/usr/local/binutils-2.18/bin/ld --enable-shared --prefix=/usr/local/gcc-4.2.1 --enable-languages=c,c++

Then run GNU make to build gcc. It is usually called `gmake' on Solaris. Please
notice that the assembler and linker of some versions of the GNU binutils is
broken (see other questions). The ones that come with GNU binutils version
2.18 and 2.19.51 worked on our Solaris machine, but you might have to build them
yourself.


Q: If I try to build the GNU binutils on Sparc + Solaris I get errors which say
that __FILE_OFFSET_BITS is being redefined. How can I get the binutils to
compile?

A: The easiest solution is to simply undefine the macro before it is defined
again. To do that simply insert an `#undef __FILE_OFFSET_BITS' just before the
location that causes the error.