On 29/04/14 08:45, Sergei Gorelkin wrote:
-gv switch in command line disables the optimized i386 Move procedure (and that's basically the only thing it does), so it indeed should cause slowdown. Comments say that valgrind (some pretty old version of it) is unable to handle the optimizied Move code. In the meantime, valgrind was presumably fixed. At least since my involvement with FPC back in 2005 I was able to use valgrind to profile programs without any trouble, and without recompiling them with -gv. So maybe it's time reconsider the action of -gv switch, or to remove it altogether.
As Tomas mentioned, -gv also causes the use of the C memory manager. This is required because while Valgrind also recognises mmap (as used by our memory manager), the result is not fine grained enough to be of any use: Valgrind can't magically determine that our heap manager divides the mmap'ed blocks into smaller allocations.
Regarding the SSE support in Valgrind: its assembler and disassembler have supported those instructions since a long time, but memcheck didn't. In particular, it didn't support memory initialisations using the movaps instruction. And at least in 2010, it still didn't: https://code.google.com/p/nativeclient/issues/detail?id=2251
Maybe it's finally fixed in the latest Valgrind release (from October last year), as the changelog lists various SSE fixes for optimized string copy routines (search for "SSE" in https://lwn.net/Articles/572790/ )
Jonas _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
