Speed difference between variable types

[jacdelad]

Hello,
is there a speed difference when using different variable types, like ".u" and ".l"? Let's say I need to store a value that will definitely never exceed 65535 and is never lower than 0, I would use ".u". But is it maybe better to use ".l" oder ".i", because these are native sizes of processor registers or whatever (I'm not so deep into asm yet)?

[STARGÅTE]

What do you mean with "using"? Using in math operation? Using in arrays?
Here is an instruction table for many processors, all operation on them and the time they need.
https://www.agner.org/optimize/instruction_tables.pdf

Most of the operations do not have strong differences between 8, 16, 32, or 64 bit.
However, an operation like DIV (division) could be faster with smaller variable types, but then Pure Basic has also to use the smaller registers, and not just put the .u value into a native type and then divide.
Other operations like IMUL (multiplication) could be faster with native variable types, but the same here, it depends on PureBasic.

For arrays it is helpful to use smaller variable sizes, to reduce the length of the array when copying and resizing the array.

[jacdelad]

Thanks for the info. The question was meant for general purpose, like "test.u=test1.u+test.u" vs. "test.i=test1.i+test2.i".

[Bitblazer]

because these are native sizes of processor registers or whatever (I'm not so deep into asm yet)?

That is often the problem. There are now very different hardware specifications of x86 / x64 processors "in the wild". Some are carefully tuned to minimize production cost (that also depends on the available technology at a certain time and place) while others are brute force optimized for one specific small usability case (especially gaming setups). IMHO if you want to achieve the maximum possible speed on every single architecture, you really can not achieve that with one universal single binary. You would have to compile at least for two or three cpu "types" into one binary file, at the start check which one to use and ignore the others.

As we talk about x86 OR x64 architectures, there are cases when using a 8-bit wide operation on x86 is the best, while doing the same on a x64 platform would be really bad. The one single thing i keep in mind about speed, is not the execution cycle of assembler commands, but the memory requirement for a specific task. Creating a sine table for example to speed up sine calculations, is a good trick but be careful about the sine table size. On some architectures if the table does not fit into the fastest cpu cache size anymore, your performance will suddenly drop a lot due to "cache trashing".

I don't know if the latest gcc is dealing with these runtime differences. Ironically microsofts .NET architecture with IL would be able to do it.

As a general rule, keep the memory requirement (references!) of "fast" operations, low. It is often more about the memory cache and not so much about the cpu cycles. But obviously you can create an example on an architecture that "proves" the opposite ...

Don't worry too much, keep memory references in "fast" routines low and if things go bad (too slow on customer machines), start to look into optimising the code, but always find the real limitation first. It might be code size and memory cache and not cpu cycles. In special cases, it could be something completely different too (fpu, gpu, instruction set or even drivers ...).

If you are not working in compiler design, don't worry too much, keep your memory references low for critical routines and let (gcc from v6 on) do its work.

ps: keep in mind that early optimization is (often) the devil. However on a general architecture layer, early optimization is crucial.

[jacdelad]

Thanks for this second answer.

My programs are nothing special, just basic stuff and absolutely not time critical. I was just interested in the technical processes on working with different data types like "is every integer converted into an 64 bit integer (and back) on a 64 bit machine or not". Beside the obvious testing, of course.

I guess I can stick with the data type that fits my need most.