At 11:50 PM 8/13/2001 -0700, Paul Prescod wrote:
>Tim Peters wrote:
> >...
> > IIRC, Greg's fabled free-threading version of Python took a speed hit of
> > about a factor of 2 (for a program using only 1 thread, compared to that
> > same program without the free-threading patches).
>
>The Perl guys considered this unacceptable and I can kind of see their
>point. You have two processors but you get roughly the same performance
>as one?
The perl speed hit's as much because of half-baked code as anything else.
Changing the two instances of pthread_get_specific to
pthread_get_specific_unchecked_np (which just bypasses the validation of
the TSD key on Tru64 and VMS) sped up threaded perl by around 3-5%
The original, pthread-like threading model in perl was never finished for a
variety of reasons. Do use many of the things it exposed as object lessons,
but speed isn't one of them.
Or maybe it is. FWIW, here's a data point. When I took perl and wrapped all
variable access in a thread-safe way (basically we got a lock before
accessing a variable and let go when we were done) we took a 40% speed hit.
Now, this was on OpenVMS where the mutexes are about 3-5x as expensive as
on Tru64 on the same box, but it was a significant cost.
I racked up a whole list of "Things to Not Do With Threads" when hacking
the original perl thread model. (The first of which is "wedge them into an
interpreter that wasn't written with threads in mind..." :) Battle scars
are viewable on request.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk
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