BitShifting

[kenneth mcfarland <ke...@gmail.com>]

Hi everyone,

I was thinking about opening an issue and eliminating as much of the bit
shifting in the code as was appropriate. My reasoning is two fold.

First its simply cryptic. I'm normally used to seeing something like it
crop up in the LMAX code as a hackish way to do super fast powers of two.
So reason one is readability and clarity.

I'm not going to fuss over bytecode but the logic is to use the shift
operator as an operator, In the event the compiler doesn't optimize the
shift out ahead of time its causing an extra couple of cycles, not a big
deal but it is a very small optimization.

var = (1<<15); //could just say 32768 and be done;
int a = 1 + 3 + 2 + 5; // could just say 10 and nobody would argue

I am curious if I will get grief for suggesting this. The other context
I've seen bit shifting in is platform agnostic code, which is also of no
concern here. So please give me your thoughts on this, does this make sense?

Re: BitShifting

[Keith Turner <ke...@deenlo.com>]

On Sat, Oct 28, 2017 at 7:05 PM, kenneth mcfarland
<ke...@gmail.com> wrote:
> Hi Chris,
>
> One instance is fluo-recipes under core/combine/CqConfigurator line 50.
>
> Another is line 36 under FluoConfigurator in fluo-recipes/core/export
>
> Looking at those lines describes the context in which I would change the
> literals, not in the encoding functions, just variable assignment.
>
> Would those changes make sense?

I think for those two cases expanding to 2^x would be a bit more human
friendly.  Would be nice to use _ also to make the literal easier to
read.

>
>
> On Oct 28, 2017 1:48 PM, "Christopher" <ct...@apache.org> wrote:
>
>> I'm guessing that most, if not all, of the places where bit-shifting is
>> used in Fluo, is in the manipulation of the Accumulo timestamp field, which
>> is customized to contain flags for Fluo. In these situations, it really is
>> the position of the bit that matters, and not the numerical value. The
>> position is easily identified by the bit-shifting. It's much hard to look
>> at an integer literal and immediately recognize which bits are "1" and
>> which are "0". This is important if we're trying to create a bitmask to
>> extract the value of a particular flag from the timestamp.
>>
>> If these can be improved to make them less cryptic, by adding comments,
>> that might be better than converting them to numeric literals.
>>
>> There might be some places in the code where a literal does make more
>> sense, but I think they'd have to be considered on a case-by-case basis,
>> rather than simply discussed generically. Which specific ones did you have
>> in mind?
>>
>> On Sat, Oct 28, 2017 at 3:19 PM kenneth mcfarland <
>> kennethpmcfarland@gmail.com> wrote:
>>
>> > I obviously meant 11 in the addition line so while you laugh the point
>> > stands :)
>> >
>> > On Sat, Oct 28, 2017 at 12:11 PM, kenneth mcfarland <
>> > kennethpmcfarland@gmail.com> wrote:
>> >
>> > > Hi everyone,
>> > >
>> > > I was thinking about opening an issue and eliminating as much of the
>> bit
>> > > shifting in the code as was appropriate. My reasoning is two fold.
>> > >
>> > > First its simply cryptic. I'm normally used to seeing something like it
>> > > crop up in the LMAX code as a hackish way to do super fast powers of
>> two.
>> > > So reason one is readability and clarity.
>> > >
>> > > I'm not going to fuss over bytecode but the logic is to use the shift
>> > > operator as an operator, In the event the compiler doesn't optimize the
>> > > shift out ahead of time its causing an extra couple of cycles, not a
>> big
>> > > deal but it is a very small optimization.
>> > >
>> > > var = (1<<15); //could just say 32768 and be done;
>> > > int a = 1 + 3 + 2 + 5; // could just say 10 and nobody would argue
>> > >
>> > > I am curious if I will get grief for suggesting this. The other context
>> > > I've seen bit shifting in is platform agnostic code, which is also of
>> no
>> > > concern here. So please give me your thoughts on this, does this make
>> > sense?
>> > >
>> >
>>

Re: BitShifting

[kenneth mcfarland <ke...@gmail.com>]

Hi Chris,

One instance is fluo-recipes under core/combine/CqConfigurator line 50.

Another is line 36 under FluoConfigurator in fluo-recipes/core/export

Looking at those lines describes the context in which I would change the
literals, not in the encoding functions, just variable assignment.

Would those changes make sense?


On Oct 28, 2017 1:48 PM, "Christopher" <ct...@apache.org> wrote:

