links

22 views
Skip to first unread message

srepmub

unread,
Nov 28, 2010, 7:43:32 AM11/28/10
to shedskin-discuss
hi all,

I'd like to have a thread with links to blog postings and such where
shedskin is tested or compared with other implementations. to start
with, here's a very recent blog post, where the author tries some
different approaches to get his code to run faster:

http://geetduggal.wordpress.com/2010/11/25/speed-up-your-python-unladen-vs-shedskin-vs-pypy-vs-c/

shedskin goes from slowest (C++ doesn't like huge amounts of small
allocations!) to fastest (after manual C), after a few minor tweaks.
and it can be faster with -bw (see comments).

here's a recent comparison of mine against psyco. looks like next time
I will have to compare against pypy.. :)

http://shed-skin.blogspot.com/2010/05/shedskin-versus-psyco-for-131-project.html

this comparison is perhaps my favourite though:

http://www.hxa.name/minilight/

while you won't often get a speedup of around 100 times, here's an
even larger one:

http://ianozsvald.com/2008/11/17/making-python-math-196-faster-with-shedskin/

(though the largest measured speed was around 300 times iirc, for the
Kanoodle example)

so, please add to this thread if you know of or encounter any other
interesting tests or comparisons!

thanks,
mark.

John Yeung

unread,
Nov 28, 2010, 10:09:20 AM11/28/10
to shedskin...@googlegroups.com
Here is a very complimentary blog article. It does have one hard
timing comparison, but it feels more like a general introduction to
Shed Skin for those who don't know about Shed Skin yet than an actual
benchmarking post. (Which is still good, right? I think this article
would have helped support the Wikipedia effort, for example; and could
be used for a future attempt to get into Wikipedia.)

I am surprised you didn't list this among your links already, because
the blog author mentions that he was contacted directly by Shed Skin's
author. ;)

http://www.korokithakis.net/node/117

John

Mark Dufour

unread,
Nov 28, 2010, 10:16:43 AM11/28/10
to shedskin...@googlegroups.com
On Sun, Nov 28, 2010 at 4:09 PM, John Yeung <gallium....@gmail.com> wrote:
Here is a very complimentary blog article.  It does have one hard
timing comparison, but it feels more like a general introduction to
Shed Skin for those who don't know about Shed Skin yet than an actual
benchmarking post.  (Which is still good, right?  I think this article
would have helped support the Wikipedia effort, for example; and could
be used for a future attempt to get into Wikipedia.)

ah, yes, I forgot about this one, thanks! and good you mention wikipedia. if anyone reading this might want to re-create a wikipedia page, here's a link to the section in lutz's well known "learning python" book that describes shedskin:
 
http://books.google.com/books?id=1HxWGezDZcgC&pg=PA31&lpg=PA31&dq=learning+python+shedskin&source=bl&ots=LiNd3Of4p-&sig=FRdDxpvcj2uY5dbYqztosrIE_sw&hl=en&ei=WnHyTPb8DISBOtbnoYwK&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBUQ6AEwAA#v=onepage&q&f=false


thanks again!!
mark.
--
http://www.youtube.com/watch?v=E6LsfnBmdnk

Jérémie Roquet

unread,
Nov 28, 2010, 1:35:29 PM11/28/10
to shedskin...@googlegroups.com
Hi,

2010/11/28 srepmub <mark....@gmail.com>:


> I'd like to have a thread with links to blog postings and such where
> shedskin is tested or compared with other implementations.

OK, I'll post some as I get them… I've set a Google alert for shedskin ;-)

> to start
> with, here's a very recent blog post, where the author tries some
> different approaches to get his code to run faster:
>
> http://geetduggal.wordpress.com/2010/11/25/speed-up-your-python-unladen-vs-shedskin-vs-pypy-vs-c/
>
> shedskin goes from slowest (C++ doesn't like huge amounts of small
> allocations!) to fastest (after manual C), after a few minor tweaks.
> and it can be faster with -bw (see comments).

I'm very pleased a few tweaks were enough to make the shedskin version
faster than the others (especially the pypy one :p). I was very
suprised by the first benchmark's results.

I don't know what kind of allocation is responsible for the overhead
there, but I guess escape analysis would help for scalar types… and
maybe some kind of factory would help for more complex objects too (if
this objects are properly garbage collected).

> here's a recent comparison of mine against psyco. looks like next time
> I will have to compare against pypy.. :)
>
> http://shed-skin.blogspot.com/2010/05/shedskin-versus-psyco-for-131-project.html

Would be awesome to have the comparison against pypy :-)

> this comparison is perhaps my favourite though:
>
> http://www.hxa.name/minilight/

I missed that one, so thanks for the link.
It makes me think that it would be interesting to have some benchmarks
with clang / dragonegg instead of gcc… especially when comparing to
pypy.

Best regards,

--
Jérémie

Mark Dufour

unread,
Nov 29, 2010, 12:14:43 PM11/29/10
to shedskin...@googlegroups.com
I'm very pleased a few tweaks were enough to make the shedskin version
faster than the others (especially the pypy one :p). I was very
suprised by the first benchmark's results.

 
in the meantime, shedskin GIT has gone from 77 to about 46 seconds for the original program. it turns out string comparison and slicing were both still not very optimal.. :P

the strangeness of the benchmarks comes from the fact it's essentially a single loop:

for x in range(200000000):
    s = somestr[x:x+3]
    if s == 'abc' or s == 'bcd' or s == 'cde':
        blah

so the crucial aspect is how does the memory subsystem handle all these slices. it looks like pypy uses escape analysis to recycle the slices, or perhaps it caches 3-length strings (shedskin only caches 256 1-length strings at the moment). in any case, when I manually 'reuse' the same string object, I get about the same speed as pypy.

I don't know what kind of allocation is responsible for the overhead
there, but I guess escape analysis would help for scalar types… and
maybe some kind of factory would help for more complex objects too (if
this objects are properly garbage collected).

yes, I think some scheme to allocate objects N at a time and recycling them somehow can help a lot. but I think in this and other cases, it could also help to rewrite the string class. dropping (indirection to) the STL helped a lot for the set and dict classes as well. unused mutability of std::string probably also costs us.

I missed that one, so thanks for the link.
It makes me think that it would be interesting to have some benchmarks
with clang / dragonegg instead of gcc… especially when comparing to
pypy.

yes, definitely. I think there's quite a bit that can be optimized outside of shedskin. it feels a bit weird to have to worry about escape analysis and other memory optimizations, if Java has them out-of-the-box.. I would expect the Boehm GC to get in the way though, since it overloads 'new', so that it's impossible to follow what happens there. I also doubt they do much in this area, because the naive output of shedskin is not that typical (looks more like Java.. hm :-)).


thanks!
mark.
--
http://www.youtube.com/watch?v=E6LsfnBmdnk

Jérémie Roquet

unread,
Nov 29, 2010, 12:52:37 PM11/29/10
to shedskin...@googlegroups.com
2010/11/29 Mark Dufour <mark....@gmail.com>:

> the strangeness of the benchmarks comes from the fact it's essentially a
> single loop:
>
> for x in range(200000000):
>     s = somestr[x:x+3]
>     if s == 'abc' or s == 'bcd' or s == 'cde':
>         blah
>
> so the crucial aspect is how does the memory subsystem handle all these
> slices. it looks like pypy uses escape analysis to recycle the slices, or
> perhaps it caches 3-length strings (shedskin only caches 256 1-length
> strings at the moment). in any case, when I manually 'reuse' the same string
> object, I get about the same speed as pypy.

Since Python strings are immutable, slices should never lead to memory
allocations, am I wrong?
This leads me to the next point :

>> I don't know what kind of allocation is responsible for the overhead
>> there, but I guess escape analysis would help for scalar types… and
>> maybe some kind of factory would help for more complex objects too (if
>> this objects are properly garbage collected).
>
> yes, I think some scheme to allocate objects N at a time and recycling them
> somehow can help a lot. but I think in this and other cases, it could also
> help to rewrite the string class. dropping (indirection to) the STL helped a
> lot for the set and dict classes as well. unused mutability of std::string
> probably also costs us.

Yes, I entirely agree. That's something I've already thought about
several times… std::string is of little help there, and it has a
serious overhead for several simple tasks :
- slicing
- copying
- resizing to a shorter string
- (maybe with some additional work) working with simple `char' where
strings are not needed (eg. for expressions like
x = 'a'
or
if foo[42] == 'z':
or even
x = 'a'
if foo[42] == x:
)

When the ticket for issue 74 (bz2) was opened, I wanted to write a
quick and dirty implementation. Unfortunately, the current internal
representation of strings prevents us from simply returning pointers
to arbitrary locations in the memory. Same problem for the `easy' task
`improve IO speed': being able to mmap files and return pointers on
the memory without any copying would help a lot.

As you may already know, the CPython representation for strings is a
pair of pointers: one for the beginning of the string, the other for
the end. I think nothing is more efficient than this.

Best regards,

--
Jérémie

Mark Dufour

unread,
Nov 29, 2010, 2:30:08 PM11/29/10
to shedskin...@googlegroups.com

Since Python strings are immutable, slices should never lead to memory
allocations, am I wrong?

well, if we keep everything copy-by-reference, we'd still have to store the slice start and end somewhere.. but if we use copy-by-value, that would avoid any allocations. though I never really liked copy-by-value. it's ugly and complicates code generation in several ways..

Yes, I entirely agree. That's something I've already thought about
several times… std::string is of little help there, and it has a
serious overhead for several simple tasks :
 - slicing
 - copying
 - resizing to a shorter string
 - (maybe with some additional work) working with simple `char' where
strings are not needed (eg. for expressions like

for set and dict it turned out to be a very good idea to just do it the cpython way.. I also like this approach because it gives the same behaviour, so for example making it faster in cpython makes it faster with shedskin as well.
 
 x = 'a'
or
 if foo[42] == 'z':
or even
 x = 'a'
 if foo[42] == x:
)

shedskin currently caches all 256 possible 1-length strings, so indexing a string for example doesn't cause an allocation, and working with "characters" is really fast. that's also how I optimized geet's program for shedskin, by simply comparing three characters instead of slicing and then comparing.

I played a bit with an alternative 'char' type some time ago, but that ended up complicating too many things, and because the current approach works practically just as well in many cases, in the end that clearly wasn't worth the effort.
 
When the ticket for issue 74 (bz2) was opened, I wanted to write a
quick and dirty implementation. Unfortunately, the current internal
representation of strings prevents us from simply returning pointers
to arbitrary locations in the memory. Same problem for the `easy' task
`improve IO speed': being able to mmap files and return pointers on
the memory without any copying would help a lot.

yeah, that's something to keep in mind. though the main problem with IO speed is that currently everything happens per-character.
 
As you may already know, the CPython representation for strings is a
pair of pointers: one for the beginning of the string, the other for
the end. I think nothing is more efficient than this.

no, but it sounds logical at this point.. ;) I'm guessing though that it still allocates a new object for each slice, to contain these pointers.. what I'm hoping is that we can somehow efficiently manage such objects, without needing copy-by-value.. it should at least be possible to allocate many of them at once. deallocation and recycling may be a bit trickier.. :P

thanks,
mark.
--
http://www.youtube.com/watch?v=E6LsfnBmdnk

srepmub

unread,
Dec 6, 2010, 11:07:32 AM12/6/10
to shedskin-discuss

> > here's a recent comparison of mine against psyco. looks like next time
> > I will have to compare against pypy.. :)
>
> >http://shed-skin.blogspot.com/2010/05/shedskin-versus-psyco-for-131-p...
>
> Would be awesome to have the comparison against pypy :-)

here's a comparison by greg copeland (haven't looked at the code yet):

https://www.blogger.com/comment.g?blogID=14063458&postID=1425969918991406460


thanks,
mark.

John Yeung

unread,
Dec 11, 2010, 1:06:42 PM12/11/10
to shedskin...@googlegroups.com
No benchmarks here, but I wanted to note that Shed Skin is listed in
the compiler section of "Python Implementations" on the Python Wiki:

http://wiki.python.org/moin/PythonImplementations

John

Mark Dufour

unread,
May 24, 2011, 5:08:43 AM5/24/11
to shedskin...@googlegroups.com
hi,

an update to the 'links' thread - in addition to 'learning python', shed skin is now also (very shortly) mentioned in 'python algorithms':

http://books.google.com/books?id=9_AXCmGDiz8C&pg=PA272&dq=python+shedskin&hl=en&ei=eXTbTeSTNI3dsgbo04juDg&sa=X&oi=book_result&ct=result&resnum=4&ved=0CDwQ6AEwAw#v=onepage&q=python%20shedskin&f=false


thanks,
mark.



--
You received this message because you are subscribed to the Google Groups "shedskin-discuss" group.
To post to this group, send email to shedskin...@googlegroups.com.
To unsubscribe from this group, send email to shedskin-discu...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/shedskin-discuss?hl=en.




--
http://www.youtube.com/watch?v=E6LsfnBmdnk

Enzo

unread,
May 24, 2011, 4:48:19 PM5/24/11
to shedskin-discuss
My congratulations!

Is very good that SS is gaining popularity, and even better to be
present in the literature!

Best regards.


On May 24, 5:08 am, Mark Dufour <mark.duf...@gmail.com> wrote:
> hi,
>
> an update to the 'links' thread - in addition to 'learning python', shed
> skin is now also (very shortly) mentioned in 'python algorithms':
>
> http://books.google.com/books?id=9_AXCmGDiz8C&pg=PA272&dq=python+shed...
>
> thanks,
> mark.
>
> On Sat, Dec 11, 2010 at 7:06 PM, John Yeung <gallium.arsen...@gmail.com>wrote:
>
>
>
Reply all
Reply to author
Forward
0 new messages