Wednesday, January 2, 2008
I'm...
... up a bit late (though not unreasonably so) and working on my simulator. Today's task was changing over some of the classes to use double-precision numbers rather than integers. Integers worked fine for most of the basic cases due to the precision of the experimental data, but when dealing with changes in temperatures it turns out to be more useful to just store doubles. I haven't yet done a speed comparison for the two styles, but that's also on my list of things to do, as it may be advantageous to use the integer version whenever possible. Anyways... I'm a tad annoyed because I naturally just changed all the functions and had it crash horribly in a psychic way, so I went back and am doing the change over step by step and in each step it works fine. Sigh. I want to know what caused the psychic crash but I've not yet developed psychic powers to figure it out.
Subscribe to:
Post Comments (Atom)
2 comments:
You'd be surprised -- the relative cost of floating point and integer arithmetic is nothing like it used to be in the old days. There's still the upfront cost of loading into the FPU (or SIMD unit) and back again, but otherwise the cycle counts are very reasonable (until you start talking division (precompute inverses instead!), sqrt, and trig functions). Try to clump all the floating point operations as close together as possible (minimize the number of of times data has to be moved in/out of the FP/XMM registers), and you shouldn't see much of a performance hit at all.
Unless you're already using vector opcodes (depending on your compiler), just because the transition to double will significantly reduce (x 0.5) the number of values handled at a time by the SIMD instructions (relative to 32 bit integers, I mean).
Hmmm... whenever I see FPU, I now naturally think of the Fermi-Pasta-Ulam (FPU) problem. It's been that way for a few years, actually.
Post a Comment