Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

2015-09-30 Thread Matthieu Brucher
After, I agree with you. 2015-09-30 18:14 GMT+01:00 Robert Kern : > On Wed, Sep 30, 2015 at 10:35 AM, Matthieu Brucher > wrote: >> >> Yes, obviously, the code has NR parts, so it can't be licensed as BSD >> as it is... > > It's not obvious to

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

2015-09-30 Thread Robert Kern
On Wed, Sep 30, 2015 at 10:35 AM, Matthieu Brucher < matthieu.bruc...@gmail.com> wrote: > > Yes, obviously, the code has NR parts, so it can't be licensed as BSD > as it is... It's not obvious to me, especially after Juha's further clarifications. -- Robert Kern

Re: [Numpy-discussion] Sign of NaN

2015-09-30 Thread Nathaniel Smith
On Tue, Sep 29, 2015 at 2:07 PM, Sebastian Berg wrote: > On Di, 2015-09-29 at 11:16 -0700, Nathaniel Smith wrote: [...] >> In general I'm not a big fan of trying to do all kinds of guessing >> about how to handle random objects in object arrays, the kind that >> ends

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

2015-09-30 Thread Juha Jeronen
Hi, On 30.09.2015 03:48, Chris Barker - NOAA Federal wrote: This sounds pretty cool -- and I've had a use case. So it would be nice to get into Numpy. But: I doubt we'd want OpenMP dependence in Numpy itself. It is indeed a good point not to add new dependencies for a small feature such as

Re: [Numpy-discussion] Sign of NaN

2015-09-30 Thread Sebastian Berg
On Mi, 2015-09-30 at 00:01 -0700, Nathaniel Smith wrote: > On Tue, Sep 29, 2015 at 2:07 PM, Sebastian Berg > wrote: > > On Di, 2015-09-29 at 11:16 -0700, Nathaniel Smith wrote: > [...] > >> In general I'm not a big fan of trying to do all kinds of guessing > >> about

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

2015-09-30 Thread Juha Jeronen
Hi, On 30.09.2015 04:37, Charles R Harris wrote: On Tue, Sep 29, 2015 at 6:48 PM, Chris Barker - NOAA Federal > wrote: This sounds pretty cool -- and I've had a use case. So it would be nice to get into Numpy. But: I doubt

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

