[integer] what is the fastest integer type which can hold an 8 bit number?
Reading the documentation at http://www.boost.org/doc/libs/1_59_0/libs/integer/doc/html/boost_integer/int... 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. 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? Robert Ramey
On 11 September 2015 at 05:30, Robert Ramey <ramey@rrsd.com> wrote:
Reading the documentation at
http://www.boost.org/doc/libs/1_59_0/libs/integer/doc/html/boost_integer/int...
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
On 9/10/15 11:59 PM, Neil Groves wrote:
On 11 September 2015 at 05:30, Robert Ramey <ramey@rrsd.com> wrote:
Reading the documentation at
http://www.boost.org/doc/libs/1_59_0/libs/integer/doc/html/boost_integer/int...
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
participants (2)
-
Bjorn Reese -
Neil Groves -
Robert Ramey