dual processor

Steve Jorgensen nospam at nospam.nospam
Tue Sep 6 07:14:12 CEST 2005


On Mon, 05 Sep 2005 23:42:38 -0400, Jeremy Jones <zanesdad at bellsouth.net>
wrote:

>Steve Jorgensen wrote:
>
...
>>That argument makes some sense, but I'm still not sure I agree.  Rather than
>>make Python programmers have to deal with concurrentcy issues in every app to
>>get it to make good use of the hardware it's on, why not have many of the
>>common libraries that Python uses to do processing take advantage of SMP when
>>you use them.  A database server is a good example of a way we can already do
>>some of that today.  Also, what if things like hash table updates were made
>>lazy (if they aren't already) and could be processed as background operations
>>to have the table more likely to be ready when the next hash lookup occurs.
>>  
>>
>Now, *this* is a really interesting line of thought.  I've got a feeling 
>that it'd be pretty tough to implement something like this in a 
>language, though.  An application like an RDBMS is one thing, an 
>application framework another, and a programming language is yet a 
>different species altogether.  It'd have to be insanely intelligent 
>code, though.  If you had bunches of Python processes, would they all 
>start digging into each list or generator or hash to try to predict what 
>the code is going to potentially need next?  Is this predictive behavior 
>going to chew up more CPU time than it should?  What about memory?  
>You've got to store the predictive results somewhere.  Sounds great.  
>Has some awesomely beneficial implications.  Sounds hard as anything to 
>implement well, though.

I think you're making the concept harder than it needs to be.  From what I'm
told by folks who know SMP way better than me, it's usually best to just look
for stuff that's waiting to be done and do it without regard to whether the
result will ever be used.  That tends to be more efficient than trying to
figure out the most useful tasks to do.

In this case, it woiuld just be keeping a list of dirty hash tables, and
having a process that pulls the next one from the queue, and cleans it.



More information about the Python-list mailing list