IMO compiler messages slow down compilation a lot. When messages are not really output (prevented by message level...), then a lot of procedure calls and string operations can be avoided, when the message preparation is ff. could check the level (and exit accordingly) prior to any further work.

MayBeLoadMessageFile could be moved into Msg2Comment in most cases, and again a quick check (or inline) can prevent calling this

Op Wed, 14 Jul 2010, schreef Hans-Peter Diettrich:

IMO compiler messages slow down compilation a lot.

How do you know this, did you benchmark or is it just your opinion?

another question. Anyway, simply write a patch, could be a nice excercise to get started with compiler development.

Daniël

> IMO compiler messages slow down compilation a lot. How do you know this, did you benchmark or is it just your opinion?

Common knowledge, proved by experience.

[...]

Sounds reasonable to me, but wether it will speed up compilation is another question. Anyway, simply write a patch,

It's not a matter of an "simple" patch :-(

The message ID has to be re-encoded in a way, that allows to determine e.g. the message level immediately. All this currently is done only after text substitution, by inspection of the returned string.

could be a nice excercise to get started with compiler development.

How is message encoding and composition related to compiler development?

DoDi

I had benchmarked that, and submitted some patching some (already long) time ago. Those patches inserted calls to CheckVerbosity before blocks of messages of rarely used verbosity, like V_Tried. This way it was possible to get rid of majority of rarely seen messages, while struggling with more common verbosities seems impractical (those are few anyway).

Message processing indeed includes some overhead, but this is not #1 bottleneck to worry about. Maybe #10 or so. Most processing is done in shortstrings, which is fast.

Regards,
Sergei

Please profile the compiler first, people did this already.

The message ID has to be re-encoded in a way, that allows to determine e.g. the message level immediately. All this currently is done only after text substitution, by inspection of the returned string.

This cannot be done because people should have the chance to use custom error files to override message verbosities.

Op 2010-07-14 17:17, Daniël Mantione het geskryf:

> IMO compiler messages slow down compilation a lot. How do you know this, did you benchmark or is it just your opinion?

A few weeks ago, I benchmarked that too (well similar). I did a comparison between Kylix 3 and FPC 2.4.x. When I disabled all compiler message output, FPC compiled the test apps a bit faster that with -va parameter. It wasn't an exhaustive test by any means, but there was a difference. So I would imagine Hans has a point, that removing any calls to message output would reduce compilation even more.

Regards,
- Graeme -

Op 2010-07-15 06:26, Sergei Gorelkin het geskryf:

Message processing indeed includes some overhead, but this is not #1 bottleneck to worry about. Maybe #10 or so.

Well, any optimization is better than none. Irrespective of where you rank it, one has to start somewhere.

Regards,
- Graeme -

Graeme Geldenhuys wrote on Thu, 15 Jul 2010:

Well, any optimization is better than none.

That's only true if it does not impact clarity or maintainability. Otherwise there is a tradeoff to be made in favour of one or the other.

Jonas

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

Op 2010-07-15 14:18, Jonas Maebe het geskryf:

That's only true if it does not impact clarity or maintainability. Otherwise there is a tradeoff to be made in favour of one or the other.

True, but I don't think we are talking about optimization like changing Object Pascal code to ASM. The original poster (as far as I can tell) simply meant that checking for verbosity or whatever before generating message output. So message calls are only generated/used when really needed.

This seems like a simple enough optimization without impacting clarity.

Regards,
- Graeme -

I think that it is more the actual syscalls to write info which make the difference than the preparation of the syscall. If you wrote output to the terminal, then that is an additional slowing-down factor.

The only way to test the impact of message preparation is to uncomment the actual write call, compile with -va and then compile again (clean) with -v0.

Michael.

That should of course be 'comment out'...

Michael.

actual write call, compile with -va and then compile again (clean) with -v0. Michael.

Graeme Geldenhuys wrote on Thu, 15 Jul 2010: > Well, any optimization is better than none.

And before doing a lot of guess work: it is already known that e.g. fillchar is a bottleneck (probably not only for the compiler). So better mail the fastcode coders if we get permission to integrated the fastcode fillchar routines into fpc. This is not that hard, just look how this is down for move.

