From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17589 invoked by alias); 8 Jan 2010 20:08:54 -0000 Received: (qmail 17579 invoked by uid 22791); 8 Jan 2010 20:08:53 -0000 X-SWARE-Spam-Status: No, hits=-10.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_PASS X-Spam-Check-By: sourceware.org Received: from proofpoint1.lanl.gov (HELO proofpoint1.lanl.gov) (204.121.3.25) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 08 Jan 2010 20:08:49 +0000 Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by proofpoint1.lanl.gov (8.14.3/8.14.3) with ESMTP id o08K8l1k029115 for ; Fri, 8 Jan 2010 13:08:47 -0700 Received: from alvie-mail.lanl.gov (alvie-mail.lanl.gov [128.165.4.110]) by mailrelay1.lanl.gov (Postfix) with ESMTP id 8AC451C23EA for ; Fri, 8 Jan 2010 13:08:47 -0700 (MST) Received: from localhost (localhost.localdomain [127.0.0.1]) by alvie-mail.lanl.gov (Postfix) with ESMTP id 8922F7D0059 for ; Fri, 8 Jan 2010 13:08:47 -0700 (MST) X-NIE-2-Virus-Scanner: amavisd-new at alvie-mail.lanl.gov Received: from [130.55.124.157] (manticore.lanl.gov [130.55.124.157]) by alvie-mail.lanl.gov (Postfix) with ESMTP id 79F7B7D0054 for ; Fri, 8 Jan 2010 13:08:47 -0700 (MST) Subject: Re: gsl container designs From: Gerard Jungman To: GSL Discuss Mailing List In-Reply-To: References: <1259110486.3028.69.camel@manticore.lanl.gov> <4B4477B8.50305@iki.fi> <1262829020.27244.361.camel@manticore.lanl.gov> Content-Type: text/plain Date: Fri, 08 Jan 2010 20:08:00 -0000 Message-Id: <1262981361.27244.383.camel@manticore.lanl.gov> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5,1.2.40,4.0.166 definitions=2010-01-08_12:2010-01-05,2010-01-08,2010-01-08 signatures=0 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/msg00010.txt.bz2 On Wed, 2010-01-06 at 22:29 -0500, Robert G. Brown wrote: > However, some of my beowulfish friends who work(ed) > for compiler companies argued that one of Fortran's longstanding > advantages in numerical code efficiency is simply because of the fact > that matrices in Fortran are written in stone and so compiler writers > can optimize the hell out of them. C pointers, OTOH -- well, I think the main difference is that fortran can assume no aliasing, which allows some extra optimization that C cannot do. The new 'restrict' keyword is supposed to help with this, but we'll see. > I've written code to do so many times -- Numerical Recipes provides the > basic idea in its matrix-packing routines. Simply allocate e.g. > > double **..*m,*v; I understand the mechanics of it. I'm not sure what my concern was; I thought about this a few months ago and decided there was some semantic problem. But it looks like the **..*m has exactly the same life-cycle and maintenance as *v, so I'm not sure what I was thinking. It might come back to me. > I can probably dig this code out and post it here (or post a link to it) > if you want to look at it. I think I went up to 9 or 10 dimensions (way > more than I needed) and did a lot of things via brute force to make the > purely mechanical recursion obvious; I planned an eventual rewrite into > a more compact form that I never got around to. Sure. Feel free to post it. I like to look at everything and cherry-pick the best parts from other people's stuff. Makes things a lot easier. -- G. Jungman