I did some rough + emprical (i.e. non-exhaustive + non-authoritative) tests with the native memory managers of
-- x64 FPC (v2.4.3)/Lazarus (v0.9.29-26670),
-- Delphi (2010),
-- FastMM4 v4.94
-- TopMemory v3.54.

Test application is fairly simple: Using a double-linked list, it generated 1,000,000 nodes and freed them. I repeated these 12 times. I ignored duplicate speed values [also ignored negative resuls, see note 2 below.]

Timing values were obtained by the use of this function:

function GetCPUTicks: Int64;
asm
   RDTSC;
end

FPC timings: 481.88; 483.29; 483.78; 484.37; 484.60; 485.01; 485.88; 487.01; 488.43; 491.07; 492.20; 525.44
FPC average: 489.42

TopMemory timings: 411.83; 412.52; 412.63; 412.83; 413.30; 413.72; 414.00; 414.25; 414.62; 415.94; 416.05; 553.15
TopMemory average: 425.40

Delphi timings: 301.06; 302.19; 302.35; 302.49; 302.62; 302.68; 302.94; 303.74; 304.18; 306.45; 308.02; 309.28
TopMemory average: 304

FastMM4 timings: 279.74; 282.08; 282.26; 282.37; 282.56; 282.76; 282.80; 282.81; 282.97; 283.09; 283.60; 284.18
FastMM4 average: 282.60

Here are the ratios I ended up with.

Delphi/FastMM4 = 1.0757
FPC/Delphi = 1.6099
FPC/FastMM4 = 1.7318
FPC/TopMemory = 1.1504
TopMemory/Delphi = 1.3993
TopMemory/FastMM4 = 1.5053

From these, it's clear that FastMM (latest version) is the fastest.

As far as FPC is concerned, switching to TopMemory would mean a speed loss of %15 --for my test application.

Notes:

1) These were the compiler options used: -MObjFPC -Scghi -O3 -OoREGVAR -gl -WG -vewnhi -l -Fu. -dLCL -dLCLwin32

2) Under FPC I got some negative values between a GetCPUTicks and another one taken later. Even though I ignored those values, I'd love to know why/how that happens.

Adem wrote

I did some rough + emprical (i.e. non-exhaustive + non-authoritative) tests with the native memory managers of -- x64 FPC (v2.4.3)/Lazarus (v0.9.29-26670), -- Delphi (2010),

So this is 32 bit vs 64 bit?

Micha

Windows 7, x64.

Delphi: 32-bit.
FPC: 64-bit.

So one of the most useless benchmarks I ever saw.

That's not a test. A) 32/64 and B) You should test parallelization, i.e. threads over multi processors (pref quadcore or more) to see the effect of topmemory vs the rest.

Try the included test from topmemory. It is in no way biased, but shows what every manamers bottleneck is.

2010/7/17 Adem :

Adam, please repeat your test with 32-bit FPC so we get more even playing field.

Focus of that 'test' was to see how TopMM compares with FastMM (both Delphi only), which turned out that FastMM is 50% faster than TopMemory.

Which, to me at least, significantly reduces TopMM's desirability until I find a massively threaded application to test it with.

About that 64bit/32bit issue..

I don't really see what all that fuss was about.

Here are the timings:

FPC_x64: 489.4
FPC_x86: 632.7
TopMM: 425.4
Delphi: 304.0
FastMM: 282.6

And, these are the ratios:

FPC_x86/FPC_x64 = 1.29
FPC_x86/TopMM: 1.49
FPC_x86/Delphi: 2.08
FPC_x86/FastMM: 2.24

Delphi/FastMM = 1.08
FPC/Delphi = 1.61
FPC/FastMM = 1.73
FPC/TopMM = 1.15
TopMM/Delphi = 1.40
TopMM/FastMM = 1.51

On Windows7_x64, *64bit binary* compiled with FPC runs about *30% faster* than 32bit binary.

I don't have an identical native x86 computer with Windows7_x86 to test, sorry.

Thaddy wrote

That's not a test. A) 32/64 and B)

It's not as if 32bit is faster than 64bit --well, not at least on my machine here; in fact 32bit is 30% slower.

You should test parallelization, i.e. threads over multi processors (pref quadcore or more) to see the effect of topmemory vs the rest.

I have here a Mac Pro w/ 8-cores; 16 GB RAM, running --natively-- Win7 x64. That should be good enough.

Try the included test from topmemory. It is in no way biased, but shows what every manamers bottleneck is.

What 'included test'?