I had benchmarked that, and submitted some patching some (already long) time ago. Those patches inserted calls to CheckVerbosity before blocks of messages of rarely used verbosity, like V_Tried.

But the patches have been rejected? For what reason?

This way it was possible to get rid of majority of rarely seen messages, while struggling with more common verbosities seems impractical (those are few anyway).

That's just what I also had in mind.

Message processing indeed includes some overhead, but this is not #1 bottleneck to worry about. Maybe #10 or so. Most processing is done in shortstrings, which is fast.

Perhaps I'm too much concentrated on an general parser. In an compiler (and for OPL) the parser overhead may be not so high.

DoDi

This is what I'm going to do now.

Does there exist some profiling code already, or do I have to reinvent the wheel?

Couldn't this be delegated to an custom message handler?

DoDi

Op Thu, 15 Jul 2010, schreef Hans-Peter Diettrich:

This is what I'm going to do now. Does there exist some profiling code already, or do I have to reinvent the wheel?

No, simply use the -pg compiler option, the use gprof.

Daniël

Have I misunderstood something, or is this optimization really just about the fact that message loading is not necessary if the compiler is requested to output no messages at all? Even if this (probably extremely rare!) case happens, the difference must be completely negligible unless you perform very many compilations of simple and short source files without further dependencies (which doesn't sound like a typical use case to me ;-) ), right?

Tomas

Hans-Peter Diettrich wrote

Florian Klaempfl schrieb:

.
.

Not sure if I understand here. Do you mean that instead of changing few letters in the message file such people would need to write their own message handler and recompile the compiler for using it?

Tomas

Hans-Peter Diettrich wrote

But the patches have been rejected? For what reason?

They have been applied in revision 9297.

Regards,
Sergei

Tomas Hajny пишет:

The issue was that, whenever compiler needs to output a message, it:
- loads a messagefile (once in a session)
- looks up the message by number
- performs the parameter substitution (this involves AnsiStrings, so is somewhat heavy)
- only then checks if it should really print the resulting string.

The most amount of messages come from unit search; the system units are loaded every time, so you always have about several thousands messages loaded and discarded. This was taking a noticeable amount of executed CPU instructions (profiled with Valgrind). With the patch applied in r9297, I was able to cut the total number of executed instructions down by 20%, but that gave no increase in perceived speed of compilation. So I decided not to put much more effort to this issue.

Although, modifying the messaging system in a way when CheckVerbosity() is called as soon as possible (before parameter substitution and other processing) could be beneficial.

Regards,
Sergei

I usually use callgrind together with kcachegrind (code needs to be compiled with -gv).

This would be one solution.

Another one would interpret (such) message files once, on load, to extract the required information from them.

DoDi

This is just what I concluded from a quick glance at the implementation.

With the patch applied in r9297, I was able to cut the total number of executed instructions down by 20%, but that gave no increase in perceived speed of compilation. So I decided not to put much more effort to this issue.

Good to know :-)

I think that it's time to put aside old experience, and replace it by up-to-date performance considerations. And since FPC seems to be optimized and tested very well, even if it doesn't look so at the first glance, I better concentrate on other tasks.

Although, modifying the messaging system in a way when CheckVerbosity() is called as soon as possible (before parameter substitution and other processing) could be beneficial.

Then at least one can be sure that the mentioned overhead can not occur any more.

DoDi

Tomas Hajny wrote

requested to output no messages at all? Even if this (probably extremely rare!) case happens, the difference must be completely negligible unless you perform very many compilations of simple and short source files

Our one project alone has over 250 units/forms with complex unit dependencies. This excludes 2 large external frameworks (also implemented in Object Pascal) that we pull in as well during compilation - we depend on them for certain functionality. I also tend to always build _all_ units, because I have been bitten enough times with source code changes which didn't trigger unit recompiles for some reason, and then waist my time debugging something that doesn't actually need debugging.

So yes, anything to improve compiler speed is always welcomed by me. I miss the speed of Kylix or Delphi. And before somebody jumps on me, yes I know FPC has a different design because it supports multiple platforms and architectures - maintainability is more important to the core team that speed.

Op Thu, 15 Jul 2010, schreef Graeme Geldenhuys:

maintainability is more important to the core team that speed.

No. That is doesn't do justice to all the effort that is put into performance optimization. It's not about maintainability being more important.

It is about making the right trade-offs between:
- Compiler speed
- Compiler memory usage
- Generated code quality
- Compiler portability
- And indeed compiler maintainability.

Compiler speed can loose from maintainability, but it can also loose from code quality; the performance of your application is probably also worth a lot to you.

Nevertheless contest the idea that FPC is a slow compiler, I have put a lot of effort in optimizing compiler speed over the years. I work with many compilers daily, including GCC, Pathscale, Intel, Portland Group. FPC wins from all of these compilers by orders of magnitude.

Last week I compiled OpenFOAM, a fluid dynamics software written in C++, with the Intel compiler. It took 9 hours for 110 megabytes of source code. FPC compiles such an amount of code in a few minutes... The fact it can do that can be attributed to the Pascal unit system (compared to include headers), but just as much to the choice of smart algorithms and datastrures and a tons of local code optimizations that were coded over many years.

Daniël

One of the bottlenecks the common user encounters, is unit loading: especially projects like the lazarus suffer from the time spent into unit loading while I suspect that it narrows down also to procedures like fillchar which consume a lot of time.

Op 2010-07-15 23:50, Daniël Mantione het geskryf:

This is kind of what I meant, I just put it in much simpler terms. Sorry if my earlier statement caused offence.

Nevertheless contest the idea that FPC is a slow compiler, I have put a

I never said FPC is slow, just that it is "slower" than Kylix and Delphi - but I also tried to explained why it is slower. I do know and acknoledge that FPC is MUCH faster than many other language compilers out there. A testament to the great work you guys hove done.

Regards,
- Graeme -

Daniël Mantione wrote

Compiler speed can loose from maintainability, but it can also loose from code quality; the performance of your application is probably also worth a lot to you.

Does FPC compile significantly faster when using -O- then?

Micha

Op Fri, 16 Jul 2010, schreef Micha Nelissen:

That is irrelevant; for example the register allocator made the compiler slower (initially even 3 times, but we managed to reduce it to a few ten %), but had great effects on code quality.

The most expensive optimization you can effect with -O is the assembler optimizer, this is noticable in compilation speed.

However, debug info is for example something that affects speed more.

Daniël

What do you mean with code quality then? I thought performance of the generated code.

Micha

Op Fri, 16 Jul 2010, schreef Micha Nelissen:

Then we are thinking the same :)

The register allocator sacrified compiler speed for code quality. 2.0 generates much better code than 1.0.

Also there were lots of bugs due to runing out of registers before, the register allocator dealt with that problem once and forever, so you can also say we sacrified compiler speed for compiler reliability.

Daniël

Florian Klaempfl wrote on Fri, 16 Jul 2010:

One of the bottlenecks the common user encounters, is unit loading: especially projects like the lazarus suffer from the time spent into unit loading while I suspect that it narrows down also to procedures like fillchar which consume a lot of time.

The main slowdown when recompiling projects is that FPC often recompiles or re-resolves the same unit multiple times when a unit in its uses clause has changed. The ppu loading itself is quite fast. Recompiling Lazarus without changing any unit just takes 2.2 seconds on my machine (without assembling/linking). Compiling program using all units from the packages dir (910 units) takes 4.4 seconds (without assembling/linking).

The following result is from compiling a program that uses 348 (precompiled) units from the packages tree on darwin/x86-64 and lists all functions taking up 1% or more of the total execution time (sample-based). I didn't use all units here because then my laptop does not keep all ppu files in the disk cache during the profiling and that obviously skews the results.

