Re: Re: about your concept

On Fri, Jul 23, 2004 at 08:11:37PM +0200, Ulrik Mikaelsson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Friday 23 July 2004 18.28 skrev Andrew Suffield:
> > > Now, it doesn't break the protocol any more than it already is to have
> > > alignments present. It would make life easier on some CPUs and to my
> > > understanding have no real effect on others since they already have to
> > > find the boundaries.
> > It would not make life easier on anything. Either it would do nothing
> > but waste bytes, by design, or it would break the protocol, depending
> > on how it was specified. The only reasonable interpretation is the
> > latter.

> Isn't it possible that your interpretation are incorrect? Or do yoy doubt the 
> effect non-aligned memory has on some architectures? If I understand it 
> correctly, accessing integers on RISC-architectures is a LOT faster if the 
> integer is aligned properly to an even 4-byte address.

See, that's the sort of stuff we had last time around. It's
*irrelevant* (it's also wrong; there is nothing magic about the number
4). This is a *stream*. There is *no* alignment. This is not a
datagram protocol. There are *no* performance problems related to
alignment, nor is it easy to rewrite the code in a fashion that would
introduce any, let alone make it work afterwards.

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

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

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

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

> Then of course there is the problem of wasting bytes on non-RISC 
> architectures, but as someone said, I don't think network bandwidth is our 
> greatest enemy. Besides, the protocol from the last time I looked at it 
> wasn't exactly bandwidth-conservative.

Right, it's designed to maximise encoding and decoding speed.


This is a spectacularly good example of a useless contribution. It
demonstrates a singular lack of understanding of what currently
exists, or how to go about writing sane wire protocols and code to
handle them. It's a form of cargo-cult programming.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBAXlOlpK98RSteX8RAnZRAJ9UGnxtRYX74tUWhM507PWlut75rwCfTgsM
/PUnH9X4DsIBZA2sAkWcwHI=
=WYbx
-----END PGP SIGNATURE-----