29.04.2014 13:00, Jonas Maebe пишет:
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/ )
Thanks for the explanation. I was mostly interested in performance data, using callgrind and
cachegrind tools, not memcheck. Also I did not compile with SSE floating-point options. That
explains why I didn't encounter the mentioned issues with cmem/SSE support.
Regards,
Sergei
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
