Re: [OpenWrt-Devel] use of soft-float on bcm47xx
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. 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? -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ping Re: RFC: LuCI Web Interface Image Format
On Wed, 17 Jun 2009 23:08:17 +0200 Felix Fietkau n...@openwrt.org wrote: My plan for the unified format is to keep the on-flash format the same as the input format. In the long run, I don't want any unpacking to be done in sysupgrade or the web interface. The structure is roughly like this: [second stage loader][environment][kernel][rootfs] Ok, here's my question. The brcm-63xx *require* a Broadcom format imagetag at the start of the flash image (on flash and for CFE upgrades), and won't load without it. Do you mean to keep this imagetag and have the [second stage loader][environment][kernel][rootfs] all in the kernel partition (as far as the CFE is concerned; for the OpenWRT obviously the partitions would be determined by the environment) ? Also, how does the second stage loader compare to the kernel? I ask because I have run across a router for which the CFE verifies the CRC of the kernel after it has been decompressed. Would the unified format be a problem for this router? Also, when it comes to decompression, do the 63xx routers have the CFE do the decompression or is it a loader? I ask because I know that the kernel has to be compressed with specific lzma parameters for it to work with the CFE and that indicates to me that it's not an arbitrary loader that's doing the unpacking, but rather the CFE. Or do you run the loader *after* un-lzma by the CFE? -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://www.bmts.com/~cshore signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
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: 256 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
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
On Saturday 20 June 2009 23:56:51 Jonas Gorski wrote: 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: 256 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. So what about the following. We introduce another option in the kernel config to disable fpuemu. This way the user can select either useremu, kernelemu or no emu at all. This probably is a win-win situation then. Because if I do care about space, I can turn off _both_ emulators. And you, who do care about performance, can set the openwrt default to kernelemu-off useremu-on. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
2009/6/21 Michael Buesch m...@bu3sch.de: On Saturday 20 June 2009 23:56:51 Jonas Gorski wrote: 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: 256 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. So what about the following. We introduce another option in the kernel config to disable fpuemu. This way the user can select either useremu, kernelemu or no emu at all. This probably is a win-win situation then. Because if I do care about space, I can turn off _both_ emulators. And you, who do care about performance, can set the openwrt default to kernelemu-off useremu-on. This would probably the best option. We should then test which applications/libraries need floating point support and mark these with an appropriate dependency. Going with no float support might require additional tweaking, as busybox seems to use floating point. Regards, Jonas Gorski ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
