How do you unsususcribe?<br><br>(sorry, I lost the original email instructions)<br><br><b><i>Roy Lyseng &lt;Roy.Lyseng@Sun.COM&gt;</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>&gt; On 7/11/07 12:45 AM, "marc@corky.net" <marc@corky.net> wrote:<br>&gt;&gt; While network byte ordering (Big Endian) is traditionally the 'right'<br>&gt;&gt; thing to do (or the default thing to do), in most cases it's a minor<br>&gt;&gt; performance hit due to constant swapping.  Since we're implementing a<br>&gt;&gt; binary protocol specifically to avoid/minimize minor performance hits<br>&gt;&gt; and since this is a brand new protocol I would recommend to keep all<br>&gt;&gt; values as Little Endian because:<br>&gt; <br>&gt; Defining a protocol that uses something other than network byte order gives<br>&gt; me the willies. But I'm not sure I can argue with your reasoning on
 anything<br>&gt; more than aesthetic grounds; swapping bytes around unnecessarily is exactly<br>&gt; the sort of thing we're trying to avoid.<br>&gt; <br>&gt; I wonder just what the overhead of byte swapping will be, though, compared<br>&gt; to all the other work that has to happen to handle a request. It may be a<br>&gt; small enough expense to disappear into the statistical noise. If we'd be<br>&gt; saving .001% of the CPU time by avoiding swapping, I'd say forget it, not<br>&gt; worth the confusion.  I've never actually measured the cost of using network<br>&gt; 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>&gt; <br>&gt; If it's a large overhead, maybe we can
 make endianness depend on the magic<br>&gt; number at the start of the command. It is annoying to support both, granted,<br>&gt; but that would potentially allow a client to be configured to send requests<br>&gt; and receive responses in whatever format is most efficient for a particular<br>&gt; server. (Or vice versa, I suppose.) Or would the overhead of having to<br>&gt; support both styles eat all the cycles you'd save by not swapping bytes? I'm<br>&gt; not sure.<br>&gt; <br>&gt; I suspect that the Sun folks would appreciate not having to flip bits back<br>&gt; to network byte order on their SPARC boxes, but I agree with you that Intel<br>&gt; and AMD totally dominate memcached's target audience at the moment.<br>&gt; Supporting both orders from the start would insulate us from changes in that<br>&gt; market reality, though maybe that's far enough off that it's better to just<br>&gt; 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>&gt; <br>&gt; -Steve<br>&gt; <br></marc@corky.net></blockquote><br><p>&#32;
      <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.