The zip file I got from TopMM's site didn't contain test project.

And, the code I used was this.

Now, I'd like to ask why every now and then (something like 1 in 10) I get a negative value for Time3 under FPC. Delphi never exhibits that behavior.

function GetCPUTicks: Int64;
asm
   RDTSC;
end
procedure TForm1.ButtonPerformanceClick(Sender: TObject);
Const
   MAX_COUNT = 1000000;
var
   Node1: TMyNode;
   Index1: integer;
   Time1: Int64;
   Time2: Int64;
   Time3: Int64;
begin
   Node1 := TMyNode.Create(Nil);
   Time1 := GetCPUTicks;
   Index1 := 0;
   while Index1 < MAX_COUNT do begin
     TMyNode.Create(Node1);
     Inc(Index1);
   end;
   Time2 := GetCPUTicks;
   Time3 := Time2 - Time1;
   MemoPerformance.Lines.Add(Format('Time: %n', [Time3 * 1E-6]));
   Node1.Free;
end;

In our previous episode, Adem said:

Now, I'd like to ask why every now and then (something like 1 in 10) I get a negative value for Time3 under FPC. Delphi never exhibits that behavior.

Afaik Delphi does so too, iirc the timestamp counters can vary lightly per core due to powersaving features that make the core run faster/slower, so if a program moves from one core to the next, this can happen.

Interesting..

Can a running program be shifted to another core under Win7?

Because, all I am doing is clicking a button in running exe --not restarting it.

In our previous episode, Adem said:

Yes.

Because, all I am doing is clicking a button in running exe --not restarting it.

Yes. It can do so to avoid one core getting to hot. (it is not hard to see that that would happen if the OS would only use one core, or if it had really rigid program->core assignments).

IIRC on Windows, the solution is to use queryperformancecounter functions and not rdtsc.

You can see in your code that FPC doesn't do that much with that, so it is nearly certainly not FPC. (and I know the behaviour from Delphi anyway).

This is all OS+CPU.

Marco van de Voort wrote

IIRC on Windows, the solution is to use queryperformancecounter functions and not rdtsc.

I would also recommend to rather use EpikTimer (high precision timer components) than GetTickCount. Results cross multiple systems are less flawed.
In the latest EpikTimer, I refactored the code/packages so it can be used in non-gui applications as well.

On Sat, 17 Jul 2010 14:25:13 +0300, Adem wrote about Re: [fpc-devel] FPC/Delphi/FastMM4/TopMemory speed test:

On a 64-bit system, the return value is in RDX, whereas the RDTSC instruction returns its value in EDX:EAX on both 32-bit and 54-bit systems. This means that your returned value will sometimes contain junk bits, and on other occasions will contain zero bits, when compiled for a 64-bit binary.

Here is the code I use to collect timestamps:

============================= tsc.pas ================================== unit tsc;
{ Unit to access the timestamp counter (TSC) on IA-32 (Pentium and later) processors. }

{ Copyright (C) 2009, David W. Noon }
{ All rights reserved, }

{ This code is released under the GNU Lesser General Public License (LGPL). }

interface
function rdtsc: qword;
implementation

{$asmmode att}
function rdtsc: qword; assembler;
asm
rdtsc
movl %eax,__result
movl %edx,__result+4
end;

end.
========================================================================

The above code has been tested in both 32-bit and 64-bit binaries.

.. which sounds very unlikely to me. Almost all benchmarks so far showed FPC 32 bit being in front of the 64 bit version.

At first, I was suspicious too.

I ran that test four times (12 non-negative samples each time). The results were similar.

BTW, is there some way of having both 32bit and 64bit FPC/Lazarus coexist in the same machine?

I don't want to keep uninstalling one to install and run the other all the time.

Focus of that 'test' was to see how TopMM compares with FastMM (both Delphi only), which turned out that FastMM is 50% faster than TopMemory.

... and FPC:

FPC_x86/FastMM: 2.24

The machine should not matter, but a 32 bit OS instead would be interesting for reasonable figures.

DoDi

And, the code I used was this.

[...]

MemoPerformance.Lines.Add(Format('Time: %n', [Time3 * 1E-6])); Node1.Free; end;

Can you show the time for Node1.Free as well?

Fast allocation can result in slow deallocation...

DoDi

On Sat, 17 Jul 2010 13:02:10 +0100, David W Noon wrote about Re: [fpc-devel] FPC/Delphi/FastMM4/TopMemory speed test:

On a 64-bit system, the return value is in RDX,

^^^
That should be RAX.

