[parsec-users] parsec-users Digest, Vol 15, Issue 1

Guoqiang Yang nkyangguoqiang at gmail.com
Wed Mar 4 20:30:10 EST 2009

 Hi chris,

Thanks for your quick reply, but I was just wondering why dedup and freqmine
took particularly much longer time than the other benchmarks. By using
sim-large input set, the other benchmarks took at most 4-5 days. But
freqmine takes more than 11 days and is still running...

I am just thinking if there might be some error like deadlock as you
mentioned in version 2.0? Or do you have anyother data that shows freqmine
does take much more time?

Many thanks,

Guoqiang Yang

> ---------- Forwarded message ----------
> From: "Christian Bienia" <cbienia at CS.Princeton.EDU>
> To: "'PARSEC Users'" <parsec-users at lists.cs.princeton.edu>
> Date: Wed, 4 Mar 2009 01:15:26 -0500
> Subject: Re: [parsec-users] question about running dedup and freqmine
> Hello Guaqiang Yang,
> It takes a pretty long time to run the PARSEC benchmarks with the simlarge
> input in a standard cycle-accurate simulator. The fundamental problem is the
> large working sets: Processing time scales at least linearly with the
> working set size because every data item has to be touched at least once.
> That means that as you go from 1 Mb working sets to 100 Mb working sets, you
> should expect an increase in processing time of at least two orders of
> magnitude (often more).
> If you really need large working sets and lots of parallelism for your
> research then you should consider using a very fast simulator. Detailed,
> cycle-accurate simulation is no problem if advanced simulation techniques
> such as sampling are employed. Unfortunately only few simulators support
> sampling yet. Here are a few simulators that might be interesting for you:
> ·         Flexus (http://www.ece.cmu.edu/~simflex/): Uses Simics and the
> SimFlex sampling technology for extremely fast simulation. The speedup over
> conventional simulators is about 3-4 orders of magnitude. That means you can
> run a simulation that would ordinarily take 5.5 days in only 90 seconds. The
> disadvantage is that you need to know a little bit about statistics.
> ·         PTLsim (http://www.ptlsim.org/): Uses a clever trick to simulate
> x86 binaries really fast on x86 processors without significant loss of
> accuracy. The disadvantage is that the binary must match the host platform.
> ·         Pin (http://www.pintool.org/): A tool for dynamic
> instrumentation of programs. Like with PTLsim the binary must match the host
> platform, but Pin is more light-weight and thus faster than PTLsim. The
> disadvantage is that Pin results have only limited accuracy since the binary
> basically runs natively and you just “hook in”.
> No doubt there are more great simulators out there that are really fast AND
> accurate at the same time. I happen to know that there are at least some
> simulators in development that will offer sampling right from the beginning,
> which basically solves the problem. PARSEC itself is simulator-agnostic, so
> we don’t recommend any particular simulator.
> Best,
> Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/parsec-users/attachments/20090304/04ad7948/attachment.html>

More information about the parsec-users mailing list