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

Christian Bienia cbienia at CS.Princeton.EDU
Wed Mar 4 20:42:37 EST 2009


Hi Guoqiang,

 

As of now no bugs have been reported for these programs in PARSEC 2.0. I
always try to verify and upload all patches to the PARSEC Wiki and announce
it on parsec-users as soon as possible.

 

Dedup and freqmine have pretty large working sets, so they have to run
somewhat longer than the other workloads with smaller working sets.

 

Best,

Chris

 

 

From: parsec-users-bounces at lists.cs.princeton.edu
[mailto:parsec-users-bounces at lists.cs.princeton.edu] On Behalf Of Guoqiang
Yang
Sent: Wednesday, March 04, 2009 8:30 PM
To: parsec-users at lists.cs.princeton.edu
Subject: Re: [parsec-users] parsec-users Digest, Vol 15, Issue 1

 

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/bbde078f/attachment.html>


More information about the parsec-users mailing list