search for: gemver

Hi, I have just tagged 3.7.1-rc1, so it is ready for testing. As a reminder, when doing regression testing, use the 3.7.0 release as your baseline. Thanks, Tom

...0.162 | 1.839 | 0.6% | 1042.2% | This number looks also fishy. In debug mode you reported for Polly-optimize 1.327 seconds. This is again faster than in release mode. > | jacobi-2d-imper.c | 0.16 | 0.161 | 0.649 | 0.6% | 305.6% | > | bicg.c | 0.149 | 0.152 | 0.444 | 2.0% | 198.0% | > | gemver.c | 0.135 | 0.136 | 0.416 | 0.7% | 208.1% | > | lu.c | 0.143 | 0.148 | 0.398 | 3.5% | 178.3% | > | Average | | | | 2.20% | 362.15% | Otherwise, those numbers look like a good start. Maybe you can put them on some website/wiki/document where you can extend them as you proceed with benchmarki...

...| 0.298 | 3.2% | 140.3% | | intrument.c | 0.149 | 0.151 | 0.837 | 1.3% | 461.7% | | atax.c | 0.135 | 0.136 | 0.917 | 0.7% | 579.3% | | gemm.c | 0.161 | 0.162 | 1.839 | 0.6% | 1042.2% | | jacobi-2d-imper.c | 0.16 | 0.161 | 0.649 | 0.6% | 305.6% | | bicg.c | 0.149 | 0.152 | 0.444 | 2.0% | 198.0% | | gemver.c | 0.135 | 0.136 | 0.416 | 0.7% | 208.1% | | lu.c | 0.143 | 0.148 | 0.398 | 3.5% | 178.3% | | Average | | | | 2.20% | 362.15% | Table 2: Compiling time overhead of Polly for Mediabench (Selected from LLVM-testsuite). | | Clang (econd) | Polly-load (econd) | Polly-optimize (econd) | Polly-load pen...

Dear Tobias Grosser, Thank you so much for your kind reply. Your advice is very helpful and inspiring. At 2013-03-18 20:40:50,"Tobias Grosser" <tobias at grosser.es> wrote: >On 03/17/2013 11:54 PM, Star Tan wrote: >> Hello Tobi, >> >> I am interested in Polly project. Polly seems to be a very promising tool to find out program parallelization based on LLVM

...0.162 | 1.839 | 0.6% | 1042.2% | This number looks also fishy. In debug mode you reported for Polly-optimize 1.327 seconds. This is again faster than in release mode. > | jacobi-2d-imper.c | 0.16 | 0.161 | 0.649 | 0.6% | 305.6% | > | bicg.c | 0.149 | 0.152 | 0.444 | 2.0% | 198.0% | > | gemver.c | 0.135 | 0.136 | 0.416 | 0.7% | 208.1% | > | lu.c | 0.143 | 0.148 | 0.398 | 3.5% | 178.3% | > | Average | | | | 2.20% | 362.15% | Otherwise, those numbers look like a good start. Maybe you can put them on some website/wiki/document where you can extend them as you proceed with benchmarki...

...ng pBasic pNoOpt pNoGen pOPt pBasic% pNoGen% > pNoOpt% pOpt% 2mm.c 0.1521 0.1593 0.1711 0.3235 0.7247 > 4.73% 12.49% 112.69% 376.46% atax.c 0.1386 0.1349 0.1449 > 0.2066 0.313 0.00% 0.00% 49.06% 125.83% covariance.c 0.1498 > 0.1517 0.1526 0.3561 0.7706 1.27% 1.87% 137.72% 414.42% gemver.c > 0.1562 0.1587 0.1724 0.2674 0.3936 1.60% 10.37% 71.19% 151.99% > instrument.c 0.1062 0.1075 0.1124 0.123 0.1216 0.00% 5.84% > 15.82% 14.50% ludcmp.c 0.157 0.1602 0.2002 1.0761 1.3175 2.04% > 27.52% 585.41% 739.17% 3mm.c 0.1529 0.1559 0.1826 0.4134 > 1.0436 1.96% 19.42% 170.37%...

