search for: gramschmidt

On Fri, Oct 14, 2016 at 6:10 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> polybench/linear-algebra/kernels/symm, FP_ABSTOLERANCE=1e1 >> polybench/linear-algebra/solvers/gramschmidt, FP_ABSTOLERANCE=1e0 >> What should be a good relative tolerance to set for these two tests? > > What's the minimum relative tolerance that you need for them to pass? Setting FP_ABSTOLERANCE=1e-5, the two tests are passing when compiled with -Ofast for the following relative tolera...

...differ more than" " FP_ABSTOLERANCE = %lf\n", i, j, V1, i, j, V2, AbsTolerance); return 0; } Do you want me to add the relative tolerance for the 2 tests? polybench/linear-algebra/kernels/symm, FP_ABSTOLERANCE=1e1 polybench/linear-algebra/solvers/gramschmidt, FP_ABSTOLERANCE=1e0 What should be a good relative tolerance to set for these two tests? Here is the code to compute the relative tolerance from fpcmp: // Check to see if these are inside the absolute tolerance if (AbsTolerance < fabs(V1-V2)) { // Nope, check the relative tolerance......

...nsures we do not calculate nan values, which are linear-algebra/kernels/cholesky/cholesky.c: LLVM: This change ensures we do not calculate nan values, which are linear-algebra/kernels/trisolv/trisolv.c: LLVM: This change ensures we do not calculate nan values, which are linear-algebra/solvers/gramschmidt/gramschmidt.c: LLVM: This change ensures we do not calculate nan values, which are linear-algebra/solvers/lu/lu.c: LLVM: This change ensures we do not calculate nan values, which are

...Pop <sebpop.llvm at gmail.com> wrote: >> Setting FP_ABSTOLERANCE=1e-5, the two tests are passing >> when compiled with -Ofast for the following relative tolerance: >> >> polybench/linear-algebra/kernels/symm, FP_TOLERANCE=1e-10 >> polybench/linear-algebra/solvers/gramschmidt, FP_TOLERANCE=1e5 > > I'm confused. Is this 1e-5 or 1e5? The test passes for a relative tolerance of 100,000.

...enables -ffast-math, which can legitimately cause differences. > The following tests pass at "-O3" and "-O3 -ffp-contract=on" compared with FP_ABSTOLERANCE=1e-5 against "-O0 -ffp-contract=off": polybench/linear-algebra/kernels/symm polybench/linear-algebra/solvers/gramschmidt polybench/stencils/seidel-2d The output of these 3 tests from "-O0 -ffp-contract=off" also matches the reference output. The following 2 tests still require increased FP_ABSTOLERANCE to pass compare between "-O3", "-O3 -ffp-contract=on" vs. "-O0 -ffp-contract=of...

Dear List, I'm trying to draw vector in XYZ with rgl under use of a cylinder3d. Therefore I scale and rotate a basis-cylinder). However, somehow the rotation is wrong as verified by overplotting arrow3d(). Where is my mistake? library(heplots) library(rgl) # ... 2 vectors data=data.frame(row.names=c('X','Y','Z'), x1=c(2,1,5),y=c(4,3,2))

On 12 October 2016 at 05:35, Sebastian Pop <sebpop.llvm at gmail.com> wrote: > polybench/linear-algebra/solvers/gramschmidt/ exposes the same problems as symm. > It does not match the reference output at -O0 -ffp-contract=off, > and it only passes all elements comparisons for FP_ABSTOLERANCE=1 for > "-Ofast" vs. "-O0 -ffp-contract=off". I think we're going about this in a completely wro...

...802 | 1.944 | 2.0% | 147.3% | | correlation.c | 0.782 | 0.792 | 2.005 | 1.3% | 156.4% | | gesummv.c | 0.583 | 0.603 | 1.08 | 3.4% | 85.2% | | ludcmp.c | 0.787 | 0.806 | 2.475 | 2.4% | 214.5% | | 3mm.c | 0.786 | 0.811 | 2.617 | 3.2% | 233.0% | | covariance.c | 0.73 | 0.74 | 2.294 | 1.4% | 214.2% | | gramschmidt.c | 0.63 | 0.643 | 1.134 | 2.1% | 80.0% | | seidel.c | 0.632 | 0.645 | 2.036 | 2.1% | 222.2% | | adi.c | 0.8 | 0.811 | 3.044 | 1.4% | 280.5% | | doitgen.c | 0.742 | 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%...

...> | correlation.c | 0.782 | 0.792 | 2.005 | 1.3% | 156.4% | > | gesummv.c | 0.583 | 0.603 | 1.08 | 3.4% | 85.2% | > | ludcmp.c | 0.787 | 0.806 | 2.475 | 2.4% | 214.5% | > | 3mm.c | 0.786 | 0.811 | 2.617 | 3.2% | 233.0% | > | covariance.c | 0.73 | 0.74 | 2.294 | 1.4% | 214.2% | > | gramschmidt.c | 0.63 | 0.643 | 1.134 | 2.1% | 80.0% | > | seidel.c | 0.632 | 0.645 | 2.036 | 2.1% | 222.2% | > | adi.c | 0.8 | 0.811 | 3.044 | 1.4% | 280.5% | > | doitgen.c | 0.742 | 0.752 | 2.32 | 1.3% | 212.7% | > | instrument.c | 0.445 | 0.45 | 0.495 | 1.1% | 11.2% | It is interesting to see th...