Hans-Peter Diettrich wrote

Can you show the time for Node1.Free as well? Fast allocation can result in slow deallocation...

*FPC_x86*
Time to Create: 632.7
Time to Destroy: 471.69

*FPC_x64*
Time to Create: 489.4
Time to Destroy: 468.94

Adem wrote

Test application is fairly simple: Using a double-linked list, it generated 1,000,000 nodes and freed them.

That is virtually the same operation described in http://lists.freepascal.org/lists/fpc-devel/2010-July/020787.html

And as I said at the end: "I guess it's no problem to commit this, but in most cases it probably won't change much if anything performance-wise unless you do almost nothing but allocate tons of small memory blocks without every freeing any in between."

This is a test that only benchmarks one very small aspect of the memory manager. Even with the current RTL code, you can probably already make the test a bit faster by adding this statement to the start of your program code:

growheapsizesmall:=64*1024;

(using larger values will result in a run time error 204 currently)

And as other people have mentioned, your RDTSC function is wrong from 64 bit systems, so you cannot really trust its return values.

Adem wrote

On 2010-07-17 11:15, Thaddy wrote: > You should test parallelization, i.e. threads over multi processors (pref quadcore or more) to see the effect of topmemory vs the rest. I have here a Mac Pro w/ 8-cores; 16 GB RAM, running --natively-- Win7 x64. That should be good enough.

If you only test a single-threaded program, it doesn't really matter how many cores you have. Of course, benchmarking multi-threaded programs is a lot harder, since scheduling factors specific to the program or execution in question can have a large impact (without indicating in any way whether any version is better or worse).

Jonas

Correction.

*FPC_x64* Time to Create: 471.41 Time to Destroy: 300.57

Adem wrote

BTW, is there some way of having both 32bit and 64bit FPC/Lazarus coexist in the same machine?

With Lazarus it is easy. You just compile it and rename the binary. It does not need to be installed.

With FPC you could do two local installations and then switch between two versions of .fpc.cfg file.
This wiki section is for installing FPC trunk into it helps for your configuration.

http://wiki.lazarus.freepascal.org/Getting_Lazarus#Build_and_install_with_make

It may be is possible to use the two versions by some command line switch, without swapping the .cfg files, but I don't know how.

Juha

What about competitors?

DoDi

But it's suggested to invoke both with a different -pcp (--primary-config-path), so that each version can create 32/64 bit applications and use its own (32/64 bit) LCL by default.

With FPC you could do two local installations and then switch between two versions of .fpc.cfg file.

What's the default INSTALL_PREFIX on Windows?

DoDi

Or use macros in the project unit output directory or the project target file name.

That's not needed.
Use fpc.exe and it will call the right compiler. Make sure your fpc.cfg contains macros and the paths are right.

Mattias

Mattias Gaertner wrote

That's not needed. Use fpc.exe and it will call the right compiler. Make sure your fpc.cfg contains macros and the paths are right.

This is what I did:

I installed 32bit version in folder C:/FPC_Lazarus_x86 and 64bit version in C:/FPC_Lazarus_x64, hoping that they would peacefully coexist.

They didn't.

I think the reason why they didn't is because both installations share the same data folder i.e. C:\Users\$username\AppData\Local\lazarus

Hence, both the x86 and x64 versions share the information stored under that folder --which screws up things.

A better solution, IMO, would be to use both the patform and version numbers; so that workdirs become:

C:\Users\$username\AppData\Local\lazarus\0.9.29\win32\2.4.0 C:\Users\$username\AppData\Local\lazarus\0.9.29\win32\2.4.3 C:\Users\$username\AppData\Local\lazarus\0.9.29\win64\2.4.0 C:\Users\$username\AppData\Local\lazarus\0.9.29\win64\2.4.3

etc.

This way, I can have several different versions live under the same $username.

One more thing: Lazarus, when uninstalled, removes neither its install folder, nor its workdir; which it should.

With respect, this is a clumsy and painful way of doing it --at least from where I am much better way, for a Lazarus install, would be to have a (top) folder named Lazarus, and immediate child folders with version numbers.

This way, new version installations wouldn't screw up the older installations --and when you uninstall one version, all of it can get automatically removed without leaving whole folder as residue or affecting other installations.

Again, there's a flaw --IMO-- in the was Lazarus is installed. It should not install FPC as a subfolder. (i.e. 'C:\Lazarus\fpc\2.4.3\' )

It should, instead, install FPC as an equal citizen so that we'd have 'C:\FreePascalCompiler\2.4.3'.

