Re: [Cython] Fwd: Re: [Numpy-discussion] Proposed Roadmap Overview
On 21 February 2012 04:42, Robert Bradshaw wrote:
> Python bytecode -> LLVM is a great idea for creating ufuncs, the
> overhead of Cython + GCC is atrocious for stuff like this. (I think
> Cython could make a good frontent as well, especially if we generated
> just the .c code for the function rather than a full extension module
> and used a good compiler to generate machine code in-memory
> on-the-fly.)
I want elementwise functions and reductions for Cython as well, but
they would be specialized according to the types you use them for, so
it wouldn't be atrocious bloat (at least, no more then you'd already
be having).
I've been giving profile guided optimizations some thoughts as well, I
think they are most neatly handled through a python tracer that is
installed e.g. through sitecustomize which collects data about types,
time spent in which code regions etc during testing and development.
You can then tell Cython to compile the module, so e.g. if it
registered "a numpy array" it could generate some specializations for
dtypes either statically or dynamically through OpenCL. The
alternative approach using code instrumentation would be more of a
chore but would work just as well for Cython code with object-typed
arguments. That's all rather far off, and this looks like an
interesting development.
> Going too deeply though and you'll be starting to duplicate the work
> of Unladen Swallow...
>
> On Mon, Feb 20, 2012 at 8:09 PM, Dag Sverre Seljebotn
> wrote:
>> This has got to be the most incredible and interesting turn of events I've
>> seen in a while! :-)
>>
>> Dag
>>
>> Original Message
>> Subject: Re: [Numpy-discussion] Proposed Roadmap Overview
>> Date: Mon, 20 Feb 2012 22:04:00 -0600
>> From: Travis Oliphant
>> Reply-To: Discussion of Numerical Python
>> To: Discussion of Numerical Python
>>
>>
>>
>> Interesting you bring this up. I actually have a working prototype of
>> using Python to emit LLVM. I will be showing it at the HPC tutorial that
>> I am giving at PyCon. I will be making this available after PyCon to a
>> wider audience as open source.
>>
>> It uses llvm-py (modified to work with LLVM 3.0) and code I wrote to do
>> the translation from Python byte-code to LLVM. This LLVM can then be
>> "JIT"ed. I have several applications that I would like to use this for.
>> It would be possible to write "more of NumPy" using this approach.
>> Initially, it makes it *very* easy to create a machine-code ufunc from
>> Python code. There are other use-cases of having loops written in Python
>> and plugged in to a calculation, filtering, or indexing framework that
>> this system will be useful for.
>>
>> There is still a need for a core data-type object, a core array object,
>> and a core calculation object. Maybe some-day these cores can be shrunk
>> to a smaller subset and more of something along the lines of LLVM
>> generation from Python can be used. But, there is a lot of work to do
>> before that is possible. But, a lot of the currently pre-compiled loops
>> can be done on the fly instead using this approach. There are several
>> things I'm working on in that direction.
>>
>> This is not PyPy. It certainly uses the same ideas that they are using,
>> but instead it fits into the CPython run-time and doesn't require
>> changing the whole ecosystem. If you are interested in this work let me
>> know. I think I'm going to call the project numpy-llvm, or fast-py, or
>> something like that. It is available on github and will be open source
>> (but it's still under active development).
>>
>> Here is an example of the code to create a ufunc using the system (this
>> is like vectorize, but it creates machine code and by-passes the
>> interpreter and so is 100x faster).
>>
>> from math import sin, pi
>>
>> def sinc(x):
>> if x==0:
>> return 1.0
>> else:
>> return sin(x*pi)/(pi*x)
>>
>> from translate import Translate
>> t = Translate(sinc)
>> t.translate()
>> print t.mod
>>
>> res = t.make_ufunc('sinc')
>>
>>
>> -Travis
>>
>>
>>
>> On Feb 20, 2012, at 10:55 AM, Sturla Molden wrote:
>>
>>> Den 20.02.2012 17:42, skrev Sturla Molden:
There are still other options than C or C++ that are worth considering.
One would be to write NumPy in Python. E.g. we could use LLVM as a
JIT-compiler and produce the performance critical code we need on the
fly.
>>>
>>> LLVM and its C/C++ frontend Clang are BSD licenced. It compiles faster
>>> than GCC and often produces better machine code. They can therefore be
>>> used inside an array library. It would give a faster NumPy, and we could
>>> keep most of it in Python.
>>>
>>> Sturla
>>>
>>> ___
>>> NumPy-Discussion mailing list
>>> numpy-discuss...@scipy.org
>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>>
>> ___
>> cython-devel mailing list
>> cython-devel@python
Re: [Cython] Fwd: Re: [Numpy-discussion] Proposed Roadmap Overview
On Tue, Feb 21, 2012 at 9:19 AM, mark florisson
wrote:
> On 21 February 2012 04:42, Robert Bradshaw
> wrote:
>> Python bytecode -> LLVM is a great idea for creating ufuncs, the
>> overhead of Cython + GCC is atrocious for stuff like this. (I think
>> Cython could make a good frontent as well, especially if we generated
>> just the .c code for the function rather than a full extension module
>> and used a good compiler to generate machine code in-memory
>> on-the-fly.)
>
> I want elementwise functions and reductions for Cython as well, but
> they would be specialized according to the types you use them for, so
> it wouldn't be atrocious bloat (at least, no more then you'd already
> be having).
> I've been giving profile guided optimizations some thoughts as well, I
> think they are most neatly handled through a python tracer that is
> installed e.g. through sitecustomize which collects data about types,
> time spent in which code regions etc during testing and development.
> You can then tell Cython to compile the module, so e.g. if it
> registered "a numpy array" it could generate some specializations for
> dtypes either statically or dynamically through OpenCL. The
> alternative approach using code instrumentation would be more of a
> chore but would work just as well for Cython code with object-typed
> arguments. That's all rather far off, and this looks like an
> interesting development.
One of the reasons JIT compilers can do so well is that they can use
runtime profile information to write specialized code. It'd be great
to be able to incorporate this kind of profiling into a Cython compile
too. One of the big missing features here is a "fallback mode" where
we can insert guards and fall back to generic code if they're not met,
which I think would open us up to a huge number of optimizations
without violating Python semantics.
>> Going too deeply though and you'll be starting to duplicate the work
>> of Unladen Swallow...
>>
>> On Mon, Feb 20, 2012 at 8:09 PM, Dag Sverre Seljebotn
>> wrote:
>>> This has got to be the most incredible and interesting turn of events I've
>>> seen in a while! :-)
>>>
>>> Dag
>>>
>>> Original Message
>>> Subject: Re: [Numpy-discussion] Proposed Roadmap Overview
>>> Date: Mon, 20 Feb 2012 22:04:00 -0600
>>> From: Travis Oliphant
>>> Reply-To: Discussion of Numerical Python
>>> To: Discussion of Numerical Python
>>>
>>>
>>>
>>> Interesting you bring this up. I actually have a working prototype of
>>> using Python to emit LLVM. I will be showing it at the HPC tutorial that
>>> I am giving at PyCon. I will be making this available after PyCon to a
>>> wider audience as open source.
>>>
>>> It uses llvm-py (modified to work with LLVM 3.0) and code I wrote to do
>>> the translation from Python byte-code to LLVM. This LLVM can then be
>>> "JIT"ed. I have several applications that I would like to use this for.
>>> It would be possible to write "more of NumPy" using this approach.
>>> Initially, it makes it *very* easy to create a machine-code ufunc from
>>> Python code. There are other use-cases of having loops written in Python
>>> and plugged in to a calculation, filtering, or indexing framework that
>>> this system will be useful for.
>>>
>>> There is still a need for a core data-type object, a core array object,
>>> and a core calculation object. Maybe some-day these cores can be shrunk
>>> to a smaller subset and more of something along the lines of LLVM
>>> generation from Python can be used. But, there is a lot of work to do
>>> before that is possible. But, a lot of the currently pre-compiled loops
>>> can be done on the fly instead using this approach. There are several
>>> things I'm working on in that direction.
>>>
>>> This is not PyPy. It certainly uses the same ideas that they are using,
>>> but instead it fits into the CPython run-time and doesn't require
>>> changing the whole ecosystem. If you are interested in this work let me
>>> know. I think I'm going to call the project numpy-llvm, or fast-py, or
>>> something like that. It is available on github and will be open source
>>> (but it's still under active development).
>>>
>>> Here is an example of the code to create a ufunc using the system (this
>>> is like vectorize, but it creates machine code and by-passes the
>>> interpreter and so is 100x faster).
>>>
>>> from math import sin, pi
>>>
>>> def sinc(x):
>>> if x==0:
>>> return 1.0
>>> else:
>>> return sin(x*pi)/(pi*x)
>>>
>>> from translate import Translate
>>> t = Translate(sinc)
>>> t.translate()
>>> print t.mod
>>>
>>> res = t.make_ufunc('sinc')
>>>
>>>
>>> -Travis
>>>
>>>
>>>
>>> On Feb 20, 2012, at 10:55 AM, Sturla Molden wrote:
>>>
Den 20.02.2012 17:42, skrev Sturla Molden:
>
> There are still other options than C or C++ that are worth considering.
> One would be to write NumPy in Python. E.g. we could use LLVM as a
> JIT-compiler and produce the performance critical code we need on t
Re: [Cython] star-imports in Cython/Includes/cpython considered harmful
On Mon, Feb 20, 2012 at 12:45 AM, Stefan Behnel wrote: > Hi, > > I just noticed that the star-imports in the cpython package have serious > side effects. The cpython/__init__.pxd file has this in it: > > """ > from cpython.version cimport * > from cpython.ref cimport * > from cpython.exc cimport * > from cpython.module cimport * > from cpython.mem cimport * > ... > """ > > This means that a direct cimport of any of those recursively cimported > names from the cpython package namespace will always trigger a complete > cimport of all cpython.* modules, thus > > 1) wasting compile time Which is still pretty cheap (and should be made extremely cheap for unchanging pxd files). > 2) polluting the cpython package namespace It's neither inspected (by the end user) at runtime, nor in danger of conflicts, so I don't see this as a big deal. "Flat is better than nested." > 3) polluting the internal state of Cython's list of cimported modules This is really (1), other than that it doesn't really hurt to have extra keys in a dict. > 4) leading to things being defined in the generated C code that don't need > to be there, specifically the object structs of PyBoolObject and > PyComplexObject, which we provide definitions for in cpython.bool and > cpython.complex. This is an actual issue that should be fixed, and avoiding emitting unused code is a worthwhile goal in many contexts. > The point where I noticed this is when I got test errors in PyPy because it > doesn't expose the bool/complex structs. That wasn't because the test > actually used them, it was purely because it had this cimport in it: > > from cpython cimport PyObject > > If it had used this instead: > > from cpython.object cimport PyObject > > Cython would still have parsed all of those .pxd files, but at least it > wouldn't have used those declarations to do any harm. > > Now, I'm 100% certain that there is user code out there that does this as > well. Fixing this bug by removing all the star-imports will break that > code, but keeping the cimports in the package will trap the average lazy > user into cimporting stuff from there directly. > > I'll add a big warning to the package for now, but I wonder if we shouldn't > accept breaking this code at some point (and sooner is always better than > later). I actually don't think it's a bad thing to allow people to be "lazy" and import directly from cpython rather than have to hunt down the specific subpackages that things live in. In fact, it's cleaner in some sense to not have to know about the subdivisions of the cpython library. (It's like including "Python.h" rather than all the individual header files.) - Robert ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Fwd: Re: [Numpy-discussion] Proposed Roadmap Overview
On Tue, Feb 21, 2012 at 8:02 PM, Robert Bradshaw wrote: > On Tue, Feb 21, 2012 at 9:19 AM, mark florisson > wrote: >> On 21 February 2012 04:42, Robert Bradshaw >> wrote: >>> Python bytecode -> LLVM is a great idea for creating ufuncs, the >>> overhead of Cython + GCC is atrocious for stuff like this. (I think >>> Cython could make a good frontent as well, especially if we generated >>> just the .c code for the function rather than a full extension module >>> and used a good compiler to generate machine code in-memory >>> on-the-fly.) >> >> I want elementwise functions and reductions for Cython as well, but >> they would be specialized according to the types you use them for, so >> it wouldn't be atrocious bloat (at least, no more then you'd already >> be having). >> I've been giving profile guided optimizations some thoughts as well, I >> think they are most neatly handled through a python tracer that is >> installed e.g. through sitecustomize which collects data about types, >> time spent in which code regions etc during testing and development. >> You can then tell Cython to compile the module, so e.g. if it >> registered "a numpy array" it could generate some specializations for >> dtypes either statically or dynamically through OpenCL. The >> alternative approach using code instrumentation would be more of a >> chore but would work just as well for Cython code with object-typed >> arguments. That's all rather far off, and this looks like an >> interesting development. > > One of the reasons JIT compilers can do so well is that they can use > runtime profile information to write specialized code. It'd be great > to be able to incorporate this kind of profiling into a Cython compile > too. One of the big missing features here is a "fallback mode" where > we can insert guards and fall back to generic code if they're not met, > which I think would open us up to a huge number of optimizations > without violating Python semantics. A really neat first-step would be to write a straight LLVM backend for Cython -- instead of generating code, one could generate equivalent in-memory IR. (The really hacky way to do this would be to throw the output of the current C code generator through Clang.) That seems achievable (at least as pie-in-the-sky projects go), and even if no-one ever got around to adding fancier profile-guided optimizations, it would still be useful. For instance, it would be possible to not just import .pyx modules directly, but reload() them after editing (!!). Or have a cython.inline() function that works like weave.inline, but more awesome. -- Nathaniel ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Fwd: Re: [Numpy-discussion] Proposed Roadmap Overview
On Tue, Feb 21, 2012 at 12:18 PM, Nathaniel Smith wrote: > On Tue, Feb 21, 2012 at 8:02 PM, Robert Bradshaw > wrote: >> On Tue, Feb 21, 2012 at 9:19 AM, mark florisson >> wrote: >>> On 21 February 2012 04:42, Robert Bradshaw >>> wrote: Python bytecode -> LLVM is a great idea for creating ufuncs, the overhead of Cython + GCC is atrocious for stuff like this. (I think Cython could make a good frontent as well, especially if we generated just the .c code for the function rather than a full extension module and used a good compiler to generate machine code in-memory on-the-fly.) >>> >>> I want elementwise functions and reductions for Cython as well, but >>> they would be specialized according to the types you use them for, so >>> it wouldn't be atrocious bloat (at least, no more then you'd already >>> be having). >>> I've been giving profile guided optimizations some thoughts as well, I >>> think they are most neatly handled through a python tracer that is >>> installed e.g. through sitecustomize which collects data about types, >>> time spent in which code regions etc during testing and development. >>> You can then tell Cython to compile the module, so e.g. if it >>> registered "a numpy array" it could generate some specializations for >>> dtypes either statically or dynamically through OpenCL. The >>> alternative approach using code instrumentation would be more of a >>> chore but would work just as well for Cython code with object-typed >>> arguments. That's all rather far off, and this looks like an >>> interesting development. >> >> One of the reasons JIT compilers can do so well is that they can use >> runtime profile information to write specialized code. It'd be great >> to be able to incorporate this kind of profiling into a Cython compile >> too. One of the big missing features here is a "fallback mode" where >> we can insert guards and fall back to generic code if they're not met, >> which I think would open us up to a huge number of optimizations >> without violating Python semantics. > > A really neat first-step would be to write a straight LLVM backend for > Cython -- instead of generating code, one could generate equivalent > in-memory IR. (The really hacky way to do this would be to throw the > output of the current C code generator through Clang.) That seems > achievable (at least as pie-in-the-sky projects go), and even if > no-one ever got around to adding fancier profile-guided optimizations, > it would still be useful. For better or for worse, Python is still pretty tied to C (or C like languages, with higher level concepts like function calls). But spitting out C snippets for Clang to consume would still be cool. > For instance, it would be possible to not > just import .pyx modules directly, but reload() them after editing > (!!). Or have a cython.inline() function that works like weave.inline, > but more awesome. Note that there is a cython.inline: http://wiki.cython.org/enhancements/inline . The compile-time overhead (it creates a full extension module to compile with gcc (but does do caching)) could be greatly improved with something like this. - Robert ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] star-imports in Cython/Includes/cpython considered harmful
Robert Bradshaw, 21.02.2012 21:14: > On Mon, Feb 20, 2012 at 12:45 AM, Stefan Behnel wrote: >> I just noticed that the star-imports in the cpython package have serious >> side effects. The cpython/__init__.pxd file has this in it: >> >> """ >> from cpython.version cimport * >> from cpython.ref cimport * >> from cpython.exc cimport * >> from cpython.module cimport * >> from cpython.mem cimport * >> ... >> """ >> >> This means that a direct cimport of any of those recursively cimported >> names from the cpython package namespace will always trigger a complete >> cimport of all cpython.* modules, thus >> >> 1) wasting compile time > > Which is still pretty cheap (and should be made extremely cheap for > unchanging pxd files). > >> 2) polluting the cpython package namespace > > It's neither inspected (by the end user) at runtime, nor in danger of > conflicts, so I don't see this as a big deal. "Flat is better than > nested." > >> 3) polluting the internal state of Cython's list of cimported modules > > This is really (1), other than that it doesn't really hurt to have > extra keys in a dict. Except when it has side-effects as in 4). If we can figure out what parts of the cimported declarations are actually used, we could still drop unnecessary declarations. But that doesn't currently happen. >> 4) leading to things being defined in the generated C code that don't need >> to be there, specifically the object structs of PyBoolObject and >> PyComplexObject, which we provide definitions for in cpython.bool and >> cpython.complex. > > This is an actual issue that should be fixed, and avoiding emitting > unused code is a worthwhile goal in many contexts. This issue was the reason I brought this up in the first place. >> The point where I noticed this is when I got test errors in PyPy because it >> doesn't expose the bool/complex structs. That wasn't because the test >> actually used them, it was purely because it had this cimport in it: >> >> from cpython cimport PyObject >> >> If it had used this instead: >> >> from cpython.object cimport PyObject >> >> Cython would still have parsed all of those .pxd files, but at least it >> wouldn't have used those declarations to do any harm. >> >> Now, I'm 100% certain that there is user code out there that does this as >> well. Fixing this bug by removing all the star-imports will break that >> code, but keeping the cimports in the package will trap the average lazy >> user into cimporting stuff from there directly. >> >> I'll add a big warning to the package for now, but I wonder if we shouldn't >> accept breaking this code at some point (and sooner is always better than >> later). > > I actually don't think it's a bad thing to allow people to be "lazy" > and import directly from cpython rather than have to hunt down the > specific subpackages that things live in. In fact, it's cleaner in > some sense to not have to know about the subdivisions of the cpython > library. (It's like including "Python.h" rather than all the > individual header files.) As long as it doesn't have side-effects to do this, it's not a problem. And I agree that it's better to actually fix the side-effects. Just not importing from the cpython package doesn't make the problem go away that your code won't compile on PyPy as soon as you cimport anything from cpython.bool or cpython.complex. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
