How do you unsususcribe?<br><br>(sorry, I lost the original email instructions)<br><br><b><i>Roy Lyseng <Roy.Lyseng@Sun.COM></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> <br><br>Steve Grimm wrote:<br>> On 7/11/07 12:45 AM, "marc@corky.net" <marc@corky.net> wrote:<br>>> While network byte ordering (Big Endian) is traditionally the 'right'<br>>> thing to do (or the default thing to do), in most cases it's a minor<br>>> performance hit due to constant swapping. Since we're implementing a<br>>> binary protocol specifically to avoid/minimize minor performance hits<br>>> and since this is a brand new protocol I would recommend to keep all<br>>> values as Little Endian because:<br>> <br>> Defining a protocol that uses something other than network byte order gives<br>> me the willies. But I'm not sure I can argue with your reasoning on
anything<br>> more than aesthetic grounds; swapping bytes around unnecessarily is exactly<br>> the sort of thing we're trying to avoid.<br>> <br>> I wonder just what the overhead of byte swapping will be, though, compared<br>> to all the other work that has to happen to handle a request. It may be a<br>> small enough expense to disappear into the statistical noise. If we'd be<br>> saving .001% of the CPU time by avoiding swapping, I'd say forget it, not<br>> worth the confusion. I've never actually measured the cost of using network<br>> byte order in any of my network apps, though, so I honestly have no idea.<br><br>I have not actually measured this, but I do not think this is a problem <br>on modern computers. Getting the bytes into the cache line is probably <br>the biggest time consumer. And unless you rely on an aligned byte <br>offset, you will have to do some byte fiddling anyway.<br>> <br>> If it's a large overhead, maybe we can
make endianness depend on the magic<br>> number at the start of the command. It is annoying to support both, granted,<br>> but that would potentially allow a client to be configured to send requests<br>> and receive responses in whatever format is most efficient for a particular<br>> server. (Or vice versa, I suppose.) Or would the overhead of having to<br>> support both styles eat all the cycles you'd save by not swapping bytes? I'm<br>> not sure.<br>> <br>> I suspect that the Sun folks would appreciate not having to flip bits back<br>> to network byte order on their SPARC boxes, but I agree with you that Intel<br>> and AMD totally dominate memcached's target audience at the moment.<br>> Supporting both orders from the start would insulate us from changes in that<br>> market reality, though maybe that's far enough off that it's better to just<br>> rev the protocol if/when the need arises.<br><br>We deliver AMD and Intel boxes these
days also :)<br><br>However, I would vote for preserving network byte order, because I do <br>not think there is a real gain in switching this strategy, not <br>mentioning having two different strategies in one protocol.<br><br>Roy<br><br>> <br>> -Steve<br>> <br></marc@corky.net></blockquote><br><p> 
<hr size=1>Need a vacation? <a href="http://us.rd.yahoo.com/evt=48256/*http://travel.yahoo.com/;_ylc=X3oDMTFhN2hucjlpBF9TAzk3NDA3NTg5BHBvcwM1BHNlYwNncm91cHMEc2xrA2VtYWlsLW5jbQ--">Get great deals
to amazing places </a>on Yahoo! Travel.