time vs. space tradeoffs of primitive types

[Noah Roberts]

I understand that different integer types might have time penalties
because of word boundaries. Where can I get information clarifying
this topic? A quick google didn't turn up much for me...nice little
C++ vs. Java troll war on wikipedia but nothing on what I'm looking
for. I want to know whether space savings using smaller types to
represent numbers you know will be small are ever seen. I would also
like to know what kind of performance penalties are associated with
using these smaller types.

 

[stefan.constantin]

I understand that different integer types might have time penalties
because of word boundaries. Where can I get information clarifying
this topic? A quick google didn't turn up much for me...nice little
C++ vs. Java troll war on wikipedia but nothing on what I'm looking
for. I want to know whether space savings using smaller types to
represent numbers you know will be small are ever seen. I would also
like to know what kind of performance penalties are associated with
using these smaller types.

I think it depends on the architecture .. for example on a 32-bit
system there's no speed/time penalty in using an int vs a short for
example .. the proccessor will fetch a 32-bit value anyway

 

[Salt_Peter]

I understand that different integer types might have time penalties
because of word boundaries. Where can I get information clarifying
this topic? A quick google didn't turn up much for me...nice little
C++ vs. Java troll war on wikipedia but nothing on what I'm looking
for. I want to know whether space savings using smaller types to
represent numbers you know will be small are ever seen. I would also
like to know what kind of performance penalties are associated with
using these smaller types.

Performance penalties depends on the context and the platform. A
primitive type has a range, a min and max value as well as a few more
interesting constants. You can dissect the various qualities of a
primitive using the <limits> header. Note that performance = 0 if the
primitive you choose generates an overflow. So before you get concerned
with speed, consider the ramifications.

#include <limits>

template< typename T >
void Numerics( const T& r_t )
{
std::cout << "\ntype: " << typeid(r_t).name();
bool is_int = std::numeric_limits< T >::is_integer;
std::cout << "\ninteger = " << is_int;
bool is_signed = std::numeric_limits< T >::is_signed;
std::cout << "\tsigned = " << is_signed;
std::cout << "\tsizeof = " << sizeof(r_t);
T min = std::numeric_limits< T >::min();
std::cout << "\nmin = " << min;
T max = std::numeric_limits< T >::max();
std::cout << "\nmax = " << max;
long capacity = static_cast<long>(max) - min;
std::cout << "\ncapacity = " << capacity;
std::cout << std::endl;
}

int main()
{
int n(0);
Numerics(n);
// etc
}

 

[Noah Roberts]

I think it depends on the architecture .. for example on a 32-bit
system there's no speed/time penalty in using an int vs a short for
example .. the proccessor will fetch a 32-bit value anyway

It doesn't have to do more processing steps to work with only half of
that value once it fetches it?

 

[Puppet_Sock]

Noah Roberts wrote:
[performance and space of different types]

This is all off topic in comp.lang.c++. But here goes anway.

If the differences are going to be important, then the thing to do is
try different ways of doing the task and measure.

Get some way of determining how much RAM a prog takes.
(Platform specific.) See if there is in fact a significant difference.
See if it is in fact in the direction you expected. In some cases
this may not be a trivial task, as operating systems tend to
hide such details from casual users. And you may not see
the difference at all on small applications or small allocations.
Some OS platforms will allocate memory in chunks so as to
avoid a lot of tiny memory fetches.

Set up some typical application task and get out your stop
watch. Be sure to account for various things about your OS
that might give spurious time values. Things like loading, or
the OS decides to do a disk maintenance cycle or something.

Generally speaking, when such performance and size issues
become critical, developers tend to make "tweaked" versions
of the code for each target platform. So, if various compile
options, or variable size, or bounds limits, etc., make a prog
run faster on one platform, that set of options is set up as
a config file for that platform. Then each targeted platform
gets its own config file. Possibly on a complete other
compiler for some targeted platforms.

This has the disagreeable aspect of possibly requiring some
noticeable differences in how apps run, how they appear, etc.
But that is probably unavoidable for some cases. XWindows
and MSWindows, for example, are going to have some code
that simply is not portable.
Socks

 

[Bo Persson]

It doesn't have to do more processing steps to work with only half
of that value once it fetches it?

It will probably work on all the bits anyway, but only use half the result.

On the other hand, one very popular 32-bit instruction set requires an extra
size-override byte to do 16-bit operations.

On the third hand smaller data uses less cache space, so it might be
faster.

As usual, it depends.


Bo Persson

 

[Jack Klein]

I understand that different integer types might have time penalties
because of word boundaries. Where can I get information clarifying
this topic? A quick google didn't turn up much for me...nice little
C++ vs. Java troll war on wikipedia but nothing on what I'm looking
for. I want to know whether space savings using smaller types to
represent numbers you know will be small are ever seen. I would also
like to know what kind of performance penalties are associated with
using these smaller types.

There are absolutely none at all, at the C++ language level. This is
easily understood by the fact the language standard does not specify
anything about the relative or absolute speed of anything.

And there really can't be any useful information about this on the C++
language level, since it is completely processor and platform
dependent.

If you really need to know this about the code a particular compiler
generates for a particular processor architecture, you need to do one
of the following:

-- consult the documentation for that particular compiler

-- ask in a newsgroup that supports that compiler/processor
combination

-- get a copy of the processor manual, and study execution timings

There are probably other possibilities, but all of them are off-topic
here because they are implementation specific and not language issues.

 

[Jack Klein]

I think it depends on the architecture .. for example on a 32-bit
system there's no speed/time penalty in using an int vs a short for
example .. the proccessor will fetch a 32-bit value anyway

While the entire issue is really off-topic here, you have fallen into
the classic trap of answering an off-topic question in a domain where
you are apparently not an expert.

Namely you are just flat-out absolutely wrong.

Consider the two most widely used 32-bit architectures in the world
today, x86 and ARM.

Both have penalties, in the form of either instruction prefixes, extra
clock cycles, or both, for accessing 16-bit variables in memory.

Sometimes pipelining hides the effects of the extra work, sometimes
not, but it is always there.

 

[eriwik]

On the other hand, one very popular 32-bit instruction set requires an extra
size-override byte to do 16-bit operations.

On the third hand smaller data uses less cache space, so it might be
faster.

Unless there is 32-bit alignment and/or the cache-lines are larger than
the data. As a general rule of thumb I'd say that you should go with
the "native" size, since the processors is usually optimized for these.
As a second rule of thumb I'd say that you'll almost always will have
to trade in performance to get smaller footprint.

 

[kwikius]

I understand that different integer types might have time penalties
because of word boundaries. Where can I get information clarifying
this topic? A quick google didn't turn up much for me...nice little
C++ vs. Java troll war on wikipedia but nothing on what I'm looking
for. I want to know whether space savings using smaller types to
represent numbers you know will be small are ever seen. I would also
like to know what kind of performance penalties are associated with
using these smaller types.

Not sure about alignment issues, but IIRC any 'small' int(signed char,
short etc) is converted to an int before math ops ( section 4.5, 5.9 in
the C++ standard for more details) IOW for performance in calcs (In
theory at least) I can't see a gain and maybe there will be a loss due
to conversion from using smaller types than ints.

regards
Andy Little

 

[Bo Persson]

Unless there is 32-bit alignment and/or the cache-lines are larger
than
the data. As a general rule of thumb I'd say that you should go with
the "native" size, since the processors is usually optimized for
these.
As a second rule of thumb I'd say that you'll almost always will
have
to trade in performance to get smaller footprint.

Sure, I was assuming that the OP was using *a lot* of these variables. If
they are half the size, each cache line will hold twice the amount. If he
uses only one or two, it doesn't matter at all.


Bo Persson