On 15 May 2012, GreyCloud spake thusly:
> Moron. What part of X server do you not understand??? And why is it so
> much more slower than on a machine that doesn't use X? The X11
> protocol was designed for the network from the very beginning. It
> doesn't mean you have to go thru the network to display a local image
> on an X server... it is just that the server paradigm in this instance
> is slower for display. Far too much overhead.
So. Rather than frothing at the mouth like a bunch of rejects from
comp.os.linux.advocacy, let's benchmark it (facts! figures! things we
fine upstanding fellows in uk.comp.os.linux learned at our mother's
knees). Benching the core protocol is quite easy: x11perf exists to do
exactly that.
The easiest way to benchmark protocol overheads is to look at the
overhead required for a noop request, which exists precisely for this
purpose: it tells us the overhead of serialization, deserialization, and
server protocol handling. All benchmarks were done on a nearly-idle
X.org 1.10 server, with a Radeon HD 4870 running the free drivers.
Local timings, over the Unix-domain socket:
200000000 reps @ 0.0000 msec (21900000.0/sec): X protocol NoOperation
200000000 reps @ 0.0000 msec (21600000.0/sec): X protocol NoOperation
200000000 reps @ 0.0000 msec (21700000.0/sec): X protocol NoOperation
Local timings, over
127.0.0.1:
200000000 reps @ 0.0000 msec (22500000.0/sec): X protocol NoOperation
200000000 reps @ 0.0000 msec (22500000.0/sec): X protocol NoOperation
200000000 reps @ 0.0000 msec (22900000.0/sec): X protocol NoOperation
(actually faster, interesting, obviously TCP/IP is more aggressively
optimized than AF_UNIX these days).
Remote timings, over a gigabit Ethernet link, unencrypted:
100000000 reps @ 0.0001 msec (19300000.0/sec): X protocol NoOperation
100000000 reps @ 0.0001 msec (19300000.0/sec): X protocol NoOperation
100000000 reps @ 0.0001 msec (19200000.0/sec): X protocol NoOperation
(Slightly slower, but not enough for anyone to care about. The link
saw 80000Kb/s of TCP traffic during the benchmark, much of the Gb
link's theoretical max capacity.)
During all these tests, the X server pretty much maxed out one core:
x11perf used about 35% of one core. So it is clear that it is *possible*
to max out the X server CPU-wise just via protocol overhead -- but you
have to do a *hell* of a lot of operations for that. This machine is
only 2.2GHz, so it's coming in at under a thousand clock ticks of
overhead per X protocol message. I'd call that impressive efficiency.
(Of course batching and the like will reduce this overhead even more in
practice.)
What about printing a dot, the simplest possible graphical operation?
(albeit not one much optimized for these days.)
Local:
50000000 reps @ 0.0001 msec (8740000.0/sec): Dot
50000000 reps @ 0.0001 msec (8740000.0/sec): Dot
50000000 reps @ 0.0001 msec (8670000.0/sec): Dot
About a third the speed of a nop. Remote timings are *absolutely
identical* and the link is no longer saturated, suggesting that protocol
and network overheads are relatively insignificant even for the most
trivial operations. (At least one third of the time taken to display a
single pixel is taken up by protocol overheads: it may be more because
the protocol request will be more complex than for a no-op.)
So let's try some core text display, -ftext.
7200000 reps @ 0.0007 msec (1350000.0/sec): Char in 80-char line (6x13)
7200000 reps @ 0.0007 msec (1340000.0/sec): Char in 80-char line (6x13)
7200000 reps @ 0.0007 msec (1340000.0/sec): Char in 80-char line (6x13)
... and the same timings for remote display, and for TCP/IP sockets
locally. Perhaps 6% of the overhead of core text display is accounted
for by protocol overheads.
What about antialiasing? Let's try -aa4trap1, displaying core text and
then antialiasing it (since x11perf can't do render protocol timings):
Local and remote look identical:
800000 reps @ 0.0071 msec (142000.0/sec): Char in 80-char aa core line (Courier 12)
800000 reps @ 0.0072 msec (140000.0/sec): Char in 80-char aa core line (Courier 12)
800000 reps @ 0.0070 msec (142000.0/sec): Char in 80-char aa core line (Courier 12)
142,000 per second. That's a hell of a lot less than the 22 million
no-ops we can do per second, which is the only proportion we can
definitely say is protocol overhead. An overhead of perhaps 0.6% in
fact.
Yep, the server paradigm is simply terrible. Far too much overhead.
It is safe to say that if your argument can be disproved by benchmarking
tools that have been freely available for decades and take five minutes
to install, your argument is not very good. Now maybe the protocol
overhead *is* significant -- it may be that the overhead for text
display is far higher than that for no-op -- but I can't see any
evidence of it here.
--
NULL && (void)