[fpc-devel] Need heap manager -gv explanation

[Sergei Gorelkin]

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