Thanks for the suggestion. Lua’s VM seems reasonably fast (executing a function takes only 25 nanoseconds), but I’d generally avoid the bit32 library unless I’d really need it.
Also, int64s for parameters/return values on a lot of methods that pertain to asset IDs might prove there to be 64-bit number support after all.
Also consult the ~= operator; it’s a better xor’er than bit32 could dream to be.
Made use of the new library to put into a rewrite of an old project of mine. Hello optimized Lua bytecode interpreter : ).
Have you benchmarked it yet? I’ve been having dislikes with the new bit32 library.
Deserialization currently runs a bit slower than its predecessor, but it is not yet properly optimized and I do much more general operations in this version. I expect once the Roblox VM optimizations for bit library kick in things will go a lot smoother than before.
I should also say passwords which are hashed are stored in a Rainbow Table. This is more powerful than using encryption in some practices (as you mentioned passwords) so if the Rainbow Table was stolen, people can’t do much about it. Hashing uses one algorithm (typically SHA) in one place to encode the plaintext by user input.
In the marching squares and marching cubes algorithms, a density map is turned into a bit field which is then used to look up which shape / edges a given cell should consist of. This is a case where I’ve had to use Lua 5.1- only implementations of bit shifts and bitwise OR, and where I can now use bit32.
int64 is a pseudo-representable type given the nature of lua_Number. I would assume they documented it in that way to allow for future expansion.
I can’t understand why you would compare a single operand instruction such as not to the bit library’s implementation of xor, they each have their own purpose and aren’t meant to be interchanged.
I’m quite happy with this. Having written binary file formats myself, I find this especially useful for crunching data into smaller sizes. A welcome addition to the API.
There have been assets being created whose ID was above the int32 maximum since last year, so the future expansion bit may have already been… well… extended.
Lua doubles can already exceed the 32 bit integer limit, but they don’t quite make it to the 64 bit limit accurately. Casting from double to int64 should work as long as the number isn’t big enough that floating point inaccuracies kick in.
Tried this with my base64 encoder, astonishing results. Nothing even close to native, but still very noteworthy.
1,000,000 byte payload
old vm:
- numberlua: 4,886ms / 3,695ms
- native: 1,216ms / 1,243ms
new vm:
- numberlua: 454ms enc / 362ms dec
- native: 178ms enc / 169ms dec
I suspect the difference between native performance and the Bit32 library is due to integers still being stored as a double. If Roblox was to back port Lua 5.3 integers I’m sure we would see much greater performance.
Even better than integers for encryption would be access to native instructions for encryption / c code snippets. Perhaps in the future, but I’ll rely on third party services for my needs. Thank goodness the Http service supports HTTPS.
Rainbow tables can easily be mitigated with salts, which is a necessity as I’m sure there are rainbow tables for any hashing algorithm you can think of.
CryptoService with things like hashing and encryption functions when?
When you make a feature request for it. 
Though implementations of hashing algorithms at least are reasonably fast with bit32 so it might be unnecessary.
Sure, but I could write a reasonably fast JSON encoder/decoder as well, but Roblox provides API for it in the HttpService because it is much easier for Roblox to hook up the standard library for decoding JSON (written in C) than it is for every developer to manually implement their own hacky implementation, with a few people going as far as to spend many hours to create a standard one that few people would ever use. If there is significant demand, or if Roblox thinks games should start using a CryptoService, then they should provide us with access to optimized C libraries that Facebook developers wrote. (I am assuming that Roblox employees don’t have to completely rewrite libraries like the JSON decoder/encoder from scratch just for the Roblox codebase. If they do, that sucks. I would think though they would just have to modify it for a Lua output table. They should at least not have to write their own JSON parser)
Fantastic addition, now we have that, we can make a Roblox “Discord” with MessagingService and bitwise permission roles just like Discord. 
What an excellent change! Another roadblock removed.
I haven’t developed on Roblox for a long time now (due to these limits), but glad to know that when I do some day come back, I can apply more of what I learnt!
I am also wondering if this would improve/replace BitBuffer in any way? People are mentioning compression as a use-case and I’m using that module to compress CFrame values.
BitBuffer is completely different since it involves writing and reading bytes from a “buffer” rather than basic operations. It is very possible that a significant performance improvement can be made using bitwise operations, especially using the Base64 encoder from above.
May look into it later today since I do actually want to figure out what I can use Bit32 for. I have put off trying new features before, and I have been annoyed at myself for not using them before.
Edit:
No luck with getting something more performant.
Feel free use/modify it if you have some ideas. Everything is in ReplicatedStorage. The unit tests can be ignored since I haven’t published the plugin for it (yet).
BitBuffer with Bit32.rbxl (29.7 KB)