7.6% mach_kernel vm_map_enter
4.0% ppcx48 FPC_MOVE
3.9% ppcx48 CCLASSES_FPHASH$SHORTSTRING$$LONGWORD
3.6% mach_kernel blkclr
3.1% mach_kernel vm_map_lookup_entry
2.4% ppcx48 SYSTEM_SYSGETMEM_FIXED$QWORD$$POINTER
1.9% ppcx48 SYSTEM_SYSFREEMEM_FIXED$PFREELISTS$PMEMCHUNK_FIXED$$QWORD 1.8% mach_kernel ml_set_interrupts_enabled
1.7% ppcx48 SYSTEM_ALLOC_OSCHUNK$PFREELISTS$QWORD$QWORD$$POINTER 1.7% mach_kernel lo_alltraps
1.6% ppcx48 FPC_ANSISTR_DECR_REF
1.5% libSystem.B.dylib __bzero
1.4% ppcx48 SYSTEM_SYSFREEMEM$POINTER$$QWORD
1.4% ppcx48 fpc_pushexceptaddr
1.2% ppcx48 SYSTEM_REMOVE_FREED_FIXED_CHUNKS$POSCHUNK 1.1% ppcx48 CCLASSES_TDYNAMICARRAY_$__READ$formal$LONGWORD$$LONGWORD 1.1% ppcx48 SYMTYPE_TDEREF_$__RESOLVE$$TOBJECT
1.1% mach_kernel pmap_enter
1.1% ppcx48 fpc_popaddrstack
1.1% ppcx48 SYSTEM_TOBJECT_$__NEWINSTANCE$$TOBJECT 1.1% mach_kernel pmap_remove_range
1.0% mach_kernel cache_lookup_path

vmmap_enter is from mmap. This can be improved by increasing the blocksize used to initialise pools for small blocks from 32Kb to 256Kb (to support this for 32 bit systems, fixedoffsetshift in rtl/inc/heap.inc has to be changed from 16 to 12, which is no problem since only the 4 lowest bits are currently used for flags).

5.1% ppcx49 FPC_MOVE // source: 1.3% fpc_shortstr_to_shortstr, 1.1% ppufile.readdata, 0.5% fpc_ansistr_copy
3.7% mach_kernel blkclr // kernel zeroing pages when we mmap memory and it has no reserve zeroed pages
3.6% ppcx49 SYSTEM_SYSGETMEM_FIXED$QWORD$$POINTER
3.5% ppcx49 CCLASSES_FPHASH$SHORTSTRING$$LONGWORD
2.2% ppcx49 SYSTEM_SYSFREEMEM_FIXED$PFREELISTS$PMEMCHUNK_FIXED$$QWORD 2.1% libSystem.B.dylib __bzero // fillchar(0)
2.0% ppcx49 SYSTEM_REMOVE_FREED_FIXED_CHUNKS$POSCHUNK 1.9% ppcx49 SYSTEM_ALLOC_OSCHUNK$PFREELISTS$QWORD$QWORD$$POINTER 1.8% ppcx49 FPC_ANSISTR_DECR_REF
1.8% ppcx49 SYSTEM_SYSFREEMEM$POINTER$$QWORD
1.7% mach_kernel lo_alltraps
1.6% mach_kernel ml_set_interrupts_enabled
1.4% ppcx49 SYMTYPE_TDEREF_$__RESOLVE$$TOBJECT
1.4% mach_kernel pmap_enter // page fault
1.4% ppcx49 fpc_pushexceptaddr
1.4% ppcx49 SYSUTILS_COMPARETEXT$ANSISTRING$ANSISTRING$$LONGINT 1.2% mach_kernel pmap_remove_range // munmap
1.1% ppcx49 PPU_TPPUFILE_$__GETBYTE$$BYTE
1.1% ppcx49 CCLASSES_TFPHASHLIST_$__INTERNALFIND$LONGWORD$SHORTSTRING$LONGINT$$LONGINT 1.1% mach_kernel vm_page_lookup // page fault
1.1% ppcx49 SYSTEM_SETJMP$JMP_BUF$$LONGINT
1.0% ppcx49 FPC_MOVE
1.0% mach_kernel vm_map_enter // mmap
1.0% ppcx49 SYSTEM_TOBJECT_$__NEWINSTANCE$$TOBJECT 1.0% ppcx49 SYSTEM_SYSGETMEM_VAR$QWORD$$POINTER
1.0% ppcx49 fpc_varset_add_sets
1.0% ppcx49 FPC_SHORTSTR_COMPARE_EQUAL
1.0% ppcx49 fpc_ansistr_setlength

In real time (without assembling/linking):

Before After
user 0m1.621s user 0m1.636s
sys 0m0.791s sys 0m0.492s

