At 2013-08-09 10:20:46,"Tobias Grosser" <tobias@grosser.es> wrote:>On 08/08/2013 06:27 PM, Star Tan wrote:<br>>> At 2013-08-08 22:28:33,"Tobias Grosser" <tobias@grosser.es> wrote:<br>>>> On 08/08/2013 01:29 AM, Star Tan wrote:<br>>>>> Hi all,<br>>>>><br>>>>><br>>>>> I have summarized the top 10 compiler passes for Polly when compiling LLVM test-ssuite. Results can be viewed on:<br>>>>>       https://gist.github.com/tanstar/581bcea1e4e03498f935/raw/f6a4ec4e8565f7a7bbdb924cd59fcf145caac039/Polly-top10<br>>>>><br>>>>><br>>>>> Based on the comparison between "clang -O3" and "polly -O3" listed on:<br>>>>>       http://188.40.87.11:8000/db_default/v4/nts/18?compare_to=14&baseline=14<br>>>><br>>>> Please compare against clang -O3 -load LLVMPolly.so, otherwise<br>>>> especially the compile time of the small binaries includes the overhead<br>>>> of loading the Polly shared object file.<br>>><br>>> In fact, the compile-time overhead of loading Polly shared object file is very small (usually less than 1%). Their overhead can be viewed on:<br>>>      http://188.40.87.11:8000/db_default/v4/nts/15?compare_to=14&baseline=14<br>><br>>I see. Still, I think we should eliminate to remove another source of noise.<br><br>Got it.  The comparison between Polly and "clang -O3 -load LLVMPolly.so" can be viewed on:<br>   http://188.40.87.11:8000/db_default/v4/nts/18?compare_to=15&baseline=15<br><br>><br>>>>> diff --git a/lib/Analysis/Dependences.cpp b/lib/Analysis/Dependences.cpp index 9f918f3..39c3fb6 100644 --- a/lib/Analysis/Dependences.cpp +++ b/lib/Analysis/Dependences.cpp @@ -95,6 +95,10 @@ void Dependences::calculateDependences(Scop &S) { collectInfo(S, &Read, &Write, &MayWrite, &Schedule); + Read = isl_union_map_coalesce(Read); + Write = isl_union_map_coalesce(Write); + MayWrite = isl_union_map_coalesce(MayWrite); + DEBUG(dbgs() << "Read: " << Read << "\n"<br>>>><br>>>> This patch is unreadable in the mail. However, the one you submitted<br>>>> looked good and was committed.<br>>>><br>>>>> With this patch file, we can reduce the compile-time percentage of PollyDependence from 98.5% to 15.3%. Unfortunately, the compile-time percentage of PollyDependence for benchmarks, such as "nestedloop", is still very high.<br>>>><br>>>> It would be good to get an up-to-date comparison with the latest patch<br>>>> having gone into Polly.<br>>><br>>> Yes, you can view the comparison on:<br>>>      http://188.40.87.11:8000/db_default/v4/nts/26?compare_to=25&baseline=25<br>><br>>I am slightly confused. What are we comparing here? It seems we compare <br>>a PollyScopInfo run with a PollyDependences run (same source code?) and <br>>the Dependences run shows compile time speedup over ScopInfo? This is <br>>surprising.<br><br>In fact, there are three runs:<br><br>pollyOpt (run id = 18): the baseline of Polly <br>pollyScopInfo (run id = 25): Polly with the ScopInfo patch r187728 that split start value from SCEVAddRecExpr<br>pollyDependence (run id = 26): Polly with both ScopInfo patch r187728 and PollyDependence patch r187981 that simplify the Read/Write/MayWrite before feeding them into ISL.<br><br>As a result, I compare pollyDependence (run id = 26) with pollyScopInfo (run id = 25) to see the impact of our ScopDependence patch r187981.  Their only difference is the ScopDependence patch file.<br><br>Of course, you can view the total performance improvements of ScopInfo patch and PollyDependence patch on:<br>      http://188.40.87.11:8000/db_default/v4/nts/26?compare_to=18&baseline=18<br><br>><br>>The numbers rather suggest that those are two Dependences runs the first <br>>without the patch applied the second with. If this is the case,<br>>why does the page say "*** WARNING ***: comparison is against a <br>>different machine (pollyScopInfo__clang_DEV__x86_64,11)"?<br><br>LNT always report warning if you compare two runs with different tester names.<br><br>>> Results show that this patch file is very effective for several benchmarks, such as salsa20 (reduced by 97.72%), Obsequi (54.62%), seidel-2d (48.64%), telecomm-gsm (33.71%).<br>>><br>>>> I did not yet look at the nestedloop benchmark, but it sounds basically<br>>>> like a benchmark only consisting of loop nests that we can optimise.<br>>>> This is definitely interesting to look into. Both in respect of how fast<br>>>> we can analyse it faster, but also if we are able to improve the<br>>>> performance of the generated code. Especially if we improve the<br>>>> execution performance some additional compile time is justified.<br>>><br>>> Yes. nestedloop.c is a very simple benchmark that contains a single nested loop as follows:<br>>>      int n = ((argc == 2) ? atoi(argv[1]) : LENGTH);<br>>>      int a, b, c, d, e, f, x=0;<br>>>      for (a=0; a<n; a++)<br>>>          for (b=0; b<n; b++)<br>>>              for (c=0; c<n; c++)<br>>>                  for (d=0; d<n; d++)<br>>>                      for (e=0; e<n; e++)<br>>>                          for (f=0; f<n; f++)<br>>>                              x++;<br>>> Polly would significantly increases the compile-time from 0.0320s to 2.3320 (70x), but it also reduces the execution time from 0.048s to 0.004s (12x). Maybe it is worth, but I think that would be eif we can reduce the compile-time without hurting the execution performance.<br>><br>>Sure. Any ideas what is going on here? It seems you have a couple of <br>>open problems. It probably makes sense to open a bug report for each of <br>>them and attach source code as well as your findings there.<br><br>I see. I would report some bugs soon.<br><br>><br>>Cheers,<br>>Tobias<br><br>Thanks,<br>Star Tan