This way, we could have several different versions of Lazarus and FPC residing on the same machine.

This is what I mean:

For Lazarus:

'C:\Lazarus\0.9.27\'
'C:\Lazarus\0.9.28\'
'C:\Lazarus\0.9.29\'

For FPC:

'C:\FreePascalCompiler\2.4.0'
'C:\FreePascalCompiler\2.4.1'
'C:\FreePascalCompiler\2.4.3'
'C:\FreePascalCompiler\2.5.0'

Which means, you can independently install or uninstall any one of these.

Makes life much easier to pick and choose different versions of IDEs and compilers.

You can pick the compiler version you want to use under Lazarus from a combobox in the options window and go.

BTW, do we still have to install Lazarus and FPC under top folders; I mean, can't we safely install them under 'C:\Program Files\' like every other application does under Windows?

The fpc macro values are i386 and x86_64.
For example the fpc.cfg under linux uses paths like this: -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget

When calling fpc(.exe) with -Ti386 it looks for a ppc386(.exe) and starts it. Let's say ppc386.exe is version 2.4.1 ppc386 then searches ppu files in

/usr/lib/fpc/2.4.1/units/i386

Translate this to some windows paths you like and adapt your fpc.cfg.

Keep in mind that Lazarus and FPC are separate things and that only the windows installer puts fpc in a sub directory of the lazarus directory.
You can easily use one lazarus with several fpcs and they can share the same fpc source directory.
All Lazarus packages use macros in their output directories, so that ppus for i386 and x86_64 are in different folders.

Feel free to do so.

One more thing: Lazarus, when uninstalled, removes neither its install folder, nor its workdir; which it should.

I don't know the internals of the windows installer. Maybe Vincent knows.

Mattias

Mattias Gaertner wrote

/usr/lib/fpc/2.4.1/units/i386 Translate this to some windows paths you like and adapt your fpc.cfg.

Quick question. I took a look at 'Installing Lazarus' [ http://wiki.lazarus.freepascal.org/Installing_Lazarus ] and all the examples for paths have no spaces in them.

Indeed, in my fpc.cfg, all paths are spaceless, such as 'c:\Lazarus\fpc\2.4.3/units/$FPCTARGET/'

There's also a special warning against them in the FAQ: "3. Check if the compiler *installation path has spaces* in it. *Make sure it doesn't!*" [ http://wiki.lazarus.freepascal.org/Lazarus_Faq#I_can.27t_compile_Lazarus ]

Is there a fundamental (still valid) reason for not being able to have it something like "c:\Program Files\Lazarus\fpc\2.4.3/units/$FPCTARGET/" at least under Windows?

It goes against everything we're accustomed to these days.

What would it take to remove that limitation, I wonder?

Keep in mind that Lazarus and FPC are separate things and that only the windows installer puts fpc in a sub directory of the lazarus directory.

OK. I usually do my development under Windows and when I have to compile on Linux, I install Lazarus/FPC from a package and not worry about its internals.

You can easily use one lazarus with several fpcs and they can share the same fpc source directory.

I am assuming this is optional. I.e., you can alson opt not to share a common source directory as well.

But, that would mean also altering how Lazarus behaves (under Windows at least). I doubt if I could get past the inertia.
Not knowing who to talk to is immensely discouraging.

> One more thing: Lazarus, when uninstalled, removes neither its install > folder, nor its workdir; which it should. I don't know the internals of the windows installer. Maybe Vincent knows.

My ideal installer would also be able to download only the sources and build them locally --instead of downloading a much bigger binary package.

I wonder if this would be possible. or even generally desirable.

Hi!

If I remember correctly it's not a limitation of FPC itself, but more of the Unix tools (make, etc) it's using. They seem to dislike spaces in paths.

Also using "c:\Program Files" for Lazarus is a bad idea, because that directory is write protected by definition and you still need to rebuild Lazarus if you install a package or the LCL if you patch something.

Do you know about the --primary-config-path=DIR parameter that you can pass to the Lazarus executable? That way you can specify the directory where the IDE is saving the user's configuration files. I'm using it successfully to run multiple versions parallel on Linux (but it works in Windows, too, but you might want to adjust the shortcuts for this). I already asked about a "multiple version aware" installer here: http://bugs.freepascal.org/view.php?id=15813

I prefer it not to uninstall my configuration data (or it should ask whether that should be done), because if I install a newer version I'd need to reconfigure the IDE to my likings again (templates, coding style options) and to open every package I used once again (which is getting on my nerves VERY much).

Regards,
Sven