|
From: Vasily G. <vas...@gm...> - 2013-08-05 13:02:04
|
Hello, all. I am searching some ideas for Valgrind's improvements where I can help. For me, changes connected with ARM (or general, like speed improvements) are quite interesting. I have some experience with Valgrind - implementation of some instructions from ARM and Thumb instruction sets. In fact, for me as ARM user, the main limiting factor for Valgrind is its speed. Maybe it is possible somehow to increase it? I have read articles about Valgrind (internal structure, shadow memory, etc.). I have some ideas but I am not sure that they are good enough (and speed improvements is not obvious). Here I placed the list of them: 1. Think about some new optimization during IR -> binary code conversion after instrumentation. Maybe there are some new optimizations (see at LLVM sources?) that can be implemented in Valgrind for speed? Some ARM-specific optimizations? 2. Maybe we can slightly (introduce new flag?) increase memory consumption but increase the speed? (increase cache size for compiled blocks?) 3. Now SETEND (feature of changing little\big endian) instruction for ARM is not implemented. Maybe it is OK to implement it (big changes?) and support big endianess for ARM? It will be also necessary to rewrite a lot of instructions parsing in VEX. 4. Think about next ARM (v8 ?) and some new instructions\features that can be realized? In fact, if the project will be quite big\complex, I think I can ask a couple of people to help with it. Any comments\ideas are welcome! -- Thank you in advance, Vasily |
|
From: John R.
|
Only two areas really matter: 1. speed of memcheck 2. 64-bit ARM The most likely path to better speed is to make cross-platform checking work. Check an ARM target program by running memcheck on a fast x86* CPU (>=4GHz) with a large data cache (>=8MB) under a "compatible" operating system. Translating system calls might be tedious but should not be onerous. |
|
From: Konstantin T. <an...@ya...> - 2013-08-06 10:18:52
|
06.08.2013, 08:23, "John Reiser" <jreiser@BitWagon.com>: > Only two areas really matter: > 1. speed of memcheck > 2. 64-bit ARM > > The most likely path to better speed is to make cross-platform checking work. > Check an ARM target program by running memcheck on a fast x86* CPU (>=4GHz) > with a large data cache (>=8MB) under a "compatible" operating system. > Translating system calls might be tedious but should not be onerous. That would be quite useful not only for ARM, but for PPC and MIPS too. -- Regards, Konstantin |
|
From: Vasily G. <vas...@gm...> - 2013-08-07 06:53:52
|
Mr. Tokarev, Can you specify some areas where 64 bit ARM is being used? I mean some links on real devices, systems, etc.? Does some company use it in mobile devices (phones, tablets)? Thanks On Tue, Aug 6, 2013 at 2:18 PM, Konstantin Tokarev <an...@ya...>wrote: > > > 06.08.2013, 08:23, "John Reiser" <jreiser@BitWagon.com>: > > Only two areas really matter: > > 1. speed of memcheck > > 2. 64-bit ARM > > > > The most likely path to better speed is to make cross-platform checking > work. > > Check an ARM target program by running memcheck on a fast x86* CPU > (>=4GHz) > > with a large data cache (>=8MB) under a "compatible" operating system. > > Translating system calls might be tedious but should not be onerous. > > That would be quite useful not only for ARM, but for PPC and MIPS too. > > -- > Regards, > Konstantin > > > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- Best Regards, Vasily |
|
From: Vasily G. <vas...@gm...> - 2013-08-07 06:58:43
|
Sorry, In fact, previous question was for Mr. Reiser according to his answer. On Wed, Aug 7, 2013 at 10:53 AM, Vasily Golubev <vas...@gm...>wrote: > Mr. Tokarev, > > Can you specify some areas where 64 bit ARM is being used? > I mean some links on real devices, systems, etc.? > Does some company use it in mobile devices (phones, tablets)? > > > Thanks > > > On Tue, Aug 6, 2013 at 2:18 PM, Konstantin Tokarev <an...@ya...>wrote: > >> >> >> 06.08.2013, 08:23, "John Reiser" <jreiser@BitWagon.com>: >> > Only two areas really matter: >> > 1. speed of memcheck >> > 2. 64-bit ARM >> > >> > The most likely path to better speed is to make cross-platform checking >> work. >> > Check an ARM target program by running memcheck on a fast x86* CPU >> (>=4GHz) >> > with a large data cache (>=8MB) under a "compatible" operating system. >> > Translating system calls might be tedious but should not be onerous. >> >> That would be quite useful not only for ARM, but for PPC and MIPS too. >> >> -- >> Regards, >> Konstantin >> >> >> ------------------------------------------------------------------------------ >> Get your SQL database under version control now! >> Version control is standard for application code, but databases havent >> caught up. So what steps can you take to put your SQL databases under >> version control? Why should you start doing it? Read more to find out. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk >> _______________________________________________ >> Valgrind-users mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users >> > > > > -- > Best Regards, > Vasily > -- Best Regards, Vasily |
|
From: John R.
|
> Can you specify some areas where 64 bit ARM is being used? > I mean some links on real devices, systems, etc.? > Does some company use it in mobile devices (phones, tablets)? So far, 64-bit ARM is for use in data centers which desire lower power consumption and lower cooling costs, but still must handle larger address spaces. Battery-powered or portable devices prefer 32 bits because of monetary cost, physical size, and software issues. |
|
From: Vasily G. <vas...@gm...> - 2013-08-07 14:12:11
|
OK, thanks! And a couple of words about cross-platform checking. If I did understand you correct you propose smth like running valgrind under quemu (1) or whole quemu under valgrind (2). (2) - will be significantly slower because we need to instrument whole system (not one binary\application) (1) - as far as I know only code generation (from arm to x86 binary) made by quemu-user decreases work of application x4. And we will need to use system-wide quemu (not only user) that also decreases speed. So, now ARM has more than 1GHz and we will not improve situation with 4Ghz host. I think that we can use assessment of quemu even if we plan write our own VM in Valgrind. Maybe I am wrong. On Wed, Aug 7, 2013 at 4:54 PM, John Reiser <jr...@bi...> wrote: > > Can you specify some areas where 64 bit ARM is being used? > > I mean some links on real devices, systems, etc.? > > Does some company use it in mobile devices (phones, tablets)? > > So far, 64-bit ARM is for use in data centers which desire > lower power consumption and lower cooling costs, but still > must handle larger address spaces. Battery-powered or > portable devices prefer 32 bits because of monetary cost, > physical size, and software issues. > > > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- Best Regards, Vasily |
|
From: John R.
|
> And a couple of words about cross-platform checking. If I did understand you correct you propose smth like running valgrind under quemu (1) or whole quemu under valgrind (2). I was thinking of running memcheck(valgrind) compiled for x86_64, running on x86_64 under Linux, but checking a target program that was compiled for ARM and designed for Android. If the SDK for Android runs on x86_64 under Linux but emulates ARM for Android, then the memcheck JIT engine can do the same thing but also perform its checks of memory accesses, malloc+free, etc. |