|
From: Manti B. <man...@gm...> - 2010-10-19 10:31:22
|
Hi, I was curious to know about any developments related to Valgrind working on multicore platforms. As an end user I am looking forward to this support in the near future and would like to be updated on this thread. Warm regards, Manti |
|
From: Miguel O. <mig...@gm...> - 2010-10-19 10:47:23
|
Hi, On Tue, Oct 19, 2010 at 12:31 PM, Manti Bose <man...@gm...> wrote: > Hi, > > I was curious to know about any developments related to Valgrind working on > multicore platforms. As an end user I am looking forward to this support in > the near future and would like to be updated on this thread. What do you mean? Debugging multi-threaded programs? If so, maybe you would like to try out DRD & Helgrind. > > Warm regards, > Manti > > ------------------------------------------------------------------------------ > 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 > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > |
|
From: Manti B. <man...@gm...> - 2010-10-19 12:59:09
|
@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. On Tue, Oct 19, 2010 at 4:17 PM, Miguel Ojeda < mig...@gm...> wrote: > Hi, > > On Tue, Oct 19, 2010 at 12:31 PM, Manti Bose <man...@gm...> wrote: > > Hi, > > > > I was curious to know about any developments related to Valgrind working > on > > multicore platforms. As an end user I am looking forward to this support > in > > the near future and would like to be updated on this thread. > > What do you mean? Debugging multi-threaded programs? If so, maybe you > would like to try out DRD & Helgrind. > > > > > Warm regards, > > Manti > > > > > ------------------------------------------------------------------------------ > > 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 > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > > > |
|
From: John R. <jr...@bi...> - 2010-10-19 14:49:47
|
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." -- |