RE: ICU tracing and thread locale storage

I share some concerns with Robert.  While TLS can be useful, I'm not sure 
how portable it is or how easy it would be for ICU to use it.  Making 
u_cleanup deal with TLS wouldn't be easy either.

I also wouldn't see how the tracing API would efficiently deal with TLS 
even when the user could supply a good routine for such a feature.  I 
believe that TLS would add a huge amount of unnecessary API user overhead 
(especially with request #2) and computer execution overhead especially 
for single threaded applications.

When I asked if the integer that determines the level of tracing could be 
kept private and accessible only by a function, this was determined to be 
too much overhead for the frequently called high performance functions.

Thread local storage just doesn't give me a warm fuzzy feeling...
http://msdn.microsoft.com/library/en-us/dllproc/base/thread_local_storage.asp?frame=true
http://www.opengroup.org/onlinepubs/007904975/functions/pthread_key_create.html
http://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html

I recommend that a policy about thread local storage be addressed before 
talking about how ICU tracing can work with TLS.

George Rhoten
IBM Globalization Center of Competency/ICU  San José, CA, USA




"Robert Buck" <[email protected]>
Sent by: [email protected]
11/04/2003 06:19 AM
 
        To:     <[email protected]>, <[email protected]>
        cc: 
        Subject:        RE: proposal for ICU tracing




> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of
> Carl W. Brown
> Sent: Monday, November 03, 2003 3:23 PM
> To: [email protected]
> Subject: RE: proposal for ICU tracing
>
> Request #2 add a user pointer in the TLS that the application
> can manage. Provide an API that makes the address of the
> pointer available to the application at any time.  The
> appliction must free and structures that it points to with
> the pointer before freeing the TLS.

This is particularly important in Windows especially, since Windows does 
no automated cleanup of any sort. And the automated cleanup routines, in 
some POSIX implementations, is also broken or extremely limited. So in 
general, if Carl is suggesting that the application must manage TLS data, 
I'd agree. There are quite a few places where it can be applied with great 
success. But on the whole, the memory management aspect of TSS objects (in 
Win32 and POSIX APIs) is, in my opinion, really flawed and is its one 
short-coming. Users are left with manually managing the memory, or if they 
want more sophisticated memory management, they are left to writing their 
own native TSS implementation (it is not too difficult to write one 
yielding higher performance and scalability).

Cautionary Note: some platforms only support 64 thread keys. If ICU starts 
chewing up many keys, application developers may become disgruntled.

Additional side note, if the application pools threads, one could just let 
the objects dangle, and never deallocate.

> I believe that ultimately the addition of TLS support into
> ICU could actually improve the performance.  For example it
> could be used to reduce locale processing overhead.  ICU
> spends a lot of processing checking and decomposing locale
> information especially when you need both C and C++ locale
> pairs.  You could save the C locale, a pointer to the C++
> locale object and the language, country and variant
> components of the locale until a new locale value was passed.
>  If the results were stored into TLS they could speed up ICU
> processing more than the extra overhead for tracing.  I have
> watched traces of ICU activity and believe that this would be
> a significant performance enhancement that could be phased in
> over a few releases.

I've been able to demonstrate a huge performance advantage in MATLAB by 
caching in thread specific storage a per thread converter pool. I've 
measured the time to create converters at as high as 30455 cycles (first 
converter ever created in a process), and on average around 2080 cycles 
(create time for the same converter type thereafter). For the same 
application, getting one from a thread specific converter pool, about 351 
cycles. Creating pooled allocator APIs, for ICU objects of all sorts, can 
be a big win for ICU users.

- Bob

_______________________________________________
icu mailing list
[email protected]
http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu