If numbers more than 65536 are supported? what is performance?

[Oleg Vazhnev]

Hi

I've read in wikipedia article that only Q16.16 is supported. So maximum value is 65535. Am I corret that bigger numbers are not supported?

Another question - what is performance for basic operations (add, substruct multiply devide) on modern Intel processors comparing to native types?

Thanks,

 Oleg

[Conrado Miranda]

Oleg,

The maximum value is lower (2^15-1) as the numbers are signed.

The + and - operations are the native ones if overflow detection is disabled. Otherwise there's a small overhead. The division and multiplication have even bigger overhead.

I'm not sure what is the performance difference exactly. It shouldn't be hard to make such a test, tough.

Cheers,

Conrado

--
You received this message because you are subscribed to the Google Groups "libfixmath" group.
To unsubscribe from this group and stop receiving emails from it, send an email to libfixmath+...@googlegroups.com.
To post to this group, send email to libfi...@googlegroups.com.
Visit this group at http://groups.google.com/group/libfixmath.
For more options, visit https://groups.google.com/groups/opt_out.

[Oleg Vazhnev]

Thanks Conrado for quick response! I have more questions :)

Isn't the main reason to use "fixed-point" is performance?

What are the main use-cases to use libfixmath?

I was thinking I can have performane improvement replacing double with fixed-point type. Why Q32.32 is not implemented, it seems Q16.16 is not enough in many cases.

Thanks,

 Oleg

[Conrado Miranda]

Yes, performance is a major reason but it's very different in 2 types of systems:

1) If the processor has an FPU, you can use fixed point to speed-up calculations that doesn't need much precision. I've been able to get more than an order os magnitude speedup.

2) If the processor doesn't have an FPU, usually you can simulate floating point in software, but it's ridiculously slow. I've used fixed point in embedded ARM without an FPU to implement real-time control.

So yes, if you don't need the precision and do check for overflow, fixed point can help. Also, maybe just single floating precision may help enough.

Q32.32 can be implemented in a similar fashion, and indeed Q16.16 isn't enough for many cases. However, IMO many processors in embedded systems still have < 64bits as the ones with 64bits are overkill for most cases. So using Q32.32 would require more operations per calculation.

[Ben Brewer]

Hey Oleg,
You can see some basic benchmarks here:
http://code.google.com/p/libfixmath/wiki/Benchmarks

These benchmarks are for embedded systems, some basic benchmarks I did a
while back can be found here:
http://en.wikipedia.org/wiki/Libfixmath

On a modern intel x86[-64] processor (even an Atom) you'll find that
the floating point unit is so fast that it always beats fixed point.
Fixed point processing is really best for low-cost embedded systems, or
applications where you want calculations to be accurate and in a fixed
range.

As you've already pointed out in a further mail, the signed types used
in this library only support up to 32767. You could easily use this
library as a template to make your own Q24.8 library or similar (or add
those types to this library) if it turns out to be what you want.

Regards,
Ben Brewer (aka flatmush)

[Oleg Vazhnev]

Thank you Conrado and Ben!

Let me conclude:

I writing low-latency trading application, I'm always using latest Xeon processors, which must have good FPU.

I was thinking to substitute "double" with fixed-point calculation to have better performance.

It seems I can't just take this library and use it. It limits me to 32767 (which is definitely not enough for me), and after all it might be slower than the Xeon's FPU.

However as I know even on latest Xeon's processors people get several times performance improvement substituting "double" with fixed-point, not with this library, they using something else I guess, something that designed for the latest desktop/server Intel processors.

[Ben Brewer]

Hey Oleg,
    The best way to get performance out of fixed point is to do it all manually, this library is for convenience but does a lot of overflow checks and whatnot to ensure calculations are done properly.

I'd imagine the people getting higher performance using fixed point are using the integer vector extensions to work on multiple integers at once, you should look into that really.

Good luck,
Ben Brewer (aka flatmush)

--