James Y Knight <foom at fuhm.net> writes:
> Investigating the pybench some more, it seems that speedup for many of
> the tests is because of the shortcut for tagged types in Py_INCREF and
> Py_DECREF. E.g. with the pybench TupleSlicing test, as written, the
> speed diff is -39.13%. However, changing the tuple to contain strings
> instead of integers causes the change to be +0.03%.
>
> This makes me think that perhaps using an inline tagged representation
> for things like True, False, and single character strings < 256 might
> be a win as well, even though they don't ever cause memory allocation
> -- just because of the refcounting. Well, I tried making booleans a
> tagged types as well: pybench then runs 11% faster than standard
> python (vs the 7% with just tagged integers).
Interesting!
> P.S.: I have also previously experimented with removing refcounting
> from Python completely, and using the Boehm GC, because I theorized
> that refcounting could very well be slower than a full conservative
> GC. It mostly worked (I did not finish, so it did not support
> destructors or weakrefs), but was not a win, because it was no longer
> possible to use large block allocation and free list tricks for
> integers, and thus integer allocation caused a huge slowdown. I might
> revisit that now. I do realize using Boehm GC has pretty much a
> negative probability of making it into standard python, though. :)
The last time I mentioned that the Boehm GC didn't help Python much
(on comp.lang.lisp) Hans Boehm showed up and claimed that it was
because we weren't using it properly :-) Let us know how it goes...
Cheers,
mwh
--
A difference which makes no difference is no difference at all.
-- William James (I think. Reference anyone?)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4