On Tue, Nov 3, 2009 at 4:20 PM, Robert Bradshaw <rober...@math.washington.edu> wrote: > On Nov 3, 2009, at 7:08 AM, Lisandro Dalcin wrote: > >> On Tue, Nov 3, 2009 at 12:28 PM, Dag Sverre Seljebotn >> <da...@student.matnat.uio.no> wrote: >>> >>> Stefan Behnel wrote: >>>> >>>> Robert Bradshaw, 03.11.2009 10:22: >>>> >>>>> On Oct 25, 2009, at 11:53 AM, Lisandro Dalcin wrote: >>>>> >>>>>> I think Cython could generate a custom, inline function >>>>>> implementing l.pop([n]) and fast dispatch to it if the object is >>>>>> exactly a list ... >>>>>> >>>>> http://hg.cython.org/cython-devel/rev/2e3dda4a7d23 >>>>> >>>> >>>> Hmm, is this really worth the code duplication with CPython? I mean, we >>>> are >>>> partly copying the list-shrink trigger algorithm here, which I would >>>> prefer >>>> to consider an implementation detail of the list type. >>>> >>> I second this, this is the kind of code I don't like to see Cython >>> output. At the very least, one should #IFDEF it to only kick in with >>> known good Python versions...it's not the kind of thing we'll >>> automatically remember to check when Python 3.4 comes out. > > I concede that we're partially copying the (half-line) list-shrink trigger > algorithm here, but if that changed nothing would break. It's not like we're > using any secret APIs. >
So L->allocated is public API? If you can get rid of that, I think no one would object your patch... >>> It should be possible to find a middle route somewhere though? (At the >>> very least prefetch "pop" of the list type rather than use getattr every >>> time.) >>> >>> Dag Sverre >>> _______________________________________________ >>> Cython-dev mailing list >>> Cython-dev@codespeak.net >>> http://codespeak.net/mailman/listinfo/cython-dev >>> >> >> I agree with Stefan and Dag... > > For the no argument case, there really is hardly any code duplication. Also, > we don't do any reallocation or anything, we just note that if the number of > items get small enough we dispatch to the generic case. I think the > resulting 5x speedup is worth it. > >> Why not use PyList_GET_ITEM(L) + Py_INCREF() + PyList_SetSlice() ?? >> This way, you could easily support "L.pop(index)"... > > Have you seen the code for PyList_SetSlice? It's way more generic (and > complicated) than is needed in this case. And if one were to use the methods > mentioned above, one would still need all the bounds checking code that's > there (the only savings would be calling PyList_SetSlice rather than having > a manual loop, at the expense of extra memory management). Again, I'd argue > it's worth an 10x speedup. > Robert, "premature optimization is the root of all evil"... You are trying to be faster than CPython!! list.pop() is implemented more or less with PyList_SetSlice !! > Ideally there should be a PyList_Pop method in the C API, and more efficient > than the one that's there, but that's not the case. > Yes, of course... And if it were, it would likely be implemented with PyList_SetSlice, as the list.pop() method is currently is... Or core CPython devs are truly lazy, or you Robert are wasting valuable time in micro-optimizations ... > ----------------------------------------------------------- > > In [1]: from benchmark_pop import * > > In [2]: L = range(10**7) > > In [3]: time cython_pop(L, 10**7) > CPU times: user 0.15 s, sys: 0.00 s, total: 0.16 s > Wall time: 0.16 s > > In [5]: L = range(10**7) > > In [6]: time python_pop(L, 10**7) > CPU times: user 0.78 s, sys: 0.00 s, total: 0.78 s > Wall time: 0.78 s > > In [8]: L = range(10**7) > > In [9]: time cython_pop_index(L, 10**7-1, -2) > CPU times: user 0.21 s, sys: 0.00 s, total: 0.21 s > Wall time: 0.21 s > > In [11]: L = range(10**7) > > In [12]: time python_pop_index(L, 10**7-1, -2) > CPU times: user 2.38 s, sys: 0.01 s, total: 2.39 s > Wall time: 2.40 s > > > _______________________________________________ > Cython-dev mailing list > Cython-dev@codespeak.net > http://codespeak.net/mailman/listinfo/cython-dev > > -- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