Total memory usage barely changes (from 297MB to 299MB). 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.

Jonas

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

Jonas Maebe wrote

Total memory usage barely changes (from 297MB to 299MB). I guess it's no

For the compiler use case .. ;-) Perhaps the compiler creates a lot of same sized blocks, while other (smaller) applications allocate many different sizes; say use a lot of different sizes classes.

Do you mean to change this in heap.inc or in the compiler startup?

256kB on 297MB isn't much; but if a program has typical memory use of e.g. 3MB it is significant ;-).

Micha

Micha Nelissen wrote

Jonas Maebe wrote: > Total memory usage barely changes (from 297MB to 299MB). I guess it's no For the compiler use case .. ;-) Perhaps the compiler creates a lot of same sized blocks, while other (smaller) applications allocate many different sizes; say use a lot of different sizes classes.

It seems more likely to me that large applications would contain more different-sized classes than small applications. At least the compiler contains a lot of differently-sized memory structures.

Do you mean to change this in heap.inc or in the compiler startup?

In heap.inc.

256kB on 297MB isn't much; but if a program has typical memory use of e.g. 3MB it is significant ;-).

They could still change it in their application's startup code. We could also set a different default for the embedded rtl.

Jonas

Jonas Maebe wrote

> 256kB on 297MB isn't much; but if a program has typical memory use of e.g. 3MB it is significant ;-). They could still change it in their application's startup code. We could also set a different default for the embedded rtl.

I think applications using 300MB+ are the exception, not the rule; so it should be other way around. Let the compiler make it bigger.

Micha

In our previous episode, Micha Nelissen said:

> > They could still change it in their application's startup code. We could also set a different default for the embedded rtl. I think applications using 300MB+ are the exception, not the rule;

In absolute numbers: sure. In cases where memory management performance is limiting, they are more likely to be memory intensive apps.

How do you know?

Micha

Might be windows related (file searching) ...

All applications but the ones that allocate a only few memory blocks (especially in case it's a few small blocks of many different sizes) would benefit from this change, not just apps allocating hundreds of megabytes at the same time (it also helps in case applications maximally use 10MB, but allocate and free a lot of data so the blocks get released back to the OS). Applications allocating a ton of them would obviously benefit more than others.

Jonas

In our previous episode, Micha Nelissen said:
[ Charset ISO-8859-1 unsupported, converting... ]

The ones that benefit measurably a lot create *lots* of objects. Bigger apps are more likely to allocate many objects.

It is not a hard rule of course, specially, if you see the practice (like on an avg Delphi forum), where people load gigantic db exports with TStringsList.loadfromfile, eating twice the memory than the file is big, with two allocations or so per line.

Jonas Maebe wrote

All applications but the ones that allocate a only few memory blocks (especially in case it's a few small blocks of many different sizes) would benefit from this change, not just apps allocating hundreds of megabytes at the same time (it also helps in case applications maximally use 10MB, but allocate and free a lot of data so the blocks get released back to the OS). Applications allocating a ton of them would obviously benefit more than others.

So why 256kb? not 64, 128, or 512kb?

Specific apps can change the size according to their expected pattern, the default should be conservative.

Micha

Micha Nelissen wrote

Jonas Maebe wrote: > All applications but the ones that allocate a only few memory blocks (especially in case it's a few small blocks of many different sizes) would benefit from this change, not just apps allocating hundreds of megabytes at the same time (it also helps in case applications maximally use 10MB, but allocate and free a lot of data so the blocks get released back to the OS). Applications allocating a ton of them would obviously benefit more than others. So why 256kb? not 64, 128, or 512kb?

I've now committed a dynamic scheme that starts of with chunks of 32KiB, but which grows the chunk size (per thread) as more and more get allocated (up to a limit of 256KiB). The speed is only slightly lower than when starting of immediately with 256KiB blocks, and for apps performing only a few allocations nothing changes regarding the amount of memory they use.

The 256KiB upper limit comes from benchmarking the compiler both when compiling itself (average scenario, mixed allocations and frees) and the "all packages units" (extreme scenario). Going higher did not provide noticeable speed gains while increasing memory usage quite a bit. The same goes for the limit of when the size of the chunks to allocate is doubled.

Jonas