On Thu, Jan 31, 2013 at 5:29 PM, Steve Strobel <[email protected]> wrote: > On Wed, Jan 30, 2013 at 9:34 PM, Albert Cahalan <[email protected]> wrote:
>> > GCC provides floating >> > point emulation libraries, but they are way too slow to run Codec2 >> > realtime. >> >> I think the problem is that gcc is trying too hard. It's probably giving >> you 100% IEEE-compliant floating-point using the standard format. >> >> The first thing to do is to say that all NaN and Inf values, on input >> or output, invoke undefined behavior. There is only one rounding >> mode, and there are no exceptions. > > I already tried the ”-mfast-fp” option which does at least some of those > things. I should have said gcc's floating-point **library** is trying too hard. All the compiler options in the world won't change the library's algorithms. >> Hacking the library would help, but ideally you'd hack gcc itself. > > I hadn't really considered that. I suppose the cleanest way to accomplish > it would be to add proper support for the "half float" datatype No, a short float won't help you. (well, not much: maybe cache misses and it might mean a tad if you don't have 32-bit registers) You need to get rid of the conditional branches in the library. Switching to a 1:15:16 format may help. Switching to a format with an explicit 1 bit (not normalized properly, like Intel 80-bit) could also help. Better yet, you need to inline the library, but that requires that the compiler be more aware of the library. I think it would involve moving the library into the code generation, so it really isn't a library at all. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
