<br><br><div class="gmail_quote">2009/10/22 John Yeung <span dir="ltr"><<a href="mailto:gallium.arsenide@gmail.com">gallium.arsenide@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Oct 22, 12:28 am, John Nagle <<a href="mailto:na...@animats.com">na...@animats.com</a>> wrote:<br>
<br>
>    The Shed Skin people would welcome some help.<br>
><br>
>        <a href="http://shed-skin.blogspot.com/" target="_blank">http://shed-skin.blogspot.com/</a><br>
<br>
</div>People?  It's one guy.  It apparently started out as a Master's thesis<br>
as well. ;)<br>
<br>
I am a great admirer of the Shed Skin project, and I would be as happy<br>
as anyone to see it progress.  However, it seems to me that Shed Skin<br>
is at a stage where what it really needs is plain old "more work".  (I<br>
don't want to call it grunt work, but it's things like more testing,<br>
implementing more library support, maintaining the Windows build,<br>
etc.  Very worthy and worthwhile work, but tough to pass off as<br>
academic graduate work.)<br>
<br>
To the original poster:  I am not sure if this is too ambitious for<br>
your time frame, but one thing many real-world Python users would LOVE<br>
is for some way to get rid of the GIL (while still retaining thread<br>
safety, single-core performance, etc.).  If you could patch CPython to<br>
make it GIL-less, I think you would have academically publishable<br>
material as well as being a hero in the Python community. :D<br></blockquote><div><br>A short question after having read through most of this thread, on the same subject (time-optimizing CPython):<br><br><a href="http://mail.python.org/pipermail/python-list/2007-September/098964.html">http://mail.python.org/pipermail/python-list/2007-September/098964.html</a><br>
<br>We are experiencing multi-core processor kernels more and more these days. But they are all still connected to the main memory, right?<br><br>To me that means, even though some algorithm can be split up into several threads that run on different cores of the processor, that any algorithm will be memory-speed limited. And memory access is a quite common operation for most algorithms.<br>
<br>Then one could ask oneself: what is the point of multiple cores, if memory bandwidth is the bottleneck? Specifically, what makes one expect any speed gain from parallelizing a sequential algorithm into four threads, say, when the memory shuffling is the same speed in both scenarios? (Assuming memory access is much slower than ADDs, JMPs and such instructions - a quite safe assumption I presume)<br>
<br>[ If every core had it's own primary memory, the situation would be different. It would be more like the situation in a distributed/internet based system, spread over several computers. One could view each core as a separate computer actually ]<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<font color="#888888"><br>
John<br>
</font><div><div></div><div class="h5">--<br>
<a href="http://mail.python.org/mailman/listinfo/python-list" target="_blank">http://mail.python.org/mailman/listinfo/python-list</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><a href="http://twitter.com/olofb">twitter.com/olofb</a><br><a href="http://olofb.wordpress.com">olofb.wordpress.com</a><br><a href="http://olofb.wordpress.com/tag/english">olofb.wordpress.com/tag/english</a><br>
<br>