From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13877 invoked by alias); 20 Sep 2009 16:19:19 -0000 Received: (qmail 13864 invoked by uid 22791); 20 Sep 2009 16:19:17 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,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; Sun, 20 Sep 2009 16:19:13 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.phy.duke.edu (Postfix) with ESMTP id BCC06BEE17; Sun, 20 Sep 2009 12:18:23 -0400 (EDT) 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 hue5kwWChseL; Sun, 20 Sep 2009 12:18:23 -0400 (EDT) Received: from lilith.rgb.private.net (client212-5.dsl.intrex.net [209.42.212.5]) by mail.phy.duke.edu (Postfix) with ESMTP id 16C55BEDA5; Sun, 20 Sep 2009 12:18:23 -0400 (EDT) Date: Sun, 20 Sep 2009 16:19:00 -0000 From: "Robert G. Brown" To: Rhys Ulerich cc: gsl-discuss@sourceware.org Subject: Re: GSL 2.0 roadmap (one man's view) In-Reply-To: <4a00655d0909200830j76902792pf5a9698611743f32@mail.gmail.com> Message-ID: References: <48E25CA9.6080306@iki.fi> <4A7ADFDC.9080408@iki.fi> <1251414774.23092.80.camel@manticore.lanl.gov> <1251414939.23092.82.camel@manticore.lanl.gov> <1253062087.23092.965.camel@manticore.lanl.gov> <4AB5F77F.8020104@iki.fi> <4a00655d0909200830j76902792pf5a9698611743f32@mail.gmail.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: 2009-q3/txt/msg00061.txt.bz2 On Sun, 20 Sep 2009, Rhys Ulerich wrote: >> a) the actual data in any tensor form be stored in a single contiguous >> vector whose address is available to the user and not hidden inside an >> opaque data object; >> b) the tensor itself be a **...*pointer, cast to the desired >> type, packed with the offsets into this vector > > Given both (a) and (b) everyone pays storage overhead for indexing > twice. The first time is to store the leading dimensions for (a)-like > access, and the second time is to store the pointers-to-pointers for > (b)-like access. > > Since (a) already exists today, if you want (b) it can be provided as > a view. Your cost will be storage overhead for pointers-to-pointers, > dereferencing delay, and potential cache misses if the > pointers-to-pointers for (b)-like access are far away from (a)'s data. > > I think those that want (b) should have a view that accomplishes it, > but that people using (a) only shouldn't pay for the overhead. I I agree, which is why I suggest that a) always be directly and simply available for people who are willing to write the somewhat ugly code (or macros) required to dereference without the additional layer of overhead and to facilitate other things such as ODE soolutions. Bear in mind that code performance isn't always the primary issue, even for numerical programs. Sometimes ease of programming and/or debugging are important, or the numerical task takes so little time that nobody cares about the possibly small increase in execution time. The dereferencing code also gets pretty ugly and non-portable for non-rectangular tensors of high rank with indices that don't always start at 0. Even if one's goal is to end up with a fast program with inline dereferencing an minimal indexing overhead, it might well be VERY USEFUL to have a direct and straightforward tensor view of the data vector to use to write an easily debugged version that can in turn be used to debug a fast version. > believe these are the reasons that both the C and Fortran numerics > communities pretty consistently stay towards (a)-like storage under > the covers. > > Also, to be fair to the current design, gsl_matrix and gsl_vector are > structs, but they certainly aren't opaque. And they aren't extensible (or at least extended) to tensors of higher rank. Scalability matters. rgb > > - 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