Re: Re: about your concept

-----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. This is consistent 
from what I've learned during the few courses I've taken on non-x86 
architectures. (in fact I think ALL memory-access on some RISC-architectures 
are faster if 4-byte aligned, even strings, but I'm not certain)

I think we can belive that it is correct, or simply look up proof that it is 
NOT the case on any architectures. We can also assume that the 
message-retrieval from socket should be as one big chunk + one small chunk 
first to know the length. (This improves the performance of parsing the 
message, since fewer syscalls are required, compared to read():ing the data 1 
field at a time. Please prove me wrong if you'd like, but make sure it's 
valid for most platforms.)

Now the good thing is that the last time I cared to look at the protocol, 
right after Andrew:s rewrite, most of the integers used in the protocol were 
actually 4-byte aligned. 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. 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. To implement 
this in the server and client is really simple, and if autotools had allowed 
me to compile Y at the moment, I would have attached a patch as well.

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. Quite the opposite, actually. If 
saving bandwidth without care for 4-byte alignment was the goal, 14 bytes 
could easily be cut of the message-header (43.75% of the message-header), as 
well as reduce the overhead of string parameters from 8 bytes to 5 bytes, and 
reduce the overhead on 32-bit integers from 8 bytes to 1 single byte. So 
please, don't say message size is a priority.

I have not looked at the protocol since Andrew did the big swap from 
string-encoded parameters to binary, so if the protocol have changed again 
since then, my argumentation is slightly or completely wrong, in which case I 
apologize for having you read all this.

Regards
/ Ulrik

- -- 
BOFH Excuse #437:

crop circles in the corn shell
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBAVTc069SELtZwIkRAgrhAJ0Q1kRq5yIlkTn8UVtXEyMiD2wQKQCffFwI
oodqqZYFr9qDp+WKU9eBgcc=
=6ILS
-----END PGP SIGNATURE-----