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
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
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
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
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
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
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
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
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
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 --
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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)
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
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
28 matches
Mail list logo