[parsec-users] parsec-users Digest, Vol 15, Issue 1
nkyangguoqiang at gmail.com
Wed Mar 4 20:30:10 EST 2009
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?
> ---------- 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the parsec-users