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-----