arithmetic overflow

There is no ‘-’ in the code line you have posted, so i guess the warning refers to another line?

In general, such warnings often can be ignored, example:

std::vector stuff(100);
int count = stuff.size(); // gives a warning

The vector uses size_t for the type, which is 8 bytes for a 64bit program. So if you use (4 bytes) int as here, it could happen the count variable has not enough bits to represent huge numbers. But if you are certain you will never use such huge amounts of data (almost always), the warning can be ignored or disabled with a #pragma.

I would advise against ignoring any warnings, for two reasons:

1. If your code issues a bunch of warnings when it compiles, there is a good chance you will miss an important warning in the noise.
2. Changing your code to eliminate the warning often results in slightly better code. For instance in JoeJ's example, you can use a type that is more explicit about the fact that you are dealing with the size of some structure in memory:

std::vector<int> stuff(100);
size_t count = stuff.size(); // probably no warning

alvaro said:
size_t count = stuff.size(); // probably no warning

I would agree with your points, but in practice it gives me too much issues, so i end up using the pragma to disable the warning very often :/

Try to give an example…

std::vector<Node> nodes;
for (int i=0; i<nodes.size(); i++)
{
int fourthChildI = nodes[i].fistChild + 4;
if (nodes[fourthChildI].parent == -1) Log("bug found!");
}

Reasons i want to use int over size_t:

• I am sure 32 bits are enough for my data, so why using 64? On some (ore any) platform this could affect performance?
• size_t is unsigned, but using signed types needs less attention while unsigned is error prone. I'm fine with sacrificing another bit here to keep it simple.

The only solution for me would to cast like so:

for (int i=0; i<(int)nodes.size(); i++)

Which is harder to read and thus worse than using the pragma, IMO. Still, i see this looks bad and fishy. It's just that using int is quick and short, and i don't see a need to use custom types for everything.

Sorry it should be ‘*’ and not ‘-’

tex_height and tex_width are int.

Still could need help with my code. Thanks

const size_t NO_PARENT=SIZE_MAX;//if real indices reach SIZE_MAX you have bigger problems than overflow
//...
std::vector<Node> nodes;
//... 
for (size_t i=0; i<nodes.size(); i++)
{
    size_t fourthChildI = nodes[i].fistChild + 4;//maybe firstChild?
    if (nodes[fourthChildI].parent == NO_PARENT) Log("bug found!");//if Node.parent values are correctly set
}

What would you need a signed index for?

Regarding the original question, if info->tex_height and info->tex_width are 32 bits, signed or unsigned, the compiler figures out that their product doesn't fit in 32 bits and you could avoid overflow by doing a 64 bit multiplication instead (by previously casting at least one of the values to a 64 bit type). It isn't actually related to signed values or not using size_t.

LorenzoGatti said:
What would you need a signed index for?

I fail to come up with an example, but whenever i try to use unsigned types for indices, shortly after i regret it because it causes some extra work, and switch back to signed. (I'm forced to be more strict here on GPU because GLSL gives an error on mixing signed / unsigned. That's not really helpful but annoying.)

LorenzoGatti said:
if (nodes[fourthChildI].parent == NO_PARENT)

Your solution is good practice, but the parent index should be 32 bits only to save memory, so some casting is often unavoidable.
It's not that doing proper casting would be an evil, but in my case it really would clutter my code because i do so much math on indices in general.
Probably the primary reason for my issues is using a pre C++11 codebase, and my progress towards modern C++ is somewhat clumsy.

MikeCyber said:
Sorry it should be ‘*’ and not ‘-’ tex_height and tex_width are int.

So you say a multiplication using the same type gives a warning? :O
I tried it myself, disabling all pragmas:

	constexpr int a = 0x10000000;
	constexpr int b = 100;
	int c = a * b;

and this is what i get:

warning C4307: '*': signed integral constant overflow

But i do not get a warning if i remove constexpr:

int a = 0x10000000;
	int b = 100;
	int c = a * b;

Or if i use numbers that don't cause overflow, also no warning:

	constexpr int a = 200;
	constexpr int b = 100;
	int c = a * b;

Maybe you have set warning level to a higher level than the default of 3?

But even then i do not understand why you get a warning at all.

No I have w3. Any help please.

JoeJ said:
I am sure 32 bits are enough for my data, so why using 64? On some (ore any) platform this could affect performance?

You are quite likely paying the cost of conversions that you didn't intend. It is faster to keep them all as the same type and do the math than it is to do the conversions.

