View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0036778||FPC||Compiler||public||2020-03-09 22:55||2020-04-08 23:55|
|Reporter||NoName||Assigned To||Marco van de Voort|
|Summary||0036778: Define FPC_USE_LIBC on Linux by default|
|Description||The define FPC_USE_LIBC isn't set by default for Linux even if libc is always available in a recent version (no issues with non-availability of functions).|
All the information available about this define is from 0001641:0002006 (see below).
The fpc syscall, which is done when define is not defined, slows down the function calls a lot which affects a lot of stuff which is provided by libc (https://www.gnu.org/software/libc/manual/html_node/Function-Index.html).
|Tags||No tags attached.|
|Fixed in Revision|
No idea why it changed '~ 2006' (w/o whitespace) to 'from 0001641:0002006 (see below).' :o
FPC_USE_LIBC was done as a fallback, and quick port solution. It actually originates on FreeBSD, but when the linux RTL was redone, it also got it.
The general consensus is that the syscall binaries are more cross *nix (both distro and distro version) portable, it has nothing to do with availability of libc or not. There some exceptions like Mac OS X, because OS X is quite decent with multiple SDK version support.
Your speed claims are unsubstantiated.
Maybe discuss things with wide consequences like this on the maillist first before filing a bugreport.
Are you sure? Wouldn't say that factor 60 is unsubstantiated
GetTickCount64 fpc 2 494 563 op/sec
GetTickCount64 libc 119 919 893 op/sec
Well, first you didn't mention that in the original report. Second it is only one unrelated call, and third a not very important one, performance wise. Fourth, if for some reason you are for some strange reason performance bound in gettickcount64, you can just import the relevant calls.
Using a syscall based RTL doesn't prevent importing libc functions if the need arises
You don't mean the GetTickCount64 example as a generic proof of your claim, do you? Do you have some real-world applications which show tangible performance increase if using LibC based RTL on Linux?
As far as use of older syscalls is concerned - the possible approaches described on the Wiki page are indeed valid (including the described pros and cons). If a particular old syscall causes issues on newer kernels, it's possible to create either a dynamic solution (with the correctly described drawbacks of slower startup and broken smartlinking), or a static one using a special build of RTL with an IFDEF (again correctly described as resulting in the drawback of broken compatibility of the built binary with older kernel versions). Using LIBC doesn't make a big difference with regard to that (well, you could get both slower startup and incompatibility with older versions at the same time that way, but I wouldn't call that an advantage ;-) ).
Apart from that, FPC_USE_LIBC is available and anybody may decide to recompile FPC RTL this way without forcing the same change to others.
I definitely prefer that FPC_USE_LIBC is *not* set by default as this easily allows a FPC binary to be used on different systems. In fact it easily allows to test different architectures thanks to QEMU's userspace emulation without the need to set up a userspace with libc for that architecture.
Also thanks to the Android target we don't have to fear degradation of the Linux LibC support anymore (which was a potential danger before that target came along) while if we enable FPC_USE_LIBC by default the non-LibC variant would likely degrade.
That said this doesn't stop us from improving functions like GetTickCount64 (or more precisely the syscalls that function uses).
Changing to FPC_USE_LIBC is a momentous change for a single function's performance difference, that is easily worked around. Moreover the bugreport only argues about one thing being faster, without specifying what is good enough and why.
However the big issue is that not much is known about the /detail/ practicalities of FPC_USE_LIBC on Linux. To fix this minor thing, 20 major ones might pop up in packaging for various distributions. The syscall decision was made in times when some distributions (Mandrake) shipped beta libc with all legacy options turned off, while at the same time the last debian stable was half a decade old branch. It is possible that that decision is outdated, BUT
Most knowledge is either old, based on assumptions and/or gut feelings. In practice we simply don't know how many users will get into problems if we change over, and how common these problems are. IOW how portable is a non trivial libc program in practice? Can we work around some of the issues with separate bootstrap compilers that are syscalls only?
So first quite some (non anecdotal) experience would have to be built up with releases built this way (either by FPC releases, or releases prepared by friendly projects). This makes it a multi-year process.
For further discussion I refer you to the maillist and/or forum.
|2020-03-09 22:55||NoName||New Issue|
|2020-03-09 22:59||NoName||Note Added: 0121510|
|2020-03-09 22:59||NoName||Note Edited: 0121510||View Revisions|
|2020-03-09 23:08||Marco van de Voort||Note Added: 0121511|
|2020-03-09 23:09||Marco van de Voort||Note Edited: 0121511||View Revisions|
|2020-03-09 23:10||Marco van de Voort||Note Edited: 0121511||View Revisions|
|2020-03-09 23:11||NoName||Note Added: 0121512|
|2020-03-09 23:54||Marco van de Voort||Note Added: 0121514|
|2020-03-10 00:01||Marco van de Voort||Note Edited: 0121514||View Revisions|
|2020-03-10 00:07||Tomas Hajny||Note Added: 0121516|
|2020-03-10 09:40||Sven Barth||Note Added: 0121525|
|2020-03-10 11:21||Marco van de Voort||Assigned To||=> Marco van de Voort|
|2020-03-10 11:21||Marco van de Voort||Status||new => resolved|
|2020-03-10 11:21||Marco van de Voort||Resolution||open => won't fix|
|2020-03-10 11:21||Marco van de Voort||FPCTarget||=> -|
|2020-03-10 11:21||Marco van de Voort||Note Added: 0121529|
|2020-03-10 11:23||Marco van de Voort||Note Edited: 0121529||View Revisions|
|2020-03-10 11:24||Marco van de Voort||Note Edited: 0121529||View Revisions|
|2020-04-08 23:55||NoName||Status||resolved => closed|