On Mon, Mar 24, 2003 at 09:59:36PM -0800, Zeev Suraski wrote:
> If __thread is any similar to Tls under Windows (which would be my guess),
> then we can't use it directly. We're already using pthread_setspecific so
> we're extremely quick with fetches as it is. As I said, I also doubt very
> much that our performance penalty is solely due to fetches, but mostly
> based on other issues, which __thread will not alter in any way. You're
> more than encouraged to try and implement a __thread based solution in
> place of the pthread_setspecific solution and see if it makes any
> difference. If it does, we can investigate further in that direction and
> see if it's usable.
I suppose that __thread is similar to __declspec( thread ). I really don't
know what is faster - using
__thread / __declspec(thread) struct {..} thread_globals;
and accesing it in code by
thread_globals.variable
which probably relay on CPU's MMU (depends on compiler and libc) is probably
faster than
(((type) (*((void ***) tsrm_ls))[TSRM_UNSHUFFLE_RSRC_ID(id)])->element)
which cannot be well optimized because id is global variable and could change
between function calls.
I won't argue - you have more experience. I'll try to implement TSRM macros,
but I don't have time now. I'll do it in July (if it won't be implemented yet).
Regards,
Wojtek
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