> I'm guessing that most, if not all, of the places where bit-shifting is
> used in Fluo, is in the manipulation of the Accumulo timestamp field, which
> is customized to contain flags for Fluo. In these situations, it really is
> the position of the bit that matters, and not the numerical value. The
> position is easily identified by the bit-shifting. It's much hard to look
> at an integer literal and immediately recognize which bits are "1" and
> which are "0". This is important if we're trying to create a bitmask to
> extract the value of a particular flag from the timestamp.
>
> If these can be improved to make them less cryptic, by adding comments,
> that might be better than converting them to numeric literals.
>
> There might be some places in the code where a literal does make more
> sense, but I think they'd have to be considered on a case-by-case basis,
> rather than simply discussed generically. Which specific ones did you have
> in mind?
>
> On Sat, Oct 28, 2017 at 3:19 PM kenneth mcfarland <
> kennethpmcfarland@gmail.com> wrote:
>
> > I obviously meant 11 in the addition line so while you laugh the point
> > stands :)
> >
> > On Sat, Oct 28, 2017 at 12:11 PM, kenneth mcfarland <
> > kennethpmcfarland@gmail.com> wrote:
> >
> > > Hi everyone,
> > >
> > > I was thinking about opening an issue and eliminating as much of the
> bit
> > > shifting in the code as was appropriate. My reasoning is two fold.
> > >
> > > First its simply cryptic. I'm normally used to seeing something like it
> > > crop up in the LMAX code as a hackish way to do super fast powers of
> two.
> > > So reason one is readability and clarity.
> > >
> > > I'm not going to fuss over bytecode but the logic is to use the shift
> > > operator as an operator, In the event the compiler doesn't optimize the
> > > shift out ahead of time its causing an extra couple of cycles, not a
> big
> > > deal but it is a very small optimization.
> > >
> > > var = (1<<15); //could just say 32768 and be done;
> > > int a = 1 + 3 + 2 + 5; // could just say 10 and nobody would argue
> > >
> > > I am curious if I will get grief for suggesting this. The other context
> > > I've seen bit shifting in is platform agnostic code, which is also of
> no
> > > concern here. So please give me your thoughts on this, does this make
> > sense?
> > >
> >
>

Re: BitShifting

[Christopher <ct...@apache.org>]

I'm guessing that most, if not all, of the places where bit-shifting is
used in Fluo, is in the manipulation of the Accumulo timestamp field, which
is customized to contain flags for Fluo. In these situations, it really is
the position of the bit that matters, and not the numerical value. The
position is easily identified by the bit-shifting. It's much hard to look
at an integer literal and immediately recognize which bits are "1" and
which are "0". This is important if we're trying to create a bitmask to
extract the value of a particular flag from the timestamp.

If these can be improved to make them less cryptic, by adding comments,
that might be better than converting them to numeric literals.

There might be some places in the code where a literal does make more
sense, but I think they'd have to be considered on a case-by-case basis,
rather than simply discussed generically. Which specific ones did you have
in mind?

On Sat, Oct 28, 2017 at 3:19 PM kenneth mcfarland <
kennethpmcfarland@gmail.com> wrote:

> I obviously meant 11 in the addition line so while you laugh the point
> stands :)
>
> On Sat, Oct 28, 2017 at 12:11 PM, kenneth mcfarland <
> kennethpmcfarland@gmail.com> wrote:
>
> > Hi everyone,
> >
> > I was thinking about opening an issue and eliminating as much of the bit
> > shifting in the code as was appropriate. My reasoning is two fold.
> >
> > First its simply cryptic. I'm normally used to seeing something like it
> > crop up in the LMAX code as a hackish way to do super fast powers of two.
> > So reason one is readability and clarity.
> >
> > I'm not going to fuss over bytecode but the logic is to use the shift
> > operator as an operator, In the event the compiler doesn't optimize the
> > shift out ahead of time its causing an extra couple of cycles, not a big
> > deal but it is a very small optimization.
> >
> > var = (1<<15); //could just say 32768 and be done;
> > int a = 1 + 3 + 2 + 5; // could just say 10 and nobody would argue
> >
> > I am curious if I will get grief for suggesting this. The other context
> > I've seen bit shifting in is platform agnostic code, which is also of no
> > concern here. So please give me your thoughts on this, does this make
> sense?
> >
>

Re: BitShifting

[kenneth mcfarland <ke...@gmail.com>]

I obviously meant 11 in the addition line so while you laugh the point
stands :)

On Sat, Oct 28, 2017 at 12:11 PM, kenneth mcfarland <
kennethpmcfarland@gmail.com> wrote:

> Hi everyone,
>
> I was thinking about opening an issue and eliminating as much of the bit
> shifting in the code as was appropriate. My reasoning is two fold.
>
> First its simply cryptic. I'm normally used to seeing something like it
> crop up in the LMAX code as a hackish way to do super fast powers of two.
> So reason one is readability and clarity.
>
> I'm not going to fuss over bytecode but the logic is to use the shift
> operator as an operator, In the event the compiler doesn't optimize the
> shift out ahead of time its causing an extra couple of cycles, not a big
> deal but it is a very small optimization.
>
> var = (1<<15); //could just say 32768 and be done;
> int a = 1 + 3 + 2 + 5; // could just say 10 and nobody would argue
>
> I am curious if I will get grief for suggesting this. The other context
> I've seen bit shifting in is platform agnostic code, which is also of no
> concern here. So please give me your thoughts on this, does this make sense?
>