2015-09-30 Thread Juha Jeronen
Hi, What qualifies as an NR part? (See my previous message concerning the references; NR is not the only source which has these algorithms. Again, the code itself is original to this solver, I haven't even looked at the code provided with NR.) -J

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

2015-09-30 Thread Pauli Virtanen
Juha Jeronen jyu.fi> writes: > I recently developed a Cython-based, OpenMP-accelerated quartic (and > cubic, quadratic) polynomial solver to address a personal research need > for quickly solving a very large number of independent low-degree > polynomial equations for both real and complex

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

2015-09-30 Thread Daπid
On 30 September 2015 at 10:20, Juha Jeronen wrote: > > Are we putting Cuthon in Numpy now? I lost track. >> > > I thought so? But then again, I'm just a user :) As of this moment, there are three Cython modules in Numpy, so yes. Releases ship the C generated modules, so it

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

2015-09-30 Thread Matthieu Brucher
Yes, obviously, the code has NR parts, so it can't be licensed as BSD as it is... Matthieu 2015-09-30 2:37 GMT+01:00 Charles R Harris : > > > On Tue, Sep 29, 2015 at 6:48 PM, Chris Barker - NOAA Federal > wrote: >> >> This sounds pretty cool --

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

2015-09-30 Thread Juha Jeronen
On 30.09.2015 19:20, Chris Barker wrote: On Wed, Sep 30, 2015 at 6:57 AM, Nathan Goldbaum > wrote: Note however that with the current version of the code, not having OpenMP will severely limit the performance, especially

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

2015-09-30 Thread Juha Jeronen
On 30.09.2015 19:20, Nathaniel Smith wrote: The challenges to providing transparent multithreading in numpy generally are: - gcc + OpenMP on linux still breaks multiprocessing. There's a patch to fix this but they still haven't applied it; alternatively there's a workaround you can use in

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

2015-09-30 Thread Sturla Molden
On 30/09/15 18:20, Chris Barker wrote: We'd need a run-time check. We need to amend the compiler classes in numpy.distutils with OpenMP relevant information (compiler flags and libraries). The OpenMP support libraries must be statically linked. Sturla

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

2015-09-30 Thread Sturla Molden
On 30/09/15 18:20, Chris Barker wrote: python threads with nogil? This is often the easiest, particularly if we construct a fork-safe threadpool. Sturla ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

2015-09-30 Thread Sturla Molden
On 01/10/15 02:20, Juha Jeronen wrote: Then again, the matter is further complicated by considering codes that run on a single machine, versus codes that run on a cluster.Threads being local to each node in a cluster, You can run MPI programs on a single machine and you get OpenMP

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

2015-09-30 Thread Juha Jeronen
On 01.10.2015 01:04, Sturla Molden wrote: There are two principal problems with using OpenMP in NumPy: One is that the GNU OpenMP threadpool is not fork-safe, and can break multiprocessing on some platforms (e.g. when using Python 2.7 on Linux). Anything that uses GCD has this nasty effect on

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

2015-09-30 Thread Sturla Molden
On 30/09/15 11:27, Daπid wrote: Is there a nice way to ship both versions? After all, most implementations of BLAS and friends do spawn OpenMP threads, so I don't think it would be outrageous to take advantage of it in more places; Some do, others don't. ACML uses OpenMP. GotoBLAS uses

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

2015-09-30 Thread Juha Jeronen
On 30.09.2015 13:21, Pauli Virtanen wrote: Juha Jeronen jyu.fi> writes: I recently developed a Cython-based, OpenMP-accelerated quartic (and cubic, quadratic) polynomial solver to address a personal research need for quickly solving a very large number of independent low-degree polynomial

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

2015-09-30 Thread Sturla Molden
On 30/09/15 18:20, Nathaniel Smith wrote: This is incorrect -- the only common implementation of BLAS that uses *OpenMP* threads is OpenBLAS, MKL and ACML also use OpenMP. Sturla ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

2015-09-30 Thread Sturla Molden
On 30/09/15 15:57, Nathan Goldbaum wrote: Basically, just try to compile a simple OpenMP test program in a subprocess. If that succeeds, then great, we can add -fopenmp as a compilation flag. If not, don't do that. Unless you use GCC on Linux, it will be more complex than that. I.e. do you

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

2015-09-30 Thread Sturla Molden
On 01/10/15 02:32, Juha Jeronen wrote: Sounds good. Out of curiosity, are there any standard fork-safe threadpools, or would this imply rolling our own? You have to roll your own. Basically use pthreads_atfork to register a callback that shuts down the threadpool before a fork and another

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

2015-09-30 Thread Nathan Goldbaum
On Wed, Sep 30, 2015 at 3:20 AM, Juha Jeronen wrote: > Hi, > > On 30.09.2015 03:48, Chris Barker - NOAA Federal wrote: > >> This sounds pretty cool -- and I've had a use case. So it would be >> nice to get into Numpy. >> >> But: I doubt we'd want OpenMP dependence in Numpy

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

2015-09-30 Thread Nathaniel Smith
On Sep 30, 2015 2:28 AM, "Daπid" wrote: [...] > Is there a nice way to ship both versions? After all, most implementations of BLAS and friends do spawn OpenMP threads, so I don't think it would be outrageous to take advantage of it in more places; provided there is a nice

Re: [Numpy-discussion] Sign of NaN

2015-09-30 Thread Sebastian Berg
On Mi, 2015-09-30 at 09:11 -0700, Chris Barker wrote: > On Tue, Sep 29, 2015 at 6:35 PM, Charles R Harris > wrote: > For this, and other use-cases, special casing > Numpy arrays stored in object arrays does make >

Re: [Numpy-discussion] composition of the steering council (was Re: Governance model request)

2015-09-30 Thread Chris Barker
On Tue, Sep 29, 2015 at 7:32 AM, Travis Oliphant wrote: > I'm in a situation now where at least for 6 months or so I can help with > NumPy more than I have been able to for 7 years. > great news! > 1) 1 year of inactivity to be removed from the council is too little for a

Re: [Numpy-discussion] Sign of NaN

2015-09-30 Thread Chris Barker
On Tue, Sep 29, 2015 at 6:35 PM, Charles R Harris wrote: > For this, and other use-cases, special casing Numpy arrays stored in >>> object arrays does make sense: >>> >>> "If this is s a Numpy array, pass the operation through." >>> >> >> Because we now (development)

Re: [Numpy-discussion] Sign of NaN

2015-09-30 Thread Chris Barker
On Wed, Sep 30, 2015 at 12:32 AM, Sebastian Berg wrote: > > >> Plus we hope that many use cases for object arrays will soon be > > >> supplanted by better dtype support, so now may not be the best time to > > >> invest heavily in making object arrays complicated and

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

2015-09-30 Thread Chris Barker
On Wed, Sep 30, 2015 at 6:57 AM, Nathan Goldbaum wrote: > Note however that with the current version of the code, not having OpenMP >> will severely limit the performance, especially on quad-core machines, >> since an important factor in the speed comes from the parallel