Re: [Boost-users] [integer] what is the fastest integer type which can hold an 8 bit number?

Subject: Re: [Boost-users] [integer] what is the fastest integer type which can hold an 8 bit number?
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-09-11 11:55:29

On 9/10/15 11:59 PM, Neil Groves wrote:
> On 11 September 2015 at 05:30, Robert Ramey <ramey_at_[hidden]> wrote:
>> Reading the documentation at
>>
>> http://www.boost.org/doc/libs/1_59_0/libs/integer/doc/html/boost_integer/integer.html
>>
>> I invoke the following
>>
>> using temp_integer = typename boost::int_t<8>::fast;
>>
>> With the idea of getting the fastest integer type which will hold an 8 bit
>> signed number.
>>
>
> That seems like a very reasonable thing to do! I know you to be very
> experienced and so I assume there is a reason for not using
> std::int_fast8_t?

lol - not experienced to know that this even existed.

There is a difference though. boost::int_t<N>::fast easily let's me use
N as the result of some other compile time calculation.  Also 
std::int_fast8_t is only available in C++11++.  But these are not huge 
issues in the context of the current problem I'm working on.  I will 
likely make my own int_t<8>::fast for this app which invokes the 
std::int_fastN_t.  I know this should be rolled in to the library.  Hmmm
guess the best is to just open a trac item so that one day it get's fixed.

>> But I get temp_integer equal to a char type.  This surprises me.  I don't
>> believe that the fastest integer type which can hold an 8 bit signed integer
>> is a char.  I looked into the boost/integer.hpp and I can't really figure it
>> out.  It doesn't seem to to have any processor specific code in it - which I
>> would think would be necessary to implement the function.  What am I missing
>> here?
>
> I don't think you are missing anything. I've taken a look at the
> Boost.Integer code and the int_fast_t implementation simply provides
> the LeastInt as the fast type. There is a comment "imps may
> specialize". I don't know why the Boost.Integer implementation doesn't
> delegate to the standard library functionality when it is available.
> It would probably make better defaults and pick up platform
> optimisations.

probably just needs a little library maintenance.
>
> On modern Intel architectures there's no performance difference taking
> a temporary in the width of integer types in most scenarios.

This was always my understanding

> Hopefully this helps.

It does - thank you.
I think Boost.Integer could use some
> optimisation to provide an answer more like the standard library by
> default.

agreed
>
>>
>> Robert Ramey
>>
>
> Neil Groves
>