2009/6/20 Michael Buesch <m...@bu3sch.de>: > On Saturday 20 June 2009 00:09:56 Jonas Gorski wrote: >> > If we do _not_ gain performance, it certainly is not a good idea to waste >> > space. >> >> I would be very surprised if we wouldn't. Every kernel emulated >> floating point operation results in an exception and the appropriate >> handling (fpu emulation is ugly), while soft-float should stay >> completely in user space. >> >> Also, the mips fpu emulator itself suggests that. >> Quoting linux/arch/mips/math-emu/cp1emu.c: >> > * Note if you know that you won't have an fpu, then you'll get much >> > * better performance by compiling with -msoft-float! >> >> To get some numbers: Perhaps could somebody test with 'sample' from >> libmpcdec the difference in speed between in-kernel emulation and >> soft-float? https://dev.openwrt.org/ticket/4715 suggests that the >> library depends heavily on floating point when not using fixed point >> math. > > No you completely got me wrong. I am talking about the performance gain in > real life. > userspace soft float certainly _is_ faster than kernel float. But _if_ > userspace > soft float is bigger in size than kernel float, it probably is not worth the > space tradeoff, > because floating point is hardly used on a router.
I apology, I really did misunderstand you. > Did somebody test this: > * Image with kernel FP emu disabled and userspace softemu enabled. > * Image with kernel FP emu enabled and userspace softemu disabled. > > Which one is smaller? Disabling the kernel fpu emu isn't intended in linux, so I had to hack the emulation away, mainly by removing any fpu references in arch/mips/kernel/ until it compiled. I don't know if it really works, I don't have a second device for testing. I used the brcm47xx/default profile for testing, making distclean before compiling. With kernel-fpuemu and no softfloat: 2560000 openwrt-brcm47xx-squashfs.trx Without fpuemu and with softfloat: 2625536 openwrt-brcm47xx-squashfs.trx So the image with soft-float instead of the in-kernel fpu emulation uses one block more. For me this would be an acceptable increase. Removing the fpu support completely does have a positive side effect even for applications that don't use floats: There is no fpu context anymore, so the memory footprint of processes should be very slightly reduced, and context switches should be a little bit faster. While the first should be neglectable (if I read the sources correctly, 256 bytes), the latter might be even measurable. Regards, Jonas Gorski _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
