km@emory.uucp (Ken Mandelberg) (09/22/87)
I just built X11R1 and am running it on a Sun 3/50. It runs very slowly (at least xterm does) in fact too slowly to actually use. Is the speed problem one with the Sun server implementation at this stage, or is the Microvax also slow? -- Ken Mandelberg | gatech!emory!km USENET Emory University | km@emory CSNET,BITNET Dept of Math and CS | km.emory@csnet-relay ARPANET Atlanta, Ga 30322 | Phone: (404) 727-7963
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (09/23/87)
Date: 22 Sep 87 13:55:23 GMT
From: bloom-beacon!gatech!gt-eedsp!emory!km@eddie.mit.edu (Ken Mandelberg)
I just built X11R1 and am running it on a Sun 3/50.
It runs very slowly (at least xterm does) in fact too
slowly to actually use.
Is the speed problem one with the Sun server implementation
at this stage, or is the Microvax also slow?
Neither seem particularly slow on a 1-bit frame buffer; it is indeed
slow on a Sun 8-bit frame buffer. Could you perhaps give more precise
quantifications?rusty@VELVEETA.BERKELEY.EDU (Rusty wright) (09/23/87)
Don't forget that as distributed, everything gets compiled with -g; try it with -O instead.
km@emory.uucp (Ken Mandelberg) (09/24/87)
In article <2253@emory.uucp> km@emory.uucp (Ken Mandelberg) writes: >I just built X11R1 and am running it on a Sun 3/50. >It runs very slowly (at least xterm does) in fact too >slowly to actually use. As was suggested, the speed problem was because of the default debug flags in macros.sun. I knew they were there but didn't expect that it would make more than a tiny bit of difference. In practice, turning debugging off made an enormous difference. -- Ken Mandelberg | gatech!emory!km USENET Emory University | km@emory CSNET,BITNET Dept of Math and CS | km.emory@csnet-relay ARPANET Atlanta, Ga 30322 | Phone: (404) 727-7963
jpb@catsim.UUCP (Joel P. Bion) (09/25/87)
We took out the debug flags in Sun.macros in .../util/imake.includes (i.e., changed -g to -O, removed the -DDEBUG) and the performance does indeed seem better on the 3/50, but is still quite poor on our color 3/160. I.e., the output of xterm is very slow; xrefresh takes MUCH (i.e., greater than 15x longer). X10R4 speed on the color 3/160 was fairly good; does anybody know the answer to the question "What happened" and even more important "Will it be fixed". The performance really is quite inferior to the previous release. Thanks for any information in this matter.
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (09/25/87)
X11 is documented to be *slow* in color on Suns (in contrast to the DEC GPX code, which is reasonably fast). This is because Sun took the (desirable) path of trying to provide generic "color frame buffer" code that was hopefully correct, highly portable, and easily reconfigured for use on a variety of color frame buffers. I believe that several other companies have used this code to advantage in getting initial ports up quickly on their hardware. In that sense, Sun has done us a service. However, the code is definitely slow as is. I don't know of any immediate plans for public speed improvements, but we would certainly welcome any contributions in that direction. For Suns in particular, one could certainly dig in and replace various mi and cfb code with pixrect code. Doing just a few crucial things would go a long way. Of course, Sun has said it is working on a combined NeWS/X server as a product, and it will almost certainly be based on different, *fast*, graphics code. I suppose you can talk to your sales rep about "when".