...0933424| 0|0.287682162| -0.42| 1690933424| 0| |SingleSource/Benchmarks/Polybench/linear-algebra/kernels/doitgen/doitgen.test | 75|0.445250085| 3399897372|0.446000827| -0.17| 3399897368| 0|0.446003224| -0.17| 3399897368| 0| |SingleSource/Benchmarks/Polybench/linear-algebra/kernels/gemver/gemver.test | 72|0.476362624| 714917745|0.479692636| -0.69| 714917750| 0|0.475910147| 0.1| 714917746| 0| |SingleSource/Benchmarks/Polybench/linear-algebra/kernels/gesummv/gesummv.test | 146|0.201739334| 480454033|0.201744234| 0| 480454024| 0|0.201747124| 0| 480454...

Hi all, I have updated my GSoS proposal: "FastPolly: Reducing LLVM-Polly Compiling overhead" (https://gist.github.com/tanstar/5441808). I think the pass ordering problem you discussed early can be also investigated in this project! Is there any comment or advice about my proposal? I appreciate all your help and advice. Thanks, Star Tan Proposal:

Hi all, I've started looking at the GlobalMerge pass, enabled by default on ARM and AArch64. I think we should reconsider that, at least for AArch64. As is, the pass just merges all globals together, in groups of 4KB (AArch64, 128B on ARM). At the time it was enabled, the general thinking was "it's almost free, it doesn't affect performance much, we might as well use it".

...| 0.752 | 2.32 | 1.3% | 212.7% | | instrument.c | 0.445 | 0.45 | 0.495 | 1.1% | 11.2% | | atax.c | 0.614 | 0.627 | 1.007 | 2.1% | 64.0% | | gemm.c | 0.721 | 0.74 | 1.327 | 2.6% | 84.0% | | jacobi-2d-imper.c | 0.721 | 0.735 | 2.211 | 1.9% | 206.7% | | bicg.c | 0.577 | 0.597 | 1.01 | 3.5% | 75.0% | | gemver.c | 0.799 | 0.857 | 1.296 | 7.3% | 62.2% | | lu.c | 0.68 | 0.702 | 1.132 | 3.2% | 66.5% | | Average | | | | 2.49% | 142.10% | Experimental results show that Polly analysis and optimization can leads to 142% extra compiling overhead, which maybe unacceptable in many large software building. As a re...

Hi Stepan, Sorry for the delay. It's great that you are working on MergeFunctions as well and I agree, we should definitely try to combine our efforts to improve MergeFunctions. Just to give you some context, the pass (with the similar function merging patch) is already being used in a production setting. From my point of view, it would be better if we focus on improving its capability

...622 0 0.01 85607 0 0.01 85607 garage.ll 25 32013 0 0.01 31982 0 0.01 31982 gasp.ll 6 51262 0 0.01 51232 0 0.01 51232 gcc-loops.ll 99 215027 3 0.02 214260 3 0.03 214260 gdevmem.ll 27 181881 0 0.02 181857 0 0.03 179175 gdevs.ll 1 1879 0 0.01 1855 0 0.01 1855 gemm.ll 12 28028 0 0.01 27980 0 0.01 27980 gemver.ll 12 35733 0 0.01 35683 0 0.01 35683 genalign11.ll 3 69116 0 0.01 69101 0 0.02 69101 gen_c.ll 40 303014 2 0.03 297916 2 0.03 283690 gen_cpp.ll 21 186423 3 0.02 172496 3 0.02 172496 gen_cs.ll 13 137612 2 0.02 128367 2 0.02 128367 general.ll 1 2295 0 0.01 2266 0 0.01 2266 genGalign11.ll 3 65594 0 0....