|Re: [eigen] about changeset 6eb14e380|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] about changeset 6eb14e380
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Wed, 18 Aug 2010 11:52:02 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=o8KE+eZ/JyTaCfAIavMxRwEO39EKTgY0Bmxc7KUq9H0=; b=iL4pEwz0x/n/tc523OQdTUqrnktGxb3MPKsle64HiWjsDubEUFT2SBvPtkSt/+S2fZ aG3IfT9Uf4aFglnOVh2HMOjX+Y6wX8cMelvf/rudsK/c+TshGrv1u5HJrXUjvKn9Qkpb AQEjwSSiQITNOo2CcP3a4MdyIRBAvxMp38BLE=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=bBnO0uI15Ce4TmUjdBXlenpKaSE9Ht0ZB32oh5t+ByeAkIgZl8iivliwLw/xmt/TH+ y2k43nPaABtvhCWelYXAhUJQiqAH6mvixqBVvwpajxpJW7ZFSijd7KuYi7aj5JGOct21 ENPL+r1xaVN31zJxW5tauyEFCOvl+SNnzDIak=
2010/8/18 joel falcou <joel.falcou@xxxxxx>
For us it is useful to prevent false sharing on same row/col in openMP scenario.
On 18/08/10 17:21, Benoit Jacob wrote:
I was going to ask about that. Do you think this makes for a significant performance improvement for real-world dynamic-size matrices (size at least 32x32) ?
hm, are you saying that you are aligning each row/col?
if yes, I wonder, because rows/cols are not too relevant to matrix products and other blocked algorithms.
It varies yes. NT2 instalaltion detect it and put it into a NT2_CONFIG_ALIGNMENT macro to be used.
Next question: can't cache line size vary even within a particular architecture? Although that probably doesn't matter since I guess it'll always be bigger than any alignment _requirement_ (it'll be at least 64 bytes, right? which is bigger than any SIMD instructions require, right?)
Ah yes then.
For us too, new simd platform == new compilation, but we support the use case that consists in compiling the same code N times for N different SIMD configs, and switching between these N paths at runtime. This requires Eigen data structures to have the same ABI across different SIMD configs (i.e.. SSE / no SSE), withing a given CPU arch (i.e. x86).
...and for the record, the other big reason: we want to be friendly to linux distros wrt binary libraries using Eigen. if libfoo uses Eigen, and you're a distro packager for x86, you want to ship only 1 package for libfoo. You decide whether you build it with SSE/AVX/nothing. Then You're free to do so because ABI is independent on that. Then app developers/packagers can link against libfoo regardless of how libfoo was built and regardless of their own simd settings. This is basically a requirement in environments, like linux distros, which rely heavily on system-wide shared libraries (rather than app bundles).