[eigen] Significant perf regression probably due to bug 363 patches |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: [eigen] Significant perf regression probably due to bug 363 patches*From*: Eamon Nerbonne <eamon@xxxxxxxxxxxx>*Date*: Fri, 4 Nov 2011 10:49:57 +0100*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=KdHdQMVrX3jPTrVYRiCDNKJp3zoJrfTVAcmIDkFK9iw=; b=b5IDcNU0I32lxk1J7PgfodW7NMrpCEXqPKYvlBKxwGVb4RNE0at595QaKrDE3g2uuU dHyb2XWUZn0Yra0I8Yb4L7ppMmc5AJtDltM0WfpAQkNSGrz44EWqHxgZVfWGwv5DqlWg xHEF8VlvBzVJ5YFj9Y4QyrDsFJORqjwmQ9lAA=

On a benchmark I use to check the performance of a simple gradient descent algorithm, I've noticesd large performance degradation over the last month.

NV benchmark results use eigen without vectorization, V results are with vectorization. The timings represent best-of-several runs and exhibit essentially no variation.

Before changeset 4285 (25ba289d5292) Bug 363 - check for integer overflow in byte-size computations:

LvqBenchNV on GCC: 1.22s

LvqBenchV on GCC: 0.991s

LvqBenchNV on MSC: 2.39s

LvqBenchV on MSC: 1.64s

Locally patched with some EIGEN_STRONG_INLINE for MSC; Before changeset 4285 (25ba289d5292) Bug 363 - check for integer overflow in byte-size computations:

LvqBenchNV on GCC: 1.21s

LvqBenchV on GCC: 0.991s

LvqBenchNV on MSC: 1.75s

LvqBenchV on MSC: 1.35s

After changeset 4309 (93b090532ed2) Mention that the axis in AngleAxis have to be normalized.:

LvqBenchNV on GCC: 1.53s

LvqBenchV on GCC: 1.41s

LvqBenchNV on MSC: 2.42s

LvqBenchV on MSC: 1.74s

Locally patched with some EIGEN_STRONG_INLINE for MSC; After changeset 4309 (93b090532ed2) Mention that the axis in AngleAxis have to be normalized.:

LvqBenchNV on GCC: 1.52s

LvqBenchV on GCC: 1.41s

LvqBenchNV on MSC: 1.97s

LvqBenchV on MSC: 1.64s

This represents a 42% slowdown for the fastest gcc (4.6.2 svn) results and a 21% slowdown for the fastest MSC results.

Since the benchmark mostly consists of simple muls and adds on matrices of size Nx1, 2x1, 2x2 and 2xN, each individual operation is just a few floating point operations and thus overhead is very relevant. I'm guessing this is due to the bug 363 related checkins; the extra checking is possibly hamping inlining and possibly just represents a significant number of operations in relation to the otherwise cheap matrix ops. The slow version has the inline for check_rows_cols_for_overflow already, so that's not it.

Perhaps a flag disabling all checking would be nice; especially if there are any other such checks which might be removed...

--eamon@xxxxxxxxxxxx - Tel#:+31-6-15142163

**Follow-Ups**:**Re: [eigen] Significant perf regression probably due to bug 363 patches***From:*Benoit Jacob

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Re: Fwd: Look what i found!!** - Next by Date:
**Re: [eigen] Significant perf regression probably due to bug 363 patches** - Previous by thread:
**Re: [eigen] Re: Fwd: Look what i found!!** - Next by thread:
**Re: [eigen] Significant perf regression probably due to bug 363 patches**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |