Re: Re: about your concept
Andrew Suffield <[email protected]> Fri, 23 Jul 2004 23:00:05 +0100
| Newsgroups | gmane.comp.graphics.y.devel |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Jul 23, 2004 at 11:44:20PM +0200, Ulrik Mikaelsson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Friday 23 July 2004 22.47 skrev Andrew Suffield: > > > We can also assume that the > > > message-retrieval from socket should be as one big chunk + one small > > > chunk first to know the length. > > No, that's (a) a performance disaster, (b) not possible on unix, and > > (c) not how the code works. > (a) Are you saying exceuting unnecessary syscalls (such as read) is not > performance impact Invalid assumption. They're not unnecessary. > (b) Why not possible on unix? man 2 read > (c) No, I see you've got a better solution, buffering data to read the entire > message from socket in 1 big chunk (unless the message is fragmented on > socket-level with big timeout, which could not have been avoided anyways). Parse error. > > > The only case I can see, where breaking alignment is > > > possible, is if there is a string parameter that is not exactly 4 bytes > > > in length. > > ...or when you are on a system with 8-byte alignment. The whole thing > > is stupid and pointless, it's an exercise in targetting one specific > > piece of hardware at the expense of all others. > That part is true. I don't know if there today is any 8-byte aligned > architectures, but as Brandon pointed out, there might be, or might be in the > future. There are. > > > So if we added an explicit rule, that each parameter should always > > > start at 4 bytes aligned offset from message start, the entire problem > > > would be solved, allowing better performance on RISC architectures. > > Only it would really just slow them down a little some of the time, > > and otherwise have no effect. You don't have any clue how the code > > works, do you? > Actually, on a pentium-class x86 or above, or on any other pipelined > architecture, I don't think there would be any performance-hit at all, and if > we did agree on the 4-byte alignment on some RISC, and it's performance > impact of addressing int:s, there would be a few systems that would benefit > from it. No. One more time, more clearly: THERE ARE NO ALIGNMENT BUGS IN THE Y PROTOCOL PARSER. ADJUSTING THE ALIGNMENT WOULD NOT IMPROVE PERFORMANCE. > > > To implement > > > this in the server and client is really simple > > s/simple/hard/, you'd have to completely rewrite the socket code and > > break it in the process. > Are you so afraid of touching your own code? Actually the only thing you'd > have to touch is messageFromString and it's equivalent in the client-libs. This would not do what you described. It would merely transmit some useless bytes, and have no other effect. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- |
signature.asc
(application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBAYpllpK98RSteX8RAqmYAJ9h0eYRxQf9tvJe87CCUa1eoUT9tgCeM/AG lRojxSo7cTn0oixOEXS2Yls= =Iyh3 -----END PGP SIGNATURE-----