On Sun, Jan 3, 2016 at 9:35 AM, Kieran Kunhya <kier...@obe.tv> wrote: >> It is still "speed critical" enough for people to retain >> CONFIG_HARDCODED_TABLES. My goal here is simple: I want to get cycle >> count down enough so that hardcoded tables can be removed here. > > How are you going to guarantee this across all arches?
First of all, I have no idea what "guarantee" you are looking for here. What I guarantee is this: on every architecture, this change results in speedup (not to a mathematical level of guarantee, but to a practical level of gurantee). What I don't know is at what point one considers hardcoded tables, associated ifdefry, etc useful or not. That is inherently subjective. Same goes for code "readability" - also subjective. I also don't know the relative gains across architectures. What I do know is that there are clear inconsistencies in opinions here regarding this (e.g not "speed critical" yet needs a configure option), and I want to understand the heart of the matter. The thread I created is a step towards a scientific understanding of the actual impact of hardcoded tables, something that seems to not have been done in the past, when it should have been done at the time of introduction. Furthermore, since when has FFmpeg "guaranteed" speedups across all arches? Impacts of even a single line change can vary across arches. Does that mean that all patches under review get benched on each and every architecture that we support? Of course not. [...] _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