On 12 October 2016 at 13:04, Sebastian Pop <sebpop.llvm at gmail.com> wrote: > The other problem is the reference output does not match > at "-O0 -ffp-contract=off". It might be that the reference output was recorded > at "-O3 -ffp-contract=off". I think that this hides either a compiler > bug or a test bug. Ah, yes! You mentioned before and I forgot to

On 12 October 2016 at 14:26, Sebastian Pop <sebpop.llvm at gmail.com> wrote: > Correct me if I misunderstood: you would be ok changing the > reference output to exactly match the output of "-O0 -ffp-contract=off". No, that's not at all what I said. Matching identical outputs to FP tests makes no sense because there's *always* an error bar. The output of O0, O1, O2,

----- Original Message ----- > From: "Renato Golin" <renato.golin at linaro.org> > To: "Sebastian Pop" <sebpop.llvm at gmail.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "Sebastian Paul Pop" <s.pop at samsung.com>, "llvm-dev" <llvm-dev at lists.llvm.org>, > "Matthias Braun" <matze at

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".

On 14 October 2016 at 15:50, Sebastian Pop <sebpop.llvm at gmail.com> wrote: > These 3 tests are passing with the following configurations: > -O3 -ffp-contract=off > -O3 -ffp-contract=on > -O0 -ffp-contract=off > -O0 -ffp-contract=on > > They are not passing at: > -Ofast -ffp-contract=on > -Ofast -ffp-contract=off Let's separate completely FP-contract and

...| 0.782 | 0.792 | 2.005 | 1.3% | 156.4% | >> | gesummv.c | 0.583 | 0.603 | 1.08 | 3.4% | 85.2% | >> | ludcmp.c | 0.787 | 0.806 | 2.475 | 2.4% | 214.5% | >> | 3mm.c | 0.786 | 0.811 | 2.617 | 3.2% | 233.0% | >> | covariance.c | 0.73 | 0.74 | 2.294 | 1.4% | 214.2% | >> | gramschmidt.c | 0.63 | 0.643 | 1.134 | 2.1% | 80.0% | >> | seidel.c | 0.632 | 0.645 | 2.036 | 2.1% | 222.2% | >> | adi.c | 0.8 | 0.811 | 3.044 | 1.4% | 280.5% | >> | doitgen.c | 0.742 | 0.752 | 2.32 | 1.3% | 212.7% | >> | instrument.c | 0.445 | 0.45 | 0.495 | 1.1% | 11.2% | > >It...

...the full set of results for the A53 machine in question with a baseline (r292491) before this patch and current (r292522) : > http://llvm.org/perf/db_default/v4/nts/107364 <http://llvm.org/perf/db_default/v4/nts/107364> > > If these are reliable results, we have 2 perf wins (puzzle, gramschmidt) on the A53 machine. How do we determine the importance of the sieve benchmark vs. the rest of the suite? > > An x86 machine doesn't show any regressions from this change: > http://llvm.org/perf/db_default/v4/nts/107353 <http://llvm.org/perf/db_default/v4/nts/107353> > >...

On Wed, Oct 12, 2016 at 10:28 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Renato Golin" <renato.golin at linaro.org> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: "Sebastian Paul Pop" <s.pop at samsung.com>, "llvm-dev" <llvm-dev at lists.llvm.org>, "Matthias

...this commit. I'm new to using the LNT site, but this should be the full set of results for the A53 machine in question with a baseline (r292491) before this patch and current (r292522) : http://llvm.org/perf/db_default/v4/nts/107364 If these are reliable results, we have 2 perf wins (puzzle, gramschmidt) on the A53 machine. How do we determine the importance of the sieve benchmark vs. the rest of the suite? An x86 machine doesn't show any regressions from this change: http://llvm.org/perf/db_default/v4/nts/107353 Are there target-scope-based guidelines for when something is bad enough to reve...

...3 0.1462 > 0.6299 0.9155 0.00% 9.35% 371.13% 584.74% adi.c 0.1593 > 0.1621 0.1835 1.4375 1.849 1.76% 15.19% 802.39% 1060.70% > correlation.c 0.1579 0.1596 0.1802 0.3393 0.6337 1.08% 14.12% > 114.88% 301.33% gemm.c 0.1407 0.1432 0.1576 0.2421 0.4477 > 1.78% 12.01% 72.07% 218.20% gramschmidt.c 0.1331 0.1349 0.1509 > 0.3069 0.4138 0.00% 13.37% 130.58% 210.89% lu.c 0.1419 > 0.1443 0.1581 0.3156 0.3943 1.69% 11.42% 122.41% 177.87% average > 1.26% 13.22% 248.47% 393.80% To improve readability, it may be worth ensuring this fits into 80 columns. You may be able to reduce the...

> On Jan 23, 2017, at 3:48 PM, Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > All targets are likely affected in some way by the icmp+shl fold introduced with r292492. It's a basic pattern that occurs in lots of code. Did you see any perf wins on your targets with this commit? > > Sadly, it is also likely that many (all?) targets are negatively