Sometimes those conversions you pay for happen inside the CPU core itself. Modern processors have moved to 64-bit processing internally so many of the 32-bit, 16-bit, and 8-bit operations are generally slower. For many operations they do the work as though it were a 64-bit value sometimes having to extend the value out, do the math, and then chop it back down. Benchmark tools like PassMark PerformanceTest have found notable differences on many CPUs which they have occasionally discussed in their forums. For example, 64-bit integer multiplies may be 6x faster than the 32-bit integer operations, or 64-bit division might be 4x faster than the same 32-bit integer division. Exact numbers depend on the chips and the operations involved.

None of this is new. The performance difference was noted about 15 years ago when Intel and AMD moved to 64-bit cpu cores. They continue to focus first on 64-bit (and with modern extensions also 128-bit, 256-bit, and even 512-bit) optimizations and leave the old, smaller cases behind as historical footnotes. The engineers might have left in faster hardware designs specific to the 32-bit or 16-bit operations, but quite often they don't bother and simply do the work at 64-bit (or higher) precision.

If your data is 32-bit use a 32-bit type like u32 or i32 or int32_t or whatever you want in your system. If it is 64 bit do likewise, using the actual size of the data. If you're working with memory sizes then size_t is the proper data type, not int or int64_t or int32_t, or other variations. Don't intentionally do conversions you don't need.

frob said:
You are quite likely paying the cost of conversions that you didn't intend. It is faster to keep them all as the same type and do the math than it is to do the conversions. Sometimes those conversions you pay for happen inside the CPU core itself. Modern processors have moved to 64-bit processing internally so many of the 32-bit, 16-bit, and 8-bit operations are generally slower.

Thanks, that's the argument i needed to hear.
Seems sticking at int in general is just lazy and i need to type longer type names in the future… : )

frob said:

JoeJ said:
I am sure 32 bits are enough for my data, so why using 64? On some (ore any) platform this could affect performance?

You are quite likely paying the cost of conversions that you didn't intend. It is faster to keep them all as the same type and do the math than it is to do the conversions.

Sometimes those conversions you pay for happen inside the CPU core itself. Modern processors have moved to 64-bit processing internally so many of the 32-bit, 16-bit, and 8-bit operations are generally slower. For many operations they do the work as though it were a 64-bit value sometimes having to extend the value out, do the math, and then chop it back down. Benchmark tools like PassMark PerformanceTest have found notable differences on many CPUs which they have occasionally discussed in their forums. For example, 64-bit integer multiplies may be 6x faster than the 32-bit integer operations, or 64-bit division might be 4x faster than the same 32-bit integer division. Exact numbers depend on the chips and the operations involved.

None of this is new. The performance difference was noted about 15 years ago when Intel and AMD moved to 64-bit cpu cores. They continue to focus first on 64-bit (and with modern extensions also 128-bit, 256-bit, and even 512-bit) optimizations and leave the old, smaller cases behind as historical footnotes. The engineers might have left in faster hardware designs specific to the 32-bit or 16-bit operations, but quite often they don't bother and simply do the work at 64-bit (or higher) precision.

If your data is 32-bit use a 32-bit type like u32 or i32 or int32_t or whatever you want in your system. If it is 64 bit do likewise, using the actual size of the data. If you're working with memory sizes then size_t is the proper data type, not int or int64_t or int32_t, or other variations. Don't intentionally do conversions you don't need.

I am very sceptical of this claim that 64-bit ops could be (that much) faster than 32-bit ops, so I tried to find the source and I think this is where it comes from: https://forums.passmark.com/performancetest/3278-amd-llano-cpumark-artificially-inflated-scores?postcount=7#post18109​

