<br><br><div><span class="gmail_quote">On 10/9/07, <b class="gmail_sendername">Gabriel Bouvigne</b> <<a href="mailto:gabriel.bouvigne@joost.com">gabriel.bouvigne@joost.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Victor Mateevitsi a écrit :<br><br>> x264_macroblock_cache_load<br>> x264_macroblock_cache_save<br>> x264_macroblock_analyse<br>><br>> Reading cache_load, I realized that there is a struct named cache, that
<br>> stores the cached data.<br>> Why not use pointers in this struct, without having to copy the data<br>> from one struct to the other ?<br>> I think we will gain some FPS there.<br><br>The purpose is to have "compact" data within the CPU cache. If your
<br>source data was already within the CPU cache, copy will be very fast<br>(assuming there is still available space within the cache). If your<br>source data was not already within CPU cache, you will have a slower<br>copy, but future access will be fast. By using pointers, you would have
<br>to use a lot of CPU prefetch hints in order to avoid being stalled<br>because of a cache miss during computing-intensive parts.</blockquote><div><br><br>But using cache data structure, access to the cache is through x264_scan8, which requires a lot of address calculation.
<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">_______________________________________________<br>x264-devel mailing list
<br><a href="mailto:x264-devel@videolan.org">x264-devel@videolan.org</a><br><a href="http://mailman.videolan.org/listinfo/x264-devel">http://mailman.videolan.org/listinfo/x264-devel</a><br></blockquote></div><br>