From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2693 invoked by alias); 7 Jan 2010 13:22:11 -0000 Received: (qmail 2679 invoked by uid 22791); 7 Jan 2010 13:22:09 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail.phy.duke.edu (HELO mail.phy.duke.edu) (152.3.182.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 07 Jan 2010 13:22:05 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.phy.duke.edu (Postfix) with ESMTP id 43DF6780B6; Thu, 7 Jan 2010 08:21:57 -0500 (EST) Received: from mail.phy.duke.edu ([127.0.0.1]) by localhost (mail.phy.duke.edu [127.0.0.1]) (amavisd-new, port 10026) with LMTP id njFDx2ywjGEf; Thu, 7 Jan 2010 08:21:57 -0500 (EST) Received: from [192.168.0.38] (cpe-024-211-252-244.nc.res.rr.com [24.211.252.244]) by mail.phy.duke.edu (Postfix) with ESMTP id 1DF53780B5; Thu, 7 Jan 2010 08:21:57 -0500 (EST) Date: Thu, 07 Jan 2010 13:22:00 -0000 From: "Robert G. Brown" To: Rhys Ulerich cc: gsl-discuss@sourceware.org Subject: Re: gsl container designs In-Reply-To: <4a00655d1001062146g555fd9dfh1e333613d8e3b463@mail.gmail.com> Message-ID: References: <1259110486.3028.69.camel@manticore.lanl.gov> <4B4477B8.50305@iki.fi> <1262829020.27244.361.camel@manticore.lanl.gov> <4a00655d1001062110m139c0a8tf2eae7de67da8f6f@mail.gmail.com> <4a00655d1001062146g555fd9dfh1e333613d8e3b463@mail.gmail.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-2049685901-1262870523=:2256" Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org X-SW-Source: 2010-q1/txt/msg00008.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-2049685901-1262870523=:2256 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Content-length: 1755 On Wed, 6 Jan 2010, Rhys Ulerich wrote: >> I recall from my benchmarking days that -- depending on compiler -- >> there is a small dereferencing penalty for packed matrices (vectors >> packed into dereferencing **..* pointers) compared to doing the offset >> arithmetic via brute force inline or via a macro. >> ...... >> I haven't >> run the benchmark recently and don't know how large it currently is.  It >> was never so large that it stopped me from using repacked pointers for >> code clarity.. > > Mostly unscientific, but worth tossing into the mix: > > Using Intel 10.1 compilers on a fairly recent AMD chip, 100,000 iterations > of doing the nested pointers approach is neck-and-neck with index arithmetic > on a 10x10 double matrix.  For the 100x100 case it takes 1.3 times longer > to iterate using the nested pointers.  Work in the inner loop "compute > kernel" is > *= against a constant scalar.  Optimization flags on -O3.  I've seen similar > behavior on recent GNU compilers. That sounds partly like a cache effect -- 10x10 almost certainly stays in L1, 100x100 won't fit. My own experience is similar, although I don't recall the multiplier being as large as 1.3 (but then, I was doing stream and stream-like tests with very large vectors, which means that one spends more time in a vector streaming mode and minimizes cache-thrashing when turning corners). And my memory could be faulty -- I'm an old guy, after all, early Alzheimers...;-) rgb > > I'm happy to provide the test code if anyone's interested. > > - Rhys > Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu --8323328-2049685901-1262870523=:2256--