Hi

I have some application with huge usage ReAllocMem and I found the big performance difference if application is compiled with -gv option (cca 20x faster) then without -gv option.

I suspect fpc heap manager. Is possible to tune fpc heap manager? Is some difference in heap manager if application is comiled with -gv or without -gv option?

Thanks
Petr

-gv generates code for valgrind.
It should be slower with -gv.

I suspect fpc heap manager. Is possible to tune fpc heap manager? Is some difference in heap manager if application is comiled with -gv or without -gv option?

Mattias

Use of valgrind requires/triggers use of cmem. Depending on the particular use case (and potentially also the target platform), cmem may indeed be faster.

Others would be better positioned for more detailed comparison among various heap managers with regard to speed in different use cases, overall memory requirements achieved by reuse of previously allocated memory, etc.

Tomas

Platform is x86_64 Linux.

Others would be better positioned for more detailed comparison among various heap managers with regard to speed in different use cases, overall memory requirements achieved by reuse of previously allocated memory, etc.

Reuse of previously allocated memory - it really can be my problem. Here is about 200x call ReAllocMem increasing buffer from 4kB to 80MB.

It looks like as buffer is increasing ReAllocMem is slowing. But I must verify this feeling.

Petr

Check if you are increasing buffers in constant steps. Change the increment to exponentially.

It looks like as buffer is increasing ReAllocMem is slowing. But I must verify this feeling.

Mattias

28.04.2014 23:14, Petr Kristan пишет:

-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.

Regards,
Sergei

On Tue, April 29, 2014 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),

I presume that you talk about the RTL side (i.e. compiling RTL with -gv). In compiler (regardless whether you use a RTL compiled with -gv or not) it triggers adding CMem (plus also some other changes related to debug information in stabs).

so it indeed should cause slowdown.

If I understand it correctly, the original poster mentioned that use of valgrind _improves_ speed (considerably) in his case. I still believe that it may be due to use of CMem instead of the standard heap manager.

I can't comment on that; I believe Jonas used Valgrind quite a lot in the past, so he might be able to comment on requirements for its use on various FPC supported platforms.

Tomas

I use "inteligent" block increasing. I can optimize program, but why is fpc heap manager to slow?

Here is the sample stress program compilable with fpc, delphi and kylix:

program m;
{$IFDEF MSWINDOWS}
  {$APPTYPE CONSOLE}
{$ENDIF}
uses
{$IFDEF MSWINDOWS}
  Windows,
{$ELSE}
  {$IFDEF FPC}
  Unix,
  {$ELSE}
  Libc,
  {$ENDIF}
{$ENDIF}
  SysUtils;
{$IFDEF MSWINDOWS}
function GetTickCount: Cardinal;
begin
  GetTickCount := Windows.GetTickCount;
end;
{$ELSE}
  {$IFDEF FPC}
  function GetTickCount: Cardinal;
  var
    tp: TTimeVal;
  begin
    fpgettimeofday(@tp, nil);
    GetTickCount := (Int64(tp.tv_sec) * 1000) + (tp.tv_usec div 1000);
  end;
  {$ELSE}
  function GetTickCount: Cardinal;
  var
    ts: TTimeSpec;
    i: Int64;
  const
    CLOCK_MONOTONIC = 1;
  begin
    if clock_gettime(CLOCK_MONOTONIC, ts)  0 then begin
      Result := 0;
      Exit;
    end;
    i := ts.tv_sec;
    i := i*1000 + ts.tv_nsec div 1000000;
    Result := i and $ffffffff;
  end;
  {$ENDIF}
{$ENDIF}
var
  p1, p2: Pointer;
  i, j: integer;
  ms, sum: Cardinal;
const
  base = 1000000;
begin
  sum := GetTickCount;
  for i := 0 to 10 do begin
    ms := GetTickCount;
    for j := 1 to 9 do begin
      ReAllocMem(p1, base*(i*10+j));
      ReAllocMem(p2, base*(i*10+j));
    end;
    Writeln(Format('Grow %d-%d %dms', [base*i*10, base*(i*10+9), GetTickCount-ms]));
  end;
  FreeMem(p1);
  FreeMem(p2);
  Writeln(Format('Sum %dms', [GetTickCount-sum]));
