We are working on other projects and there were no problems in using inline assembly.
I can accept that you have different stand based on your experience regarding using inline assembly and I would like to understand it so we could better comply with your standard and see if we have shortcomings in our approach. So could you please elaborate a little on why you think that it is harder to maintain inline assembly code and what portability problems do you expect? Thanks, -Nedeljko ________________________________________ From: libav-devel-boun...@libav.org [libav-devel-boun...@libav.org] on behalf of Babic, Nedeljko [nba...@mips.com] Sent: Monday, August 20, 2012 13:29 To: libav development Cc: Lukac, Zeljko Subject: Re: [libav-devel] Optimization of decoders for MIPS. > I notice that the patches are very large. Even though the parts they > contain are related, the sheer size makes them difficult to evaluate as > review effort grows more than linearly with patch size. So if you could > split them into smaller parts that would reduce the effort to review and > integrate your patches considerably. > Ok. I will try to send smaller patches in the future. Do you want me to split patches that are already submitted? > All your optimizations are done as inline assembly. Our experience with > inline assembly is mixed at best. In most cases, it creates portability > problems and performance is reduced. As we strive to support ever more > systems and compilers, inline assembly is less than ideal. > > What motivated your decision to implement your optimizations that way? > > best regards, Diego Our optimizations are targeting mainly parts of the code that compiler cannot deal with good enough. For the rest of the code compilers for MIPS are doing pretty good job in optimizing it. This leads to faster development and we don't loose on performance. Also, if the function is written in external asm, the compiler will not inline it and for small functions that are called lots of times this could lead to significant performance drop. Code written in external assembler for one ABI basically cannot be used on systems with different ABI without changes. Code written in inline assembly can. And finally, it is easier to maintain the code with inline assembly than the code with external assembly. Regards, Nedeljko ________________________________________ From: libav-devel-boun...@libav.org [libav-devel-boun...@libav.org] on behalf of Diego Biurrun [di...@biurrun.de] Sent: Friday, August 17, 2012 14:49 To: libav development Subject: Re: [libav-devel] Optimization of decoders for MIPS. On Fri, Aug 17, 2012 at 01:49:44PM +0200, Nedeljko Babic wrote: > > In next few patches optimizations of decoders for MIPS architecture are sent. Thank you for your submission! > AMR NB and WB decoder optimizations are put in the same patch because > they share a lot of the same functionality. > > Optimizations for MP3 fixed and floating point decoders are also in one patch. > > Since this is first submission of our optimizations to Libav we will highly > appreciate any suggestion (and/or critic) regarding these patches or the way > submission is done. I will review your patches individually wrt how they fit into libav as a whole; build system, style, general programming issues. The Assembly itself I cannot review. Some general notes about your submission(s) below. I notice that the patches are very large. Even though the parts they contain are related, the sheer size makes them difficult to evaluate as review effort grows more than linearly with patch size. So if you could split them into smaller parts that would reduce the effort to review and integrate your patches considerably. All your optimizations are done as inline assembly. Our experience with inline assembly is mixed at best. In most cases, it creates portability problems and performance is reduced. As we strive to support ever more systems and compilers, inline assembly is less than ideal. What motivated your decision to implement your optimizations that way? best regards, Diego _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
