Avoid Doubles And Longs?

[TrevorBradley]

Thanks to the folks in the GP2X dev forum, I'm on my way to developing my first Pandora game using C++ and SDL. Early results are extremely promising.

I've demonstrated that I can cross compile SDL code to the GP2x, but I've decided to do development on my Linux machine and port to the Pandora later.. The GP2X isn't likely to have enough oomph to render it properly. (Though I should give it a try).

And of course since I'm a math geek my code presently makes extensive use of doubles. "Extensive" is a mild term here... I'm presently doing hundreds of thousands of computations per second. (Don't ask, yet...

Now the Pandora doesn't have floating point capabilities, and I'm pretty sure my code should work just fine using floats and ints rather than longs and doubles. Should I convert all my doubles to floats right now and save myself significant pain later? Is there anything more I should know about doubles vs floats for the system? (e.g. estimated time comparison for multiplying two doubles vs two floats?)

(If this doesn't work, I may just release this game for beefier machines with FPU's anyways... I'm too invested in the idea now, and it looks awesome on my Dual Core Linux box that I'm not sure I want to scale it down

Thanks in advance!

EDIT: A quick search and replace of "double" with "float" and it still works great... Yay! I think I'll stick with Floats for safety.

 

[cb88]

uuuurrrr.....huudreds of thousands? thats like a like a lot!

what kind of strain is it putting on you PC?

also http://en.wikipedia.org/wiki/ARM_architect...SIMD_.28NEON.29

the pandora DOES support floating point... might be weaker than a PC though

it is fast enough to render quake2 in software pretty fast


you will probably what to check into what compile flags you should use to enable the optimizations you need when you do a pandora release (even if just for good measure... to save battery etc..)
Edit: not sure which version of gcc you need for neon (there was talk of the latest version working not sure.... I think it was the 2007q3 version that does support neon for sure)

Flags to pass to gcc: -O3 -fomit-frame-pointer -mfloat-abi=softfp -mfpu=neon -mcpu=cortex-a8 -ftree-vectorize -ffast-math

somebody might wanna check my facts on that since I'm not at the top of my game atm... amid finals..(brain power being sapped)

 

[dockthepod]

You can get away with using soft floats most of the time but if you are really crunching numbers you'll need to switch over to fixed point. It's not much fun though if you're numbers are of various ranges... Here's a little fixedpoint lib.

http://www.trenki.net/content/view/17/37/

edit: Duh, i thought you were asking about GP2X. I don't know how well pandora will handle floats. A hell of a lot better than GP2x though

 

[TrevorBradley]

OH ZOMBIE JEEBUS.

It compiles *and* works on the GP2X. Well, kinda.. need to figure out some memory limitations to keep it from crashing...

I may need to make this into a single player game for the GP2X sooner rather than later for the Pandora....

 

[TrevorBradley]

uuuurrrr.....huudreds of thousands? thats like a like a lot!

what kind of strain is it putting on you PC?

At the moment, 100% of one CPU, but I've not yet optimized the frame rendering. (Or rather I did and it caused weirdness. That and no SDL_Delay *looks* awesome. I figure it only needs about a quarter of this.

Scaled down, the GP2X capacity appears to be about 1/10th of my desktop computer, which sounds about right. Which also means it should run near full speed on the Pandora.

With major tweaking of course. I'll get back to all of you...

 

[sinoth]

I've been wondering about the float issue too lately. I have a basic game engine using C++/OpenGL that has some of the common hurdles finished, like a quaternion camera, accurate timers, etc etc. The camera in particular operates exclusively on floats.

Conceptually, my 3D space extends from -infinity to +infinity, and X,Y,Z are stored as floats. It seems to me like changing them to ints will make for jerky movement. Is the answer to simply pull the camera back and increase the scale of the scene, so that a change from 1 to 2 is small enough it seems smooth?

 

[ldesnogu]

This has been discussed many times, but here it is again:
- Cortex-A8 supports single and double precision floating-points
- the floating-point unit is not pipelined (so SP and DP FP are slow though faster than software emulation of FP)
- the NEON unit can execute SP FP and is pipelined.

To summarize: don't use doubles and use NEON SIMD FP instruction set

 

[lardman]

And to summarise further fixed point or integer arithmetic is far faster than floating point, so move to using fixed point or integer code.

 

[flatmush]

And to summarise further fixed point or integer arithmetic is far faster than floating point, so move to using fixed point or integer code.

Uh that's not always true, a more true statement would be: "To summarise further, fixed point or integer arithmetic is never slower than floating point."

Much as I'm a fan of fixed point (made a whole astro-lander game in it), there are limits to what can be achieved easily in fixed point. If he's doing extensive maths stuff like it sounds like then it will massively simplify his calculations having the dynamic range.

On another note for one of the more technically minded guys here, does the NEON pipeline work in parallel with the 2 integer pipelines?
Because if that was the case then a balanced load of half integer and half floating point would actually be faster (the other integer pipeline would probably be used up doing branches/misc control logic).

 

[zacaj]

The pandora has hw floating point and a neon processor- floating point shouldnt be a problem, and I dont think you should be using fixed. Doubles just have a bigger range, but I doubt youll need even what floats give you

 

[multiplex]

You'd think someone with a Beagle Board would have run some performance benchmarks, but I can't seem to find any relevant ones....
I found http://groups.google.com/group/beagleboard...4a91e2ea056be13
, which indicates a pretty hefty penalty for doubles, but there's no indication of how it's measured, or whether it's typical.

If it's just floats vs. doubles that worries you, it wouldn't hurt to make it a typedef. Converting code to fixed point is more involved, and lacking any hard numbers, I'd just go with floating point, as that'd likely be easier to code.

If you need to do some optimization later, it's likely to involve tweaking the code to make use of the NEON unit (which does require single-precision floats.) I'm betting there's lots of parallelity to exploit in those hundreds of thousands of computations.

 

[TheGoodDoktor]

You should always abstract your atomic data types so that you can change them easily if you need to.
If you are using C++ then create some vector & matrix classes, use accessor functions to read and write to them, keep the data private, that way you should easily be able to write NEON SIMD versions of the operations.
Oh and use floats on the Pandora, loads of people will argue about fixed point being faster but no one will argue about them being more accurate. The general rule is that if a system has an FPU you should use it.

 

[Svartalf]

The general rule is that if a system has an FPU you should use it.

Indeed. Unless there's a severe penalty for it's use (Read: 8087... ) you should use the hardware- and the Pandora does have a slight penalty, but unless you're seriously FP intensive, you shouldn't avoid using it. (Unless you've just GOT fixed point in there from an older title from off of the GP32/GP2X lying around and don't want to clean that mess up... )

 

[piedottaste]

Of course, since you're using C++ you could always use a typedef for all of your values and make it float now. Then when you get a real pandora you can change the type as much as you like with no change in code

 

[Exophase]

You should always abstract your atomic data types so that you can change them easily if you need to.
If you are using C++ then create some vector & matrix classes, use accessor functions to read and write to them, keep the data private, that way you should easily be able to write NEON SIMD versions of the operations.

You don't need to do all that to abstract an implementation, the equivalent setup of structs and functions in C should suffice.

Oh and use floats on the Pandora, loads of people will argue about fixed point being faster but no one will argue about them being more accurate. The general rule is that if a system has an FPU you should use it.

Actually, 32bit ints have 8 bits more precision than 32bit floats. If your numbers (and intermediate results) stay close enough in order of magnitude then fixed point will store more data. Floats actually will be faster than fixed for some operations if the platform is pipelined, but Pandora's VFP unit isn't.

 

[warmi]

And to summarise further fixed point or integer arithmetic is far faster than floating point, so move to using fixed point or integer code.

On a Neon equiped hardware using fixed point amounts to stupidity.

Why would you want to have your main integer unit doing all the work while at the same time keeping your floating point unit completely idle ?
Not to mention being able to vectorize your floating code ...

Doesn't make sense at all.

Don't use doubles ( unless you absolutely need them) and vectorize your code ( if you can ) - it is not free if you are doing it yourself ( using asm) because in addition to the cost of the call itself ( you won't be able to inline this stuff unless using compiler intrinsics), there is a setup penalty when going into vectorized mode but for bigger stuff ( like transforming many verticles) it will pay off handsomely.

If you don't believe me .. check this out:

http://www.imgtec.com/forum/forum_posts.as...amp;PID=583#583

.. and he is talking about the iPhone which is nowhere near as powerfull as what you get with Pandora.

 

[ldesnogu]

Uh that's not always true, a more true statement would be: "To summarise further, fixed point or integer arithmetic is never slower than floating point."

That's wrong on most processors: many integer multipliers are slower than FP ones, most integer units don't have divide. I'm afraid there's no general rule :lol:

 

[flatmush]

Uh that's not always true, a more true statement would be: "To summarise further, fixed point or integer arithmetic is never slower than floating point."

That's wrong on most processors: many integer multipliers are slower than FP ones, most integer units don't have divide. I'm afraid there's no general rule :lol:

I said more true (fuzzy logic ). I'm currently designing a processor so I do realize the complexities but I was pointing out that his statement was outdated.
Also that still depends on how many multiplies you are performing in your integer arithmetic and the processor you're running on, DSP's often have a more highly optimized multiplier.
But yeah for single precision floats the floating point unit only has to do a 48-bit multiply (after scaling) while an integer multiplier has to do either a 32-bit multiply (for a 32-bit cpu ofc) or more often a 64-bit multiply if the top 32-bits of the multiply are required (which they are for multiplying by reciprocals).

 

[Adventus]

QUOTE
Why would you want to have your main integer unit doing all the work while at the same time keeping your floating point unit completely idle ?
Not to mention being able to vectorize your floating code ...
The Neon unit also has 3 integer pipelines (MAC, ALU, SHIFT), so you can probably Neon accelerate fixed point if you like.

However, i think we should be able to get away with using floats for most non-integer quanitities. If your using the data as an input to the SGX you may aswell use floats, other datatypes require conversion in the USSE pipeline.

 

[PokeParadox]

On a somewhat related topic, how do we use the NEON unit for floats?