From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13441 invoked by alias); 17 Feb 2010 22:49:36 -0000 Received: (qmail 13427 invoked by uid 22791); 17 Feb 2010 22:49:34 -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; Wed, 17 Feb 2010 22:49:19 +0000 Received: from mailrelay2.lanl.gov (mailrelay2.lanl.gov [128.165.4.103]) by proofpoint1.lanl.gov (8.14.3/8.14.3) with ESMTP id o1HMmsov014905 for ; Wed, 17 Feb 2010 15:49:16 -0700 Received: from alvie-mail.lanl.gov (alvie-mail.lanl.gov [128.165.4.110]) by mailrelay2.lanl.gov (Postfix) with ESMTP id 94AEC15FB31A for ; Wed, 17 Feb 2010 15:47:26 -0700 (MST) Received: from localhost (localhost.localdomain [127.0.0.1]) by alvie-mail.lanl.gov (Postfix) with ESMTP id 91A377D0044 for ; Wed, 17 Feb 2010 15:47:26 -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 8058F7D0042 for ; Wed, 17 Feb 2010 15:47:26 -0700 (MST) Subject: Re: libflame version 4.0 announced From: Gerard Jungman To: GSL Discuss Mailing List In-Reply-To: <87aav7r2u4.wl%bjg@network-theory.co.uk> References: <4B3F0184.2030505@iki.fi> <1266363451.8015.153.camel@manticore.lanl.gov> <87aav7r2u4.wl%bjg@network-theory.co.uk> Content-Type: text/plain Date: Wed, 17 Feb 2010 22:49:00 -0000 Message-Id: <1266446869.8015.201.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-02-17_15:2010-02-06,2010-02-17,2010-02-17 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/msg00024.txt.bz2 On Wed, 2010-02-17 at 21:04 +0000, Brian Gough wrote: > > The problems below are all fixable I am sure. Sure, they're fixable, but the question is by whom. I'm trying to chart a specific course for integration. I assume we don't want to touch (fork) their code base; that's to be avoided at almost all costs. I just want to link against it, presumably through some GSL-owned insulation layer, which can be configured to point to any conforming implementation. Similar to the BLAS wrapper layer. But this requires some kind of interface design. With BLAS we were lucky that a standard C interface existed already. But it's not so clear what a "standard" LAPACK interface would look like. It's very nice that they have gifted us with their implementation and their interfaces for a model. But it doesn't leave us entirely off the hook. The other big problem is what to do with their data structures. Obviously we need an insulation layer to protect clients from changes in FLA_Obj and friends. Here are some problems to be solved: (1) Explicitly specify the data layout for buffers of underlying types. There is presumably only one reasonable way to do this, but we should be sure not to paint ourselves into a corner in some initially unforeseen way. Understand how it fits into a larger scheme involving multiarrays, etc. Make sure that it makes sense _across_ language barriers. This includes things like the complex types. What is our philosophy about packing complex types and can we make it language-neutral? Is this a solved problem yet? (2) Decide how to map (semantically and syntactically) the FLAME picture of metadata to/from anything else we might want to expose. Do we compose our metadata objects from theirs (bad insulation?)? Do we transform representations on the fly (performance penalties?)? Is metadata hidden behind functional interfaces (performance again?)? Or is it exposed (as documented struct elements for example)? I am perfectly happy to accept their definitions for the abstract metadata. It's good to have a document (FLAME manual) that lays it all out explicitly. But there is still stuff to do. (3) Design an access scheme that makes sense, i.e. no awful element-wise '_get' and '_set' functions. Make sure that GSL clients have full and free access to the data buffer, so that it can be manipulated directly, passed to external functions for element-wise processing, etc. Make sure that other GSL components that expect globs of data are friendly to these buffers and to the metadata that may be needed to guide access to these buffers. Also make sure no heap-centric-isms creep in. These are only some things to think about. Of course, I have some (very preliminary) opinions, but that's for later discussions. -- G. Jungman