fluo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kenneth mcfarland <kennethpmcfarl...@gmail.com>
Subject Re: BitShifting
Date Sat, 28 Oct 2017 23:05:37 GMT
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" <ctubbsii@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?
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message