Re: [hybi] frame length encoding

[John Tamplin <[e-mail]>]

On Sun, Aug 22, 2010 at 12:22 PM, Shelby Moore <[e-mail]> wrote:

> But I think you are missing my point as follows?
>
> Any ends that have a CPU load problem due to multi-core synchronization
> overhead, may set their maximum size to 125, if eliminating the
> conditional test will improve throughput. The downside is that is a lot of
> fragmentation that would not be necessary for the large source frames.
>

I think it is ridiculous to suggest an implementation would avoid a couple
of conditional tests and instead would fragment a large frame into 125-byte
frames to save CPU - the cost of the doing the fragmentation will dwarf the
few instructions.


> The CPU load problem improves the larger the maximum frame can be, but
> apparently not if there is conditionals in the size. That was the only
> reason I proposed Option 1/15-bit, which gives a maximum frame size of
> 32767 without any conditionals,


There is still a check of whether the value is the flag to indicate an
8-byte length.  Having 2 compares to byte constants and associated branches
instead of 1 compare to a short constant and a branch seems hardly a
significant additional processing requirement.


> and the cost is only adds 1 byte to header
> for frame sizes smaller than 126, and removes 1 byte for the 2% of frame
> sizes between 126 - 32767.
>

Yes, and my point above is that you add a byte in the 98% case and save a
byte for the <2% case, which on average costs at least 0.96 bytes more per
frame.

-- 
John A. Tamplin
Software Engineer (GWT), Google