Are Tiny Floating-Point Numbers Hurting Game Performance?

[mangosprout]

Hi friends,

Are non-round numbers and tiny floating point numbers hurting performance? Or is this a non-issue?

I just looked into one of my save files today, and to my utter horror, I saw many, many, many floating point numbers close to 0, 0.5, and 1 that seem completely unnecessary, especially for vessel part positioning. I wonder if this impact performance during calculations in the black box of the KSP engine. Is this indicative of a systemic problem, or is it a non-issue?

From stock saves:

Fig. 1: unnecessarily small floating-point numbers that might as well be zero:

			PART
			{
				name = longAntenna
				// ...
				position = 1.1920930376163597E-07,-0.59675884246826172,0.25907167792320251
				rotation = 0.710125268,-1.26440568E-07,8.42937098E-08,0.704075754
				mirror = 1,1,1
				// ...
			}

Fig. 2a: more unnecessarily precise numbers that might as well be one

			PART
			{
				name = probeCoreOcto
				// ... 
				position = -5.2240800130221032E-08,-1.1970952749252319,2.8651722772110588E-08
				rotation = 1.00000012,0,-7.89703385E-19,0
				mirror = 1,1,1
			}

Fig. 2b: yet more unnecessarily precise numbers that might as well be one (and more bonus zeroes)

			PART
			{
				name = solarPanels5
				// ...
				position = -2.980232949312267E-08,-1.7227878570556641,-0.37164053320884705
				rotation = 0,0.999964118,-0.00851761177,0
				// ...
			}

From Modded Saves

When I looked at a craft made using procedural parts, the problem gets a lot worse. I wonder if this might have contributed to a huge FPS drop when flying planes made with procedural wings.

Fig 3: An excerpt from a B9 Procedural Wing

PART
{
	part = B9.Aero.Wing.Procedural.TypeA_4293943466
	// ...
	attPos = 0,-0.0103091002,0
	attPos0 = 2.00000405,-0.484342158,0
	rot = 0.706864536,-0.0185098294,-0.0185098201,0.706864476
	attRot = 0,-0.0436194316,0,-0.999048233
	attRot0 = 0,0.0436194241,0,0.999048293
	mir = 1,1,1
	// ...
	MODULE
	{
		name = WingProcedural
		// ...
		sharedBaseLength = 2.625
		sharedBaseWidthRoot = 1.125
		sharedBaseWidthTip = 0.250100017
		sharedBaseOffsetRoot = 0
		sharedBaseOffsetTip = 1.25
		sharedBaseThicknessRoot = 0.239999995
		sharedBaseThicknessTip = 0.199999988
		sharedEdgeTypeLeading = 2
		sharedEdgeWidthLeadingRoot = 0.239999995
		sharedEdgeWidthLeadingTip = 0.239999995
		sharedEdgeTypeTrailing = 3
		sharedEdgeWidthTrailingRoot = 0.479999989
		sharedEdgeWidthTrailingTip = 0.199999988
		sharedMaterialST = 1
		sharedColorSTOpacity = 0
		sharedColorSTHue = 0.100000001
		sharedColorSTSaturation = 0.75
		sharedColorSTBrightness = 0.600000024
		sharedMaterialSB = 4
		sharedColorSBOpacity = 0
		sharedColorSBHue = 0.100000001
		sharedColorSBSaturation = 0.75
		sharedColorSBBrightness = 0.600000024
		sharedMaterialET = 4
		sharedColorETOpacity = 0
		sharedColorETHue = 0.100000001
		sharedColorETSaturation = 0.75
		sharedColorETBrightness = 0.600000024
		sharedMaterialEL = 4
		sharedColorELOpacity = 0
		sharedColorELHue = 0.100000001
		sharedColorELSaturation = 0.75
		sharedColorELBrightness = 0.600000024
		// ...
	}
	// ...
}

Is this a non-issue?

I have enough systems programming experience to know that floating point numbers are never integers anyways. The entire game engine deals with messy decimal approximations of rational numbers with odd number denominators (1/7th, 1/9th, etc), not to mention sine/cosine calcs, but I wonder if the processors might benefit from a little bit of rounding 0's and 1's, especially right out of the VAB or SPH.

Thanks in advance for your thoughts. I just used regex to round some of these numbers for parts positioning. Maybe I'll see a performance gain, but I'm not serious enough a player to have benchmarking tools to verify if rounding out part positioning numbers will reduce computational load in any meaningful way. I'm probably better off using 32-bit mode.

 

Edited July 28, 2017 by mangosprout
typoes

[Snark]

Hello, and welcome to the forums! 

1 hour ago, mangosprout said:

re non-round numbers and tiny floating point numbers hurting performance? Or is this a non-issue?

Well, if you really want to know, you could always take a craft with a bunch of numbers like that, save an alternate version in which you manually clean up the "untidy" numbers, then try flying one and then the other to see if there's any observable difference whatsoever.

But honestly, I'd strongly suspect that it's a complete non-issue.  Everything's just a floating-point number (even zero), and the CPU knows how to add and subtract and multiply and divide them, and it can perform a binary operation on pretty much any two floating-point numbers, zero or otherwise.  It's its job.

I'd guess that any effect here would be either zero or so darn close to it that it might as well be.  On the list of potential performance optimizations to KSP, I'd guess that this one is not even on the map.

Just my two cents-- it's not as though I'm privy to the particular calculations that KSP goes through in its internals.

[TheRagingIrishman]

I agree with @Snark

[mangosprout]

2 hours ago, Snark said:

Well, if you really want to know, you could always take a craft with a bunch of numbers like that, save an alternate version in which you manually clean up the "untidy" numbers, then try flying one and then the other to see if there's any observable difference whatsoever.

But honestly, I'd strongly suspect that it's a complete non-issue.  Everything's just a floating-point number (even zero), and the CPU knows how to add and subtract and multiply and divide them, and it can perform a binary operation on pretty much any two floating-point numbers, zero or otherwise.  It's its job.

My silly aesthetically attuned human brain just did exactly that, and yup. zippo noticeable difference! I did feel better knowing that my parts were perfectly aligned however.

Although I'm absolutely sure that given a sensitive enough benchmarking tool, the game loaded microsecondsfaster because it had fewer bytes to parse in the text file.  

[HebaruSan]

Here's a (horribly-titled) video explaining conventional floating point representation in computers:

 

What you see in the text file is a decimal (base 10) representation, but the value in memory is stored in base 2. This is simple enough for whole numbers, but for fractions there are numbers that are exactly representable in a finite number of digits in one system but not the other. Usually that's where the extra decimal digits come from; an exact base 2 value that the program is using doesn't have a short representation in base 10. Base 10 fractions (1/10, 3/10, etc.) are especially susceptible to this:

http://www.exploringbinary.com/why-0-point-1-does-not-exist-in-floating-point/

Consider 0.600000024 from one of your files. This probably started life as "0.6" in some modder's config file. When the computer tried to load "0.6" into a binary representation, it wasn't able to convert it exactly, but it got as close as possible; it generated a number that worked just like 0.6 in practice, but wasn't quite exactly equal to it. Then later it was time to write it out to disk again, so that near-0.6 binary value was converted to base 10, again with some errors, and it ended up 0.000000024 away from where it started.

0.6 → [binary mess close to 0.6] → 0.600000024

Sometimes writing out fewer decimal digits can force the computer to round back to the original value, but this is really just a convenience for human readers rather than a way of making it more accurate.

And no, none of this has any performance implications. Floating point operations take the same amount of time regardless of the value of the arguments when converted to base 10.

[Jas0n]

Also even if you tidied it up in base 10, it might still be untidy in binary. Also, the number exists as a 64-bit floating point anyways so shouldn't affect calculation anyways.

[mangosprout]

That was such a cogent explanation! Thanks for taking the time to write all that out  The PBS vid was always illuminating. I hope it's useful to other aesthetes out there. And math teachers. 50+ base-2 bits for a mantissa?!. WOW.

The last time I learned about data types was in 2000, when I thought that 8-character variable names were used instead of 16 or longer strings because the bigger the text file, the more the C-compiler had to parse. hehe.

ps. I <3 Astrogator. Even if I don't use the transfers your algorithms give me, it's still the base from which I start all my interplanetary transfers.