From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11018 invoked by alias); 16 Sep 2009 00:45:45 -0000 Received: (qmail 11010 invoked by uid 22791); 16 Sep 2009 00:45:44 -0000 X-SWARE-Spam-Status: No, hits=-10.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_PASS X-Spam-Check-By: sourceware.org Received: from proofpoint2.lanl.gov (HELO proofpoint2.lanl.gov) (204.121.3.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 Sep 2009 00:45:37 +0000 Received: from mailrelay2.lanl.gov (mailrelay2.lanl.gov [128.165.4.103]) by proofpoint2.lanl.gov (8.14.3/8.14.3) with ESMTP id n8G0jauo001778 for ; Tue, 15 Sep 2009 18:45:36 -0600 Received: from alvie-mail.lanl.gov (alvie-mail.lanl.gov [128.165.4.110]) by mailrelay2.lanl.gov (Postfix) with ESMTP id 2CC1115C9E56 for ; Tue, 15 Sep 2009 18:45:36 -0600 (MDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by alvie-mail.lanl.gov (Postfix) with ESMTP id 2A8827D009D for ; Tue, 15 Sep 2009 18:45:36 -0600 (MDT) 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 1BA567D009C for ; Tue, 15 Sep 2009 18:45:36 -0600 (MDT) Subject: Re: GSL 2.0 roadmap (one man's view) From: Gerard Jungman To: GSL Discuss Mailing List In-Reply-To: References: <48E25CA9.6080306@iki.fi> <490DE4BD.7070907@iki.fi> <497B00F6.2080400@iki.fi> <498727E5.6080407@iki.fi> <49AA9DB5.6030908@iki.fi> <49FB01D1.30000@iki.fi> <4A7ADFDC.9080408@iki.fi> <1251414774.23092.80.camel@manticore.lanl.gov> <1251414939.23092.82.camel@manticore.lanl.gov> Content-Type: text/plain Date: Wed, 16 Sep 2009 00:45:00 -0000 Message-Id: <1253062087.23092.965.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=2009-09-15_11:2009-09-01,2009-09-15,2009-09-15 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: 2009-q3/txt/msg00045.txt.bz2 On Mon, 2009-09-07 at 14:57 +0100, Brian Gough wrote: > > In practice it seems like any solution is going come down to saying > people should use FFTW (or LAPACK) one way or another. Either we > could bundle it, or -- if we don't supply the existing GSL routines -- > they could be forced to install it. Either way it doesn't seem like > the result is actually much different from now. What we type may not be much different. What we say could be quite different. We need to catalog the use cases for these things. It mainly comes down to inter-operability of data structures. In the end, everybody's data structures amount to something plastered over the top of double *, with some meta-information for layout and life-cycle control. This includes things likes the row-major vs column-major distinction, which we should not ignore any longer. But this rapidly turns into a discussion of gsl_vector and friends, which we should save for later. The distinct point is that the GSL stop-gap implementations are hindering us. I have seen benchmark web pages, regarding ffts or linear algebra, where GSL looks like a turd. Well... if the dunce cap fits... > While getting packages via RPM/DEB is typically fine for desktop use, > I think the ease of doing this in the wider world generally is > underestimated: Packages are the best thing to happen in computer organization and configuration ever. Period. But anyway... > Consider an example of targetting an embedded system for > data-collection with an ARM cpu where the vendor provides only an > older version of GCC, without fortran. Based on my experience, this > is a realistic scenario in industry. We could have a poll. How many people reading this mailing list are targeting a platform like this, and how many are sitting in front of a linux box right now, trying to get their crap to work, so that they can get on with life? The fft and linear algebra code need not be sent down the garbage chute. It will be there for fortran-less ARM prisoners. But the rest of us should get something better by default. -- G. Jungman