Re: Re: about your concept

Ulrik Mikaelsson wrote:

> 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
>
However, I think what he was trying to say (well, what I'm saying, I 
won't put words in his mouth), is that these considerations of alignment 
are in fact processor/machine/architecture-specific, and therefore don't 
belong in a platform-agnostic network protocol that is to be widely used 
for a long, long time (I'm thinking in terms of the X protocol and how 
widely it was implemented and how long it has lasted here).  When one 
tallies older processors still in active use from various manufacturers, 
the current models all aruond, the known upcomnig future ones, and 
especially the unknown ones, there are myriad possibilities in terms of 
what alignment (if any) is ideal for any given processor.  Therefore it 
shouldn't be a design consideration that we happen to know that a 
certain alignment helps out on certain current processors today.

Brandon