end.

-------------------------------------------------------------------------------- And here are results:

ppcx64 m.pas
Free Pascal Compiler version 2.7.1 [2014/02/17] for x86_64 Target OS: Linux for x86-64
Grow 0-9000000 89ms
Grow 10000000-19000000 281ms
Grow 20000000-29000000 488ms
Grow 30000000-39000000 716ms
Grow 40000000-49000000 898ms
Grow 50000000-59000000 1085ms
Grow 60000000-69000000 1294ms
Grow 70000000-79000000 1470ms
Grow 80000000-89000000 1652ms
Grow 90000000-99000000 1916ms
Grow 100000000-109000000 2099ms
Sum 12007ms

ppcx64 -gv m.pas
Free Pascal Compiler version 2.7.1 [2014/02/17] for x86_64 Target OS: Linux for x86-64
Grow 0-9000000 0ms
Grow 10000000-19000000 0ms
Grow 20000000-29000000 1ms
Grow 30000000-39000000 0ms
Grow 40000000-49000000 0ms
Grow 50000000-59000000 0ms
Grow 60000000-69000000 2ms
Grow 70000000-79000000 3ms
Grow 80000000-89000000 2ms
Grow 90000000-99000000 0ms
Grow 100000000-109000000 0ms
Sum 10ms

ppc386 m.pas
Free Pascal Compiler version 2.7.1 [2013/06/28] for i386 Target OS: Linux for i386
Grow 0-9000000 86ms
Grow 10000000-19000000 247ms
Grow 20000000-29000000 417ms
Grow 30000000-39000000 595ms
Grow 40000000-49000000 781ms
Grow 50000000-59000000 964ms
Grow 60000000-69000000 1128ms
Grow 70000000-79000000 1288ms
Grow 80000000-89000000 1438ms
Grow 90000000-99000000 1612ms
Grow 100000000-109000000 1767ms
Sum 10341ms

ppc386 -gv m.pas
Free Pascal Compiler version 2.7.1 [2013/06/28] for i386 Target OS: Linux for i386
Grow 0-9000000 0ms
Grow 10000000-19000000 0ms
Grow 20000000-29000000 0ms
Grow 30000000-39000000 0ms
Grow 40000000-49000000 0ms
Grow 50000000-59000000 0ms
Grow 60000000-69000000 1ms
Grow 70000000-79000000 0ms
Grow 80000000-89000000 0ms
Grow 90000000-99000000 0ms
Grow 100000000-109000000 0ms
Sum 1ms

dcc m.pas
Borland Delphi for Linux Version 14.5
Grow 0-9000000 0ms
Grow 10000000-19000000 0ms
Grow 20000000-29000000 0ms
Grow 30000000-39000000 0ms
Grow 40000000-49000000 0ms
Grow 50000000-59000000 0ms
Grow 60000000-69000000 0ms
Grow 70000000-79000000 0ms
Grow 80000000-89000000 0ms
Grow 90000000-99000000 0ms
Grow 100000000-109000000 0ms
Sum 2ms

fpc m.pas
Free Pascal Compiler version 2.7.1 [2013/12/27] for i386 Target OS: Win32 for i386
Grow 0-9000000 47ms
Grow 10000000-19000000 157ms
Grow 20000000-29000000 359ms
Grow 30000000-39000000 531ms
Grow 40000000-49000000 656ms
Grow 50000000-59000000 797ms
Grow 60000000-69000000 985ms
Grow 70000000-79000000 1109ms
Grow 80000000-89000000 1250ms
Grow 90000000-99000000 1406ms
Grow 100000000-109000000 1532ms
Sum 8829ms

dcc m.pas
Borland Delphi Version 15.0
Grow 0-9000000 16ms
Grow 10000000-19000000 31ms
Grow 20000000-29000000 47ms
Grow 30000000-39000000 47ms
Grow 40000000-49000000 109ms
Grow 50000000-59000000 63ms
Grow 60000000-69000000 62ms
Grow 70000000-79000000 250ms
Grow 80000000-89000000 266ms
Grow 90000000-99000000 94ms
Grow 100000000-109000000 110ms
Sum 1125ms

(Windows is virtual machine)

