<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><div><br></div><pre><br>At 2015-10-06 22:54:53,"Steve Borho" <steve@borho.org> wrote:
>On 10/06, chen wrote:
>> 
>> 
>> 
>> At 2015-10-06 21:42:48,"Steve Borho" <steve@borho.org> wrote:
>> >On 10/06, dnyaneshwar@multicorewareinc.com wrote:
>> >> # HG changeset patch
>> >> # User Dnyaneshwar G <dnyaneshwar@multicorewareinc.com>
>> >> # Date 1444107449 -19800
>> >> #      Tue Oct 06 10:27:29 2015 +0530
>> >> # Node ID 93525c471023575d500c912284a3853ee8df8991
>> >> # Parent  f8b8ebdc54578e6735216d8b9abce5ba80c05bd8
>> >> add 64-byte alignment macro, align NR buffer & Encoder class to cache line of 64-byte
>> >
>> >what does this fix or improve?
>> 
>> 64 bytes may improve cache performance, I think we also need Pagr Alignment macro for large buffer
>
>The Encoder class is an odd place to use it, few primitives operate on
>it. I don't object to increasing alignment, but this seems a wierd place
>to start with, without some explanation of why.
>
>We could be allocating picture buffers and other large chunks of memory
>from huge page allocations from the O/S, to save TLB space and enforce a
>64byte alloc alignment. But this is a larger project.
</pre><pre>we had a patch, I hack the x265_align to force large buffer to page bound, I got a little (~5%) improve</pre></div>