Hi Virendra, On 18-01-2016 15:54, Virendra Kumar Pathak wrote: > Hi Linaro Toochain Group, > > I have few questions on glibc+libm w.r.t aarch64. > If possible, please provide some insight, otherwise kindly redirect me to the > concerned person/forum. > > 1.It seems from the community patches that ARM/Linaro is optimizing glibc > functions such as memcpy/memmove, string for aarch64. > However, looks like some of these (e.g. memcpy/memmov) patches are still not > merged in glibc. Any comment on their availability in glibc? > e.g. https://www.sourceware.org/ml/libc-alpha/2015-12/msg00341.html
This is mainly due lack of review. Usually for optimization patches the arch maintainer will have the final answer. Now it is too late for 2.23, but we will focus on make it available for 2.24. Besides this memcpy, there is still some other string function (memchr) and some generic one (strpbrk, etc.) that are stalled either due missing review or lacking of comments follow up. > > > 2. On the same note, is there any plan for optimizing/tuning libm functions > (e.g. trigonometric) for aarch64? > I could find any matching patches on review board. Please correct me if I am > wrong. No one has posted any patch or stirred discussions about it. The complex function in libm are usually coded in in C to be platform neutral, with some specific function being optimized (rounding, etc.). x86_64 also have some assembly implementations for some specific routines (exp, log, ...), but I also do not have number about how fast are they related to C counterparts (it also might be the case where the speedup is not that high to validate the assembly existence). Rule of thumb currently in GLIBC is to avoid as possible arch-assembly routines and work with C implementation that are platform neutral with possible arch hooks on sensitive performance paths (check Siddhesh recent sincos performance improvements). For very critical performance paths we also have the option to add specific build with more aggressive optimization flags along with IFUNC support (for instance one for A57 and another for A72, if it is such the case). If none options are the best way to improve performance, platform specific implementation are still a good option (libmvec is basically a lot of x86_64 assembly implementation currently). > > 3. Looks like ARM have released an independent version of libm for certain > trigonometric functions. > https://github.com/ARM-software/optimized-routines. > Any plan of these optimization going in glibc's libm? Any comment on its > performance improvement over GNU libm ? > Regarding licensing I do not foresee any issues, since GLIBC is LGPL 2.1 and later it may be combined with code from a LGPL version 3 library, with the combined work as a whole falling under the terms of the GPLv3 [1] (since Apache 2.0, the one ARM used in this projects, and it is compatible with LGPL 3.0). I am far from a license lawyer, so someone please correct me if I am wrong. Now related to technical side, I think it is feasible however it will required a lot of work to adjust these function for fit GLIBC project. First thing is the requirements: GLIBC current required 4.7 as the minimum compiler, however the project itself requires 4.8. I noted mpfr and mpc are used exclusive in testing framework. Second thing is add these implementations for ARM/AArch64 with correct names and infrastructure. The downside is it will deviate ARM/AArch64 from rest of other ports, requiring further maintenance because of the different optimization. Another thing is to check the implementation against GLIBC own testcase, which add some tests regarding exceptions, rounding, etc. Any deviation will require fixing and/or bug reported. Finally GLIBC developers will certainly ask for either improvements in the benchmark testsuite or number that show these implementation are somewhat better than current ones. It will also require some precision/speed analysis. [1] http://www.gnu.org/licenses/license-list.en.html > Thanks in advance for your time. > > -- > with regards, > Virendra Kumar Pathak > > > _______________________________________________ > linaro-toolchain mailing list > linaro-toolchain@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/linaro-toolchain > _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
