Why would you want and int64 in first place?
-
-
-
In this case, I use byte flags with values 0-1 so that lots of threads can update flags concurrently without requiring slow atomics. Maintaining bit flags shared between threads requires atomics which are ~72 times slower than uncontended byte writes.
- 2 more replies
New conversation -
-
-
Explanation: 0x0102040810204080 = 2^56 + 2^49 + 2^42 + 2^35 + 2^28 + 2^21 + 2^14 + 2^7. Multiply each bit by pow2 to shift it to the the right place. Higher bits overflow, so they are not a problem.
-
Result = highest 8 bits of 64 bit value contain the bitfield. Shift down by 56 to move it to first 8 bits. This trick works because you have 7 bits free between the original bits. Compacted result can't be more than 7+1 = 8 bits long.
- 1 more reply
New conversation -
-
-
Multiplier tricks are fun. You can generalize that kind of trick using lookup tables: lut[(x * k) >> n]
-
So even if the exact form of the data isn't as clean, as long as it can be distinguished among the high bits of the product, you can use a (hopefully small, like 256 entries or less) lookup table to do the mapping.
- 3 more replies
New conversation -
-
-
Hahaha! What movie is that from?
- 1 more reply
New conversation -
-
Huh. So with 2 muls and a shift you can do an arbitrary 8 bit swizzle in a portable way... cool
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.