Is possible to speedup heap manager?

Petr

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

29.04.2014 13:00, Jonas Maebe пишет:

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

Reallocmen checks if there is enough free mem behind. If not it allocates a new mem and copies the content.

The fpc heap manager allocates new mem behind the
already allocated mem. Running two Reallocmem have almost never enough free mem behind and they have to copy often.

cmem leaves more space behind the blocks, so that calling Reallocmen with small increases needs less copies. AFAIK the cmem algorithm depends on OS.

Mattias

On Tue, April 29, 2014 10:30, Petr Kristan wrote:
.
.

I use "inteligent" block increasing. I can optimize program, but why is fpc heap manager to slow? Here is the sample stress program compilable with fpc, delphi and kylix:

.
.

And here are results:

.
.

Is possible to speedup heap manager?

Well, results of your test program on my machine (physical machine, MS Win 7 32-bit) show something different:

Grow 0-9000000 31ms
Grow 10000000-19000000 109ms
Grow 20000000-29000000 172ms
Grow 30000000-39000000 250ms
Grow 40000000-49000000 327ms
Grow 50000000-59000000 406ms
Grow 60000000-69000000 483ms
Grow 70000000-79000000 546ms
Grow 80000000-89000000 625ms
Grow 90000000-99000000 702ms
Grow 100000000-109000000 764ms
Sum 4431ms

(compiled without cmem / without valgrind)

Grow 0-9000000 31ms
Grow 10000000-19000000 125ms
Grow 20000000-29000000 203ms
Grow 30000000-39000000 265ms
Grow 40000000-49000000 375ms
Grow 50000000-59000000 436ms
Grow 60000000-69000000 531ms
Grow 70000000-79000000 624ms
Grow 80000000-89000000 733ms
Grow 90000000-99000000 796ms
Grow 100000000-109000000 873ms
Sum 5008ms

(compiled with -gv; as expected, adding CMem to the uses clause and compiling without -gv gives basically the same result).

Tests performed with trunk compiler based on SVN from about 10 days ago. Results for 2.6.4 are more or less the same.

I don't know the reason of your difference, but no time necessary at all (0 ms) for the valgrind variant looks very suspicious to me.

Tomas

Are you sure that -gv in windows has any effect?
I think, that valgrind can be used only in unix systems. Isn't -gv option silently ignored in windows?

Tests performed with trunk compiler based on SVN from about 10 days ago. Results for 2.6.4 are more or less the same.

Approve, I tested in 2.6. too.

I don't know the reason of your difference, but no time necessary at all (0 ms) for the valgrind variant looks very suspicious to me.

But compiling by kylix compiler, i get the same results as by fpc with -gv option in linux.
This is the reason why I start to hunt where is my program to slow if compiled by fpc against kylix.

Petr

Is possible to tune this space behind the blocks?

Petr

.
.

> Well, results of your test program on my machine (physical machine, MS > Win > 7 32-bit) show something different:

.
.

> Sum 4431ms > > (compiled without cmem / without valgrind)

.
.

Use of CMem instead of the internal FPC heap manager is triggered for -gv regardless of the target platform. In addition, the results for source compiled with CMem added explicitly to the uses clause (without using -gv) are also the same.

Can't it be somehow related to the method used for measuring the time under Linux? Is the result shown inside consistent to the overall time necessary for the program run?

Tomas

[...] Is possible to tune this space behind the blocks?

The space is bad for the processor's caches.
You only need the space behind when you want to grow big chunks in many small steps. Since this does not happen often it is better to change the few places in your code than the whole heap manager.

Just allocate somewhat more than you need.
For example:

if NeededSize>CurrentSize then
begin
  CurrentSize:=Max(NeededSize,CurrentSize+CurrentSize div 2);
  ReAllocMem(p1, CurrentSize);
end;

Mattias

Time measurement appears to be correct. Strace shows that reallocation happens using mremap syscalls, which apparently rearranges pages within address space without actual moving the data. This indeed can be done with almost zero overhead, but is hardly portable.

Regards,
Sergei

Thanks for the fast and perfect explanation.
Resolution for me is that heap manager cannot be multiplatformly improved. I do some optimatization in my code.

Petr