Path: utzoo!attcan!uunet!husc6!bloom-beacon!CITI.UMICH.EDU!martin
From: martin@CITI.UMICH.EDU
Newsgroups: comp.windows.x
Subject: PURDUE+ patches
Message-ID: <8812190358.AA20033@EXPO.LCS.MIT.EDU>
Date: 19 Dec 88 04:52:40 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 37

Earlier message...

>In the announcement for the PurduePlus fixes it was implied that the
>improvements would only be effective when using gcc. Is this due to
>something intrinsic to gcc or was it just not tested with anything else?
>I am interested in knowing whether PurduePlus has any effect on Suns
>using cc rather than gcc.

Well, the PURDUE+ patches take advantage of the sophisticated asm instruction
(assembler output) to define the hairy getbits/putbits macro combination to be
just two assembler (asm) instructions.  There are one or two improvements
which are machine/compiler independent.  These are:

1) DONAHUE's mfbCopyArea patch (see ./contrib/server/speedups/donahue/README
	or the comment in the patched mfbbitblt.c file)

2) Quicker (unrolled and smarter) mfbBres.c Code. 

3) Some changes to the Terminal Emulator Glyph BLT code.
	NOTE: I think that this is #ifdef'ed for FASTGETBITS which is ifdef'ed
		for (__GNUC__ && (mc68020 || vax))
	But it may still be faster in the general case.  This speedup ors four
	glyphs (width <= 8) into one full word before putting them onto the
	screen.

So I dunno.  I don't have time to check, NOR do I have a program (hint hint)
to benchmark the server.  I can just tell that the thing runs faster.  I get
some poor fool that is used to the vanilla mfb code and I see if they can tell
the difference.  (Not a very good way to test the server for speed)

I suggest that you get GCC 1.31 and use it!  It generates faster and smaller
code than cc anyway.

I am happy to hear that people are actually bagging other window systems for
X11 after seeing these patches.  (Or maybe that was just hype from ohio-state?)

Marty.