Are system calls sometimes costlier than library calls?

[Charlie Gordon]

Some gcc's (the one have to hand) can't be stopped from doing it -- at
least it seems to do it even with no optimisation turn on.

My guess is they found a simple way to shine on comparison charts for some
of the simpler tests, such as "total code size in statically linked
executable for simple hello.c". But static linking has become pretty rare
these days.

 

[Ben Bacarisse]

My guess is they found a simple way to shine on comparison charts for some
of the simpler tests, such as "total code size in statically linked
executable for simple hello.c". But static linking has become pretty rare
these days.

That's a thought but it is not currently true in my hosted set up:

$ ls -l t.o t2.o
-rw-r--r-- 1 ben ben 864 Nov 9 01:31 t.o
-rw-r--r-- 1 ben ben 888 Nov 9 13:45 t2.o
$ ls -l t t2
-rwxr-xr-x 1 ben ben 475988 Nov 9 13:44 t
-rwxr-xr-x 1 ben ben 475476 Nov 9 13:45 t2
$ nm t.o t2.o

t.o:
00000000 T main
U puts

t2.o:
00000000 T main
U printf

They both have all the printf machinery linked in but it seems puts is
longer than the one-line wrapper that printf probably requires.
Something in the start-up or exit code path must require formatted
printed in this set up. The motivation may have come from embedded
uses, or some earlier version where this could be avoided, so your
idea is quite reasonable.

 

[Charlie Gordon]

That's a thought but it is not currently true in my hosted set up:

$ ls -l t.o t2.o
-rw-r--r-- 1 ben ben 864 Nov 9 01:31 t.o
-rw-r--r-- 1 ben ben 888 Nov 9 13:45 t2.o
$ ls -l t t2
-rwxr-xr-x 1 ben ben 475988 Nov 9 13:44 t
-rwxr-xr-x 1 ben ben 475476 Nov 9 13:45 t2
$ nm t.o t2.o

t.o:
00000000 T main
U puts

t2.o:
00000000 T main
U printf

They both have all the printf machinery linked in but it seems puts is
longer than the one-line wrapper that printf probably requires.
Something in the start-up or exit code path must require formatted
printed in this set up. The motivation may have come from embedded
uses, or some earlier version where this could be avoided, so your
idea is quite reasonable.

Here I get a 537k statically linked executable with a ton of link time
warnings. It is so sad the Gnu libc has turned into so much bloated useless
crap. hello.c should compile to just a few kilobytes of executable image
with everything linked in and just the system call interface. How bad is it
on the BSD font?

 

[Eric Sosman]

Charlie Gordon wrote On 11/08/07 18:16,:

Which compiler was that?
Did it expand less trivial printf formats into a series of explicit calls to
conversion functions?

It was a Digital compiler, but I'm not sure which one;
I mis-spoke (mis-wrote?) when I said I had "seen" it, not
having verified it for myself. However, I worked alongside
and had multiple bull sessions with a guy who had been part
of Digital's compiler development team, and it was he who
told me of the substitution. It seems that some benchmark
or other used a lot of printf() calls to output string
constants, and profiling had showed that printf() was
spending a lot of time inspecting all those strings to
find the conversion specifiers they didn't contain. So
DEC (said my ex-DEC acquaintance) special-cased the code
generation for printf() and fprintf() -- don't know about
sprintf() -- to avoid the scanning when it was provably
unnecessary. He didn't tell me whether or how much this
improved their benchmark score.

He didn't mention any fancier transformations. It's
easy to see difficulties in doing such things; e.g.

printf ("Hello, %s%c\n", hailedThing, punctuation);

is not quite equivalent to

fputs ("Hello, ", stdout);
fputs (hailedThing, stdout);
putc (punctuation, stdout);
putc ('\n', stdout);

if the second fputs(), say, returns EOF. Such difficulties
aren't insuperable, but dealing with them would be a bigger
project than the simpler substitution. (Guess: The simpler
change was "obviously easy" and well within the scope of a
day's work for one developer; the fancier substitution would
have been large enough to require project reviews, approvals,
test schedules, and all the rest.)

 

[RoS]

In data Fri, 09 Nov 2007 10:58:22 -0500, Eric Sosman scrisse:

It seems that some benchmark
or other used a lot of printf() calls to output string
constants, and profiling had showed that printf() was
spending a lot of time inspecting all those strings to
find the conversion specifiers they didn't contain. So
DEC (said my ex-DEC acquaintance) special-cased the code
generation for printf() and fprintf() -- don't know about
sprintf() -- to avoid the scanning when it was provably
unnecessary. He didn't tell me whether or how much this
improved their benchmark score.

He didn't mention any fancier transformations. It's
easy to see difficulties in doing such things; e.g.

printf ("Hello, %s%c\n", hailedThing, punctuation);

is not quite equivalent to

fputs ("Hello, ", stdout);
fputs (hailedThing, stdout);
putc (punctuation, stdout);
putc ('\n', stdout);

if the second fputs(), say, returns EOF. Such difficulties
aren't insuperable, but dealing with them would be a bigger
project than the simpler substitution. (Guess: The simpler
change was "obviously easy" and well within the scope of a
day's work for one developer; the fancier substitution would
have been large enough to require project reviews, approvals,
test schedules, and all the rest.)

if the string is in the boundary of unsigned
probably should be possible to find byte "%" in the vector of unsigned
using the same way in witch strlen() find byte "\0" in one string

se la stringa è allineata alla frontiera degli interi unsigned
si potrebbe probabilmente controllare se vi sono "%" in un vettore di
unsigned
con lo stesso metodo con cui strlen trova un byte "\0" in una stringa