And it just seems to be the usual mixup of 64-bit architecture and 64-bit data. When they're talking about 32bit and 64bit in that thread it's about architecture, without specifying what datatypes are used - just “Integer Math” and “Find Prime Numbers”. A bit more reading ( https://forums.passmark.com/performancetest/3383-64bit-vs-32bit-benchmarks-integer-maths-pt8?t=3348​ ) shows that both tests mixed 32-bit and 64-bit integers and performance numbers where dominated by integer division and square roots respectively. So it's not that 32-bit ops are slow(er) on modern x64 CPUs, it's that 64-bit integer operations are slow when you have to emulate them with x86 instructions.

And then coincidentally the specific chips in that original benchmark also had a hardware bug, with a workaround that completely ruined their integer division performance: https://forums.passmark.com/performancetest/3705-amd-llano-a-series-benchmark-and-cpu-bug?t=3656​

And if you want to look up exact performance numbers for individual instructions on specific processor architectures, Agner Fog has you covered: https://www.agner.org/optimize/instruction_tables.pdf

I think we can also take a look at the “int_fast”-types defined in . On pretty much all modern compilers/systes that I checked, fast8_t is defined as int8, fast16_t as int32, fast32_t as int32 and fast64_t as int64_t. That seems to suggest that anything outside of 16-bit integeres is going to be pretty efficient for the processor to deal with.

Eternal said:
I am very sceptical of this claim that 64-bit ops could be (that much) faster than 32-bit ops

It's something i'll keep an eye on over time. I never compared 32 vs 64 bit integer type perf. before.

Yesterday i made some fake poisson samples generator, and i thought this would be a nice test, because it has a lot index math.
Basically, for each sample it iterates 27 * 27cells, so that's expensive.

The test was very interesting. At first i forgot to convert also the randF function, because it used uint32_t instead int.
With this, performance was exact the same with replacing int with either int32t or int64t.
Then, after changing this function too, i got a 10% speedup. : )

Seems the 64 → 32u truncation had a noticeable cost, and using 64 bit is free. Both is surprising for me.

namespace FAKE_POISSON
{
	constexpr float radius = 1.f;
	constexpr float clip = 0.498f;

	//using intT = int32_t; // 478 ms
	using intT = int64_t; // also 478 ms at first, 438 ms after making also randF 64 bit

	inline float randF (intT i)
	{
		i *= 1664525;
		i ^= (i << 16);
		i ^= (i >> 16);

		i *= 16807;
		i ^= (i << 8);
		i ^= (i >> 24);

		i *= 100069;
		i ^= (i << 24);
		i ^= (i >> 8);

		i *= 1000099;

		return float(i) / float(0x100000000LL);
	}


	template <class Vec3>
	Vec3 RandomSampleInCell (const intT x, const intT y, const intT z)
	{
		intT h = (x*23879 + y*96823 + z*182177) * 3;
		return Vec3 ( randF(h)-.5f, randF(h+1)-.5f, randF(h+2)-.5f );
	}

	template <class Vec3>
	Vec3 RelaxedSampleInCell (const intT x, const intT y, const intT z)
	{
		Vec3 curP = RandomSampleInCell<Vec3> (x, y, z);

		Vec3 dispSum (0);
		float wSum = FP_TINY;
		for (intT x2=-1; x2<=1; x2++)
		for (intT y2=-1; y2<=1; y2++)
		for (intT z2=-1; z2<=1; z2++)
		{
			Vec3 adjP = RandomSampleInCell<Vec3> (x+x2, y+y2, z+z2) + Vec3(x2,y2,z2);
			Vec3 diff = curP - adjP;
			float l = diff.SqL();
			if (l<radius*radius && l>FP_EPSILON2)
			{
				l = sqrt(l);
				Vec3 disp = diff / l * (radius-l);
				dispSum += disp;
				wSum += 1.f;
			}			
		}			
		curP += dispSum / (wSum*2);
		for (intT i=0; i<3; i++)
		{
			curP[i] = max(-clip, curP[i]);
			curP[i] = min( clip, curP[i]);
		}

		return curP;
	}

	template <class Vec3>
	Vec3 RelaxedTwiceSampleInCell (const intT x, const intT y, const intT z)
	{
		Vec3 curP = RelaxedSampleInCell<Vec3> (x, y, z);

		Vec3 dispSum (0);
		float wSum = FP_TINY;
		for (intT x2=-1; x2<=1; x2++)
		for (intT y2=-1; y2<=1; y2++)
		for (intT z2=-1; z2<=1; z2++)
		{
			Vec3 adjP = RelaxedSampleInCell<Vec3> (x+x2, y+y2, z+z2) + Vec3(x2,y2,z2);
			Vec3 diff = curP - adjP;
			float l = diff.SqL();
			if (l<radius*radius && l>FP_EPSILON2)
			{
				l = sqrt(l);
				Vec3 disp = diff / l * (radius-l);
				dispSum += disp;
				wSum += 1.f;
			}		
		}			
		curP += dispSum / (wSum*2);
		for (intT i=0; i<3; i++)
		{
			curP[i] = max(-clip, curP[i]);
			curP[i] = min( clip, curP[i]);
		}

		return curP;
	}
}