[parsec-users] 答复: parsec on sparc patch (except ferret, facesim and vips)

Qingyuan Deng ddqqyy at gmail.com
Wed Jul 23 21:13:46 EDT 2008


Hi Huan,

Acctually I am studying the communication among threads of those
applications. So I just tested them on my desktop which is a 2-core P4 SMP
machine. And I use Pin to count the instructions. Another method is to
"time" the execution while varying the thread number, and I found Canneal
running much faster with more threads. But it doesn't make sense because
there are only 2 cores in the machine. So I doubt this may be one reason
which cause the superlinear speed-up which you mentioned before.

Regards,
Qingyuan

2008/7/23 Huan Fang <huanf at kth.se>:

>
> Hi Qingyuan,
>
> May I know what machine are you running on (how many cores are there)? And
> how do you count the number of instructions.
>
>
> Regards,
> Huan
>  ------------------------------
> *发件人:* parsec-users-bounces at lists.cs.princeton.edu [
> parsec-users-bounces at lists.cs.princeton.edu] 代表 Qingyuan Deng [
> ddqqyy at gmail.com]
> *发送时间:* 2008年7月23日 12:14
> *收件人:* PARSEC Users
> *主题:* Re: [parsec-users] parsec on sparc patch (except ferret, facesim and
> vips)
>
>   Thanks Chris, I test the Canneal on my real machine several times by
> specifying the thread number ranging from 2 to 128, and found everytime the
> total instruction count decreases when the thread number becomes bigger. I
> am not so sure what is the condition on other machines but I doubt this may
> be one reason which causes the superlinear speedup of this application other
> than the cache efficiency. Is that possible?
> Qingyuan
>
>
> 2008/7/22 Christian Bienia <cbienia at cs.princeton.edu>:
>
>>  Hi Qingyuan,
>>
>>
>>
>> Canneal runs until the design converges. The required instructions for
>> that might slightly vary if you use more than one thread. If this is not
>> desired, you can change the termination condition of the main loop so that a
>> fixed number of iterations will be used.
>>
>>
>>
>> - Chris
>>
>>
>>
>>
>>
>> *From:* parsec-users-bounces at lists.cs.princeton.edu [mailto:
>> parsec-users-bounces at lists.cs.princeton.edu] *On Behalf Of *Qingyuan Deng
>> *Sent:* Tuesday, July 22, 2008 2:43 AM
>>
>> *To:* PARSEC Users
>> *Subject:* Re: [parsec-users] parsec on sparc patch (except ferret,
>> facesim and vips)
>>
>>
>>
>> Hi All,
>> I found the instruction # of Canneal decreases while # of threads
>> increase. I am not so familiar with the characteristics of simulated
>> annealing(SA) algorithm. Anybody got idea why this happens?
>> Thanks,
>> Qingyuan
>>
>> 2008/7/12 major <mbb45 at cornell.edu>:
>>
>> I tested canneal (via the provided patch) on a SPARC SUN Niagara 8-core
>> machine and it exhibited horrible sub-linear speedups going from 1-8 cores.
>>
>> Without modeling memory, probably avoiding the largest bottleneck for this
>> benchmark.
>>
>> -Major
>>
>> Huan Fang wrote:
>>
>> Hi Chiris B,
>>
>> Thank you as well. Actually I didn't run the patch provided by Chris F,
>> but modified a few lines of atomic.h and AtomicPtr.h as the patch does. It
>> must have fixed the issue of alignment you mentioned before.
>>
>> The speedup test is achieved in Simics without any cache model(like ruby).
>> I remember the Simics does not model cache hierarchies by default. My
>> guess is that this kind of simplification of Simics make it even better
>> than real machines. However, canneal is the only one which has superlinear
>> speedup I have found so far. I will keep finding the reason.
>>
>> Thanks again
>>
>> Regards,
>> Huan
>>
>>
>>
>> Hi Huan,
>>
>> I'm not the Chris who submitted the patch, but I have an idea. (Chris F.
>> from Cambridge submitted the patch. I'm Chris B.)
>>
>> The superlinear speedup is most likely caused by better cache efficiency.
>> I
>> haven't looked at the patch in enough detail, but canneal is severely
>> memory
>> bound. The slightest improvement here will make the program run a lot
>> faster.
>>
>> Is your Solaris machine an SMP box? In that case the cache capacity grows
>> linearly with the number of processors (as compared to a CMP, where it
>> remains constant). That could be a reason for the improvement.
>>
>> - Chris
>>
>>
>>
>> -----Original Message-----
>> From: parsec-users-bounces at lists.cs.princeton.edu
>> [mailto:parsec-users-bounces at lists.cs.princeton.edu] On Behalf Of Huan
>> Fang
>> Sent: Tuesday, July 08, 2008 10:17 AM
>> To: PARSEC Users
>> Subject: Re: [parsec-users] parsec on sparc patch (except ferret, facesim
>> and vips)
>>
>> Hi Chris,
>>
>>
>> Many thanks to your patch, canneal can now run without any problems on
>> solaris/sparc.
>> The weird thing is I got a speedup even better than the ideal one.
>> i.e.  4.6x  on 4cpus,
>> 24.4x on 16cpus. I used Simics for simulation.
>>
>> Can anyone explain that?
>>
>> Regards,
>> Huan
>>
>>
>> Hi all,
>>
>>   I compiled a patch that hopefully should allow you to compile parsec
>> on
>>      a Sparc/Solaris 10 box. A few notes on my build environment: Solaris
>> 10
>> 5/08, gcc 4.2.3, and binutils 2.18. binutils 2.15 that ships with
>> Solaris
>> 10 have a funny version of AS, that refuses to compile perfectly legal
>> opcodes and I think there was also an ld issue. The patch is configured
>> to
>>      use parsec hooks with simics magic instructions.
>>
>> You can get the patch from:
>> http://www.cl.cam.ac.uk/~cf309/parsec_sparc.patch.bz2<http://www.cl.cam.ac.uk/%7Ecf309/parsec_sparc.patch.bz2>
>>
>> A few notes on the patch. I added a global definition BIG_ENDIAN_MACHINE
>> to trigger endianess swap in affected benchmarks. No effort has been
>> made
>> to bind a thread to a particular CPU. As for dedup, the output is saved
>> in
>>      big endian and as such different from output computed on an x86 box.
>> The
>> patch adds a configuration gcc-sparc, so you can use parsecmgmt to
>> compile
>>      the benchmarks as usual.
>>
>> As for the remaining benchmarks, I have vips and facesim running. But...
>>
>> vips produces output that is too different to say that it is just an
>> endianess issue.
>>
>> facesim runs only if I use a really nasty hack. I don't feel comfortable
>> of releasing this to public.
>>
>> as for ferret, I am still at a complete loss. It compiles, but then just
>> hangs...
>>
>> If you have any questions feel free to contact me.
>>
>> Cheers
>>
>>   Chris
>> _______________________________________________
>> parsec-users mailing list
>> parsec-users at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/parsec-users
>>
>>
>>
>> _______________________________________________
>> parsec-users mailing list
>> parsec-users at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/parsec-users
>>
>> _______________________________________________
>> parsec-users mailing list
>> parsec-users at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/parsec-users
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> parsec-users mailing list
>> parsec-users at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/parsec-users
>>
>>
>>
>> _______________________________________________
>> parsec-users mailing list
>> parsec-users at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/parsec-users
>>
>>
>>
>> _______________________________________________
>> parsec-users mailing list
>> parsec-users at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/parsec-users
>>
>>
>
> _______________________________________________
> parsec-users mailing list
> parsec-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/parsec-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/parsec-users/attachments/20080724/657ccb3e/attachment-0001.html>


More information about the parsec-users mailing list