C++Talk.NET Forum Index C++Talk.NET
C++ language newsgroups
 
Archives   FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

time vs. space tradeoffs of primitive types

 
Post new topic   Reply to topic    C++Talk.NET Forum Index -> C++ language (comp.lang.c++)
View previous topic :: View next topic  
Author Message
Noah Roberts
Guest





PostPosted: Thu Nov 23, 2006 10:11 am    Post subject: time vs. space tradeoffs of primitive types Reply with quote



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.
Back to top
Salt_Peter
Guest





PostPosted: Thu Nov 23, 2006 10:11 am    Post subject: Re: time vs. space tradeoffs of primitive types Reply with quote



Noah Roberts wrote:
Quote:
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
}
Back to top
Guest






PostPosted: Thu Nov 23, 2006 10:11 am    Post subject: Re: time vs. space tradeoffs of primitive types Reply with quote



Noah Roberts wrote:
Quote:
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
Back to top
kwikius
Guest





PostPosted: Fri Nov 24, 2006 10:10 am    Post subject: Re: time vs. space tradeoffs of primitive types Reply with quote

Noah Roberts wrote:
Quote:
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
Back to top
Jack Klein
Guest





PostPosted: Fri Nov 24, 2006 10:10 am    Post subject: Re: time vs. space tradeoffs of primitive types Reply with quote

On 23 Nov 2006 00:30:56 -0800, stefan.constantin (AT) gmail (DOT) com wrote in
comp.lang.c++:

Quote:

Noah Roberts wrote:
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

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.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
Back to top
eriwik@student.chalmers.s
Guest





PostPosted: Fri Nov 24, 2006 10:10 am    Post subject: Re: time vs. space tradeoffs of primitive types Reply with quote

On Nov 23, 9:21 pm, "Bo Persson" <b...@gmb.dk> wrote:
Quote:
Noah Roberts wrote:
stefan.constan...@gmail.com wrote:
Noah Roberts wrote:
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

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 Smile 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.

--
Erik Wikström
Back to top
Jack Klein
Guest





PostPosted: Fri Nov 24, 2006 10:11 am    Post subject: Re: time vs. space tradeoffs of primitive types Reply with quote

On 23 Nov 2006 00:09:30 -0800, "Noah Roberts" <roberts.noah (AT) gmail (DOT) com>
wrote in comp.lang.c++:

Quote:
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
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
Back to top
Display posts from previous:   
Post new topic   Reply to topic    C++Talk.NET Forum Index -> C++ language (comp.lang.c++) All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2006 phpBB Group
SEO toolkit © 2004-2006 webmedic.