Hi Eric,
Thanks -- this is very helpful. Before going forward, I have a
question. It sounds as if s...@home is distributing an executable that
statically links the FFT libs. Is that correct? My understanding of the
licensing issues is that if the linking to FFT libs is done dynamically
at run-time on the hosts, rather than statically, then there are no
GPL/non-GPL compatibility issues. In other words, a dynamic executable
of pure-GPL code is allowed to dynamically link at run-time to a
proprietary non-GPL library.
Cheers,
Bruce
On 8/14/09 3:53 AM, Eric J Korpela wrote:
> Hi Bruce,
>
> We do timing tests of several routines in s...@home before choosing
> the one to use. Our timing code is in our subversion repository
> (http://setisvn.ssl.berkeley.edu/) in the seti_boinc/client/vector
> directory if you want to use it.
>
> There may be one hitch, though. You may need to get a non-GPL licence
> for FFTW in order to allow you to also link in IMKL and ACML in the
> same distributed binary. You might want to Matteo ( athena at
> fftw.org ) or Steven ( stevenj at fftw.org ) to see if they have a
> problem with also linking in non-GPL-compatible non-operating-system
> libraries. They might be able to give you a non-GPL license (they
> gave s...@home one before we were open source) or they might allow it
> as long as the rest of your app is GPL compliant. They are sticklers
> on distributing a copy of the GPL and a source offer with the
> binaries, and got on my case at one point about that before we started
> putting the COPYING and COPYRIGHT files in the application.
>
> Because of this linking difficulty we had to put a license exception
> in the s...@home copyright to allow linking non-GPL FFT libraries. A
> GPL without exceptions wouldn't allow the use of proprietary FFT
> libraries. It's annoying but was necessary if we wanted to use FFTW
> while allowing others to use the Intel or AMD libraries...
>
> // In addition, as a special exception, the Regents of the University of
> // California give permission to link the code of this program with libraries
> // that provide specific optimized fast Fourier transform (FFT) functions
> // as an alternative to FFTW and distribute a linked executable and
> // source code. You must obey the GNU General Public License in all
> // respects for all of the code used other than the FFT library itself.
> // Any modification required to support these libraries must be distributed
> // under the terms of this license. If you modify this program, you may
> extend
> // this exception to your version of the program, but you are not obligated to
> // do so. If you do not wish to do so, delete this exception statement from
> // your version. Please be aware that FFTW is not covered by this exception,
> // therefore you may not use FFTW in any derivative work so modified without
> // permission of the authors of FFTW.
>
> Sorry to be the bearer of complexity.
>
> Eric
>
> On Mon, Aug 3, 2009 at 3:39 AM, Bruce Allen<[email protected]> wrote:
>> Dear BOINC devs,
>>
>> For some of the einst...@home code which is FFT-bound, we are going to
>> try the following strategy:
>>
>> (1) Link our application to FFTW, Intel Math Kernel Library (IMKL) and
>> to the AMD Core Math Library (ACML).
>>
>> (2) At app start up, do some timing tests to measure the speed of each
>> different library. We have a fixed data size.
>>
>> (3) Dynamically use the library which is tested as the fastest on the
>> host machine.
>>
>> I have two questions:
>>
>> (A) Has someone else already tried this approach?
>>
>> (B) Is anyone currently redistributing the ACML or IMKL with their
>> application? If so, did you sign a licensing agreement like this:
>>
>> http://developer.amd.com/cpu/Libraries/acml/redistribution/Pages/default.aspx
>>
>> Cheers,
>> Bruce
>>
>>
>>
>> _______________________________________________
>> boinc_dev mailing list
>> [email protected]
>> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
>> To unsubscribe, visit the above URL and
>> (near bottom of page) enter your email address.
>>
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.