Re: [Cython] About IndexNode and unicode[index]
Robert Bradshaw, 01.03.2013 09:25: > On Thu, Feb 28, 2013 at 10:54 PM, Zaur Shibzukhov wrote: > I think you could even pass in two flags, one for wraparound and one for > boundscheck, and then just evaluate them appropriately in the existing > "if" > tests above. That should allow both features to be supported independently > in a fast way. > Intresting, could C compilers in optimization mode to eliminate unused evaluation path in nested if statements with constant conditional expressions? >>> >>> They'd be worthless if they didn't do that. (Even Cython does it, BTW.) >>> >> Then it can simplify writing utility code in order to support >> different optimization flags in other cases too. > > The one thing you don't have much control over is whether the C > compiler will actually inline the function (CYTHON_INLINE is just a > hint). In particular, it may decide the function is too large to > inline before realizing how small it would become given the constant > arguments. I'm actually not sure how much of a problem this is in > practice... I tried it out for the Get/Set/DelItemInt() utility functions and took a look at the generated assembly (gcc -O3). It does look as expected and sometimes also better than what we currently generate. So I think it's worth it. https://github.com/scoder/cython/commit/cc4f7daec3b1f19b5acaed7766e2b6f86902ad94 I'd be happy if someone else could give this change a review to make sure I got all conditions right. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] About IndexNode and unicode[index]
Stefan Behnel, 28.02.2013 22:16:
> ZS, 28.02.2013 21:07:
>> 2013/2/28 Stefan Behnel:
This allows to write unicode text parsing code almost at C speed
mostly in python (+ .pxd defintions).
>>>
>>> I suggest simply adding a constant flag argument to the existing function
>>> that states if checking should be done or not. Inlining will let the C
>>> compiler drop the corresponding code, which may or may nor make it a little
>>> faster.
>>
>> static inline Py_UCS4 unicode_char2(PyObject* ustring, Py_ssize_t i, int
>> flag) {
>> Py_ssize_t length;
>> #if CYTHON_PEP393_ENABLED
>> if (PyUnicode_READY(ustring) < 0) return (Py_UCS4)-1;
>> #endif
>> if (flag) {
>> length = __Pyx_PyUnicode_GET_LENGTH(ustring);
>> if ((0 <= i) & (i < length)) {
>> return __Pyx_PyUnicode_READ_CHAR(ustring, i);
>> } else if ((-length <= i) & (i < 0)) {
>> return __Pyx_PyUnicode_READ_CHAR(ustring, i + length);
>> } else {
>> PyErr_SetString(PyExc_IndexError, "string index out of range");
>> return (Py_UCS4)-1;
>> }
>> } else {
>> return __Pyx_PyUnicode_READ_CHAR(ustring, i);
>> }
>> }
>
> I think you could even pass in two flags, one for wraparound and one for
> boundscheck, and then just evaluate them appropriately in the existing "if"
> tests above. That should allow both features to be supported independently
> in a fast way.
Done.
https://github.com/scoder/cython/commit/cc4f7daec3b1f19b5acaed7766e2b6f86902ad94
Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] To Add datetime.pxd to cython.cpython
Hi, the last pull request looks good to me now. https://github.com/cython/cython/pull/189 Any more comments on it? Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] About IndexNode and unicode[index]
2013/3/2 Stefan Behnel : >> I think you could even pass in two flags, one for wraparound and one for >> boundscheck, and then just evaluate them appropriately in the existing "if" >> tests above. That should allow both features to be supported independently >> in a fast way. > > https://github.com/scoder/cython/commit/cc4f7daec3b1f19b5acaed7766e2b6f86902ad94 It seems to include the following directive at the beginning of the tests (which tests indices for lists, tuples and unicode): #cython: boundscheck=True #cython: wraparound=True as default mode for testing? -- С уважением, Шибзухов З.М. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] About IndexNode and unicode[index]
Zaur Shibzukhov, 02.03.2013 18:55: > 2013/3/2 Stefan Behnel: >>> I think you could even pass in two flags, one for wraparound and one for >>> boundscheck, and then just evaluate them appropriately in the existing "if" >>> tests above. That should allow both features to be supported independently >>> in a fast way. >> >> https://github.com/scoder/cython/commit/cc4f7daec3b1f19b5acaed7766e2b6f86902ad94 > > It seems to include the following directive at the beginning of the > tests (which tests indices for lists, tuples and unicode): > > #cython: boundscheck=True > #cython: wraparound=True > > as default mode for testing? Yes, although they would appear redundant here. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Py_UNICODE* string support
Hi, Please review my feature proposal to add Py_UNICODE* string support for better Windows interoperability: https://github.com/cython/cython/pull/191 This is motivated by my current work that involves calling lots of Windows APIs. If people are interested I can elaborate on some important points, like the choice of base type (Py_UNICODE vs wchar_t) or the nature of Py_UNICODE* literals or why this feature is necessary at all. Best regards, Nikita Nemkin ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Two minor bugs
On Fri, Mar 1, 2013 at 10:52 PM, Nikita Nemkin wrote: > Hi, > > I'm new to this list and to Cython internals. > > Reporting two recently found bugs: > > 1. Explicit cast fails unexpectedly: > >ctypedef char* LPSTR >cdef LPSTR c_str = b"ascii" >c_str # Failure: Python objects cannot be cast from pointers > of primitive types > >The problem is CTypedefType not delegating can_coerce_to_pyobject() to > the original type. >(because BaseType.can_coerce_to_pyobject takes precedence over > __getattr__). >Patch+test case and attached. Thanks! Applied. >Interestingly, implicit casts use a different code path and are not > affected. > >There is potential for similar bugs in the future, because __getattr__ >delegation is inherently brittle in the presence of the base class > (BaseType). Yes, very true. > 2. This recently added code does not compile with MSVC: > > https://github.com/cython/cython/blob/master/Cython/Utility/TypeConversion.c#L140-142 >Interleaving declarations and statements is not allowed in C90... Fixed https://github.com/cython/cython/commit/24f56e14194e14c706beb6d0ee58a58e77b0b03e - Robert ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Py_UNICODE* string support
Nikita Nemkin, 03.03.2013 08:39: > Please review my feature proposal to add Py_UNICODE* string support > for better Windows interoperability: > https://github.com/cython/cython/pull/191 > > This is motivated by my current work that involves calling lots of Windows > APIs. > > If people are interested I can elaborate on some important points, like > the choice of base type (Py_UNICODE vs wchar_t) or the nature of > Py_UNICODE* literals or why this feature is necessary at all. Are you aware that Py_UNICODE is deprecated as of Py3.3? http://docs.python.org/3.4/c-api/unicode.html Your changes look a bit excessive for supporting something that's inefficient in recent Python versions and basically "dead". Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
