rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (05/02/90)
Our Stardent GS 1000 (Stellar GS 1000) uses shared memory and we have a
flipbook image which uses GetImage and PutImage to flip over 200 half
megabyte images per second. Try that with sockets.
This example is not to the main point. In R4 we have an experimental
extension which uses shared memory for GetImage and PutImage; it doesn't
require a full shared-memory transport to deal with these requests, and
in fact it is more appropriate to special-case these requests. In a
normal transport, even when it's shared-memory, the PutImage request
still has to copy from the "source" into the shared-memory transport
buffer, which is an expensive operation. Better to just put the image
itself in shared memory, and send a pointer to it, which is what our
extension does.
I think the question more directly was, excepting image data transfer,
does the use of a shared memory transport buy you significant performance
for the core X protocol over other local transports? In our (limited)
experience, it buys little.billkatt@CAEN.ENGIN.UMICH.EDU (Steve Bollinger) (05/03/90)
>From: rws@expo.lcs.mit.edu (Bob Scheifler) > Our Stardent GS 1000 (Stellar GS 1000) uses shared memory and we have a > flipbook image which uses GetImage and PutImage to flip over 200 half > megabyte images per second. Try that with sockets. >This example is not to the main point. In R4 we have an experimental >extension which uses shared memory for GetImage and PutImage; it doesn't >require a full shared-memory transport to deal with these requests, and >in fact it is more appropriate to special-case these requests. In a >normal transport, even when it's shared-memory, the PutImage request >still has to copy from the "source" into the shared-memory transport >buffer, which is an expensive operation. Better to just put the image >itself in shared memory, and send a pointer to it, which is what our >extension does. Ahh.. Yes, the Stellar uses a setup with just a shared memory connection, with copying and such instead of sockets, not like your experimental extension. I would say that images are going to be a bigger and bigger percentage of the data used in X, with the visualization explosion. It would be a good idea to get a jump on anything which does speed them up. Heck, I think the most significant addition to X in the near future will be when bitmaps are compressed and expanded using that new standard (20 & 40 : 1) before being sent over the network. This won't speed up local stuff, but a lot of what people do with X lately is across networks from fast machine to slow ones. -Steve Bollinger
jg@max.crl.dec.com (Jim Gettys) (05/04/90)
And comparing tracking between a Sun machine (any flavor) and a VAX/DECstation is fraught with dangers.... For example, Digital spends the $10 for cursor hardware, and Sun does not spend it; this makes a big difference in tracking situations. (as to the explanation of why, I leave it to the advanced student....) Also, the DEC device driver interface to the server (shared memory event queue) helps tracking applications alot. A number of other companies (in addition to Digital) implement this form of interface. If your manufacturer doesn't, you should ask them to. (I haven't flamed in public about this for several years, maybe I should loose another tirade on what/why this is a good idea... System calls are evil, and all that... It got us good tracking on poor .5 mip 11/750's on VS100's many moons ago....). So you must be careful in analyzing what is going on here.... It often has little or nothing to do with transport. - Jim