[sac-user] sac2c -mt

Juhasz David juhda at inf.elte.hu
Wed Jun 1 20:05:43 BST 2011


Hi,

Thanks for all the advices. Eventually, I chose the PAPI timer and made a 
SaC module to use it instead of gettime(). I performed the benchmarks 
again concentrating on sizes 100, 500 and 1000. The interesting case was 
the second one, where there is a peak in run times about 16 threads. 
Therefore I did another run respect to this size increasing the number of 
worker threads one by one. This measurement was repeatedly performed, and 
the peak was always there. I don't know whether what cause the issue... 
The new graphs are on bottom of the usual page. ( 
http://people.inf.elte.hu/juhda/misc/melanie/matmult.html )

The blocking pragma is an interesting and markedly useful feature, but 
unfortunately nowadays I have no time to deal with it in detail.

David


On Tue, 31 May 2011, Scholz, Sven-Bodo wrote:

> David,
> 
> you may further improve your code by adding a blocking pragma.
> Here, you find our results as well as the source codes we used:
> 
> https://unibench.sac-home.org/?page=benchmark_suites&filterId=132
> 
> There are several graphs on top of the page which compare speedups 
> and runtimes for various shapes and pairs of languages.
> 
> We also have created another approach for measuring using functions
> on objects to prevent the compiler from shifting code around. It is timer
> based and, thus, potentially flawed as Bob points correctly out.
> However, my experience is that IF you can scale your problem to 
> achieve long enough overall runtimes you can get some reasonable results.
> 
> HTH
>   Bodo
> 
> 
> 
> On 30 May 2011, at 12:57, Juhasz David wrote:
> 
> > Hi Clemens,
> > 
> > Thanks the quick reply. After I've added specialization directives to the 
> > program, the run-time measurements indicate real speed-up. Furthermore the 
> > gap between set-notation and with-loop implementation is dissipated, even 
> > in case of 1 thread. I've made the graphs of new measurements available on 
> > the bottom of page 
> > http://people.inf.elte.hu/juhda/misc/melanie/matmult.html
> > 
> > I think, in real world problems, when run-time specialization can take 
> > effect, this implementation of the compiler is viable even without 
> > explicit specializations.
> > 
> > Best,
> > David
> > 
> > On Sun, 29 May 2011, Clemens Grelck wrote:
> > 
> >> Hi David,
> >> 
> >> You actually hit a kind of black hole in the implementation of multithreading.
> >> The reason why the predicate below yields false is simply that the predicate
> >> has not yet been implemented, whereas anything else in the compiler is ready
> >> to deal with your case.
> >> 
> >> There is, however, a simple workaround to the problem: You only need to make
> >> the compiler somehow aware of the shape of the matrices involved. This can be
> >> done in either of two ways: you create the argument matrices such that the
> >> compiler is aware of their shape. Or you use a specialisation directive like
> >> 
> >>  specialize matMult( double[100,100], double[100,100]);
> >> 
> >> anywhere in your code. You can use multiple such directives for the same
> >> function
> >> of course. Your implementations of matMult may stay shape-generic as they are.
> >> The availability of this simple work-around has lowered the urgency of this
> >> problem, but your example shows that I need to do something about it.
> >> 
> >> Cheers,
> >>  Clemens
> >> 
> >> P.S.: Please, share your new measurements with us.
> >> 
> >> 
> >> 
> >> Juhasz David wrote:
> >>> Hi SaC experts,
> >>> 
> >>> I implemented matrix multiplication in 4 different ways (set-notation,
> >>> explicit with-loops and each with transponsing the RHS matrix before the
> >>> multiplication), and runned the compiled multithreaded binaries with various
> >>> numbers of worker threads, up to 32, on a 48-cores system. The surprising
> >>> observation was that the more worker threads started, the more wall clock
> >>> time consumed to do the multiplication. My source codes of the
> >>> multiplication and graphs of the runtime results are available on page:
> >>> http://people.inf.elte.hu/juhda/misc/melanie/matmult.html
> >>> 
> >>> Thereafter I examined the C-code generated by sac2c, and found the
> >>> data-parallel sections in it. Each of these sections is in a conditional
> >>> statement and the then-branch contains the SPMD implementation, the
> >>> else-branch is the sequential one. The condition itself is a variable, which
> >>> is defined just before the if statement by macro
> >>> SAC_ND_PRF_RUNMT_GENARRAY__DATA. However this macro sets the variable to 0,
> >>> thus always the sequential implementation will be executed. I would like to
> >>> ask why this is the case?
> >>> 
> >>> Best regards,
> >>> David
> >>> _______________________________________________
> >>> sac-user mailing list
> >>> sac-user at sac-home.org
> >>> http://lists.sac-home.org/mailman/listinfo.cgi/sac-user
> >> 
> >> -- 
> >> ----------------------------------------------------------------------
> >> Dr Clemens Grelck                                     Science Park 904
> >> Universitair Docent                                  1098 XH Amsterdam
> >>                                                             Nederland
> >> Universiteit van Amsterdam
> >> Instituut voor Informatica                       T +31 (0) 20 525 8683
> >>                                                 F +31 (0) 20 525 7490
> >> Office C3.105                               www.science.uva.nl/~grelck
> >> ----------------------------------------------------------------------
> >> _______________________________________________
> >> sac-user mailing list
> >> sac-user at sac-home.org
> >> http://lists.sac-home.org/mailman/listinfo.cgi/sac-user
> >> 
> >> 
> > _______________________________________________
> > sac-user mailing list
> > sac-user at sac-home.org
> > http://lists.sac-home.org/mailman/listinfo.cgi/sac-user
> 
> _______________________________________________
> sac-user mailing list
> sac-user at sac-home.org
> http://lists.sac-home.org/mailman/listinfo.cgi/sac-user
> 


More information about the sac-user mailing list