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
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.)
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
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).
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.
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
allocations, am I wrong?
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.
http://wiki.python.org/moin/PythonImplementations
John
--
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.