On 10/19/2010 05:59 AM, Manti Bose wrote: > > @Miguel: I apologise for not phrasing my query clearly. I meant is there > any work going on to parallelize Valgrind inorder to make its > performance faster using multicore processors.
At the lowest level of code, such work is specific to each CPU architecture: how instructions encode addresses, how relocation info is represented, etc. This makes it unappealing to (n-1)/n of the audience. Currently n=5: x86, amd64, ppc, ppc64, arm. Perhaps x86 and amd64 are close enough, and similarly for ppc vs ppc64; still n>=3. At the highest level of code, valgrind already has internal assumptions about serializing threads. Untangling these assumptions is work. Many years ago I parallelized a different memory checker (not Memcheck): each thread checked itself. At the lowest level there were about a dozen places that required interlocked OR-to-memory and AND-to-memory. At the "highest" level some gymnastics were necessary to enter and leave the parts of the code that were thread-specific versus truly re-entrant. For performance reasons the notion of "ThreadLocalStorage" also included "thread-local instructions." -- ------------------------------------------------------------------------------ Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
