Boost logo

Boost Users :

Subject: Re: [Boost-users] [integer] what is the fastest integer type which can hold an 8 bit number?
From: Neil Groves (neil_at_[hidden])
Date: 2015-09-11 02:59:51


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?

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

On modern Intel architectures there's no performance difference taking
a temporary in the width of integer types in most scenarios. There is
a strong difference with SSE/AVX but then you need to use fixed width
for that use-case.

Hopefully this helps. I think Boost.Integer could use some
optimisation to provide an answer more like the standard library by
default.

>
> Robert Ramey
>

Neil Groves


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net