Rust: 128 bit integers preparing to be released • Hacker News Board

Re: Rust: 128 bit integers preparing to be released

#71

Post by the_duke » Sun, Dec 04, 2016, 8:37 AM UTC

drfuchs wrote: post #45

andars wrote: post #8

In case anyone else is interested in reading it, the relevant RFC is here: https://github.com/rust-lang/rfcs/blob/master/text/1504-int1...

The RFC doesn't seem to mention anything about the atomicity (or lack thereof) of loads and stores of variables of the 128-bit types. From the discussion, it seems that on a number of current architectures, they're not going to be atomic. Does this cause any problems in the Rust view of the world? Will there be unanticipated issues for developers who have been getting along just fine so far unknowingly assuming that…

I what drfuchs might be getting at is that 128bit integers would need two registers on a 64bit architecture. Or four on a 32 bit one.

LLVM supports arbitrary length integer types, regardless of the platform. Rust already has u64 and i64 on 32bit architectures.

But even if something fits in one register, a variable isn't thread safe anyway.

Rust DOES NOT allow a mutable reference to exist simultaneously with non-mutable ones.

For thread safety, you always need special types, which Rust provides:

https://doc.rust-lang.org/std/sync/atomic/

https://doc.rust-lang.org/std/sync/struct.Arc.html

Re: Rust: 128 bit integers preparing to be released

#72

Post by Tuna-Fish » Sun, Dec 04, 2016, 8:42 AM UTC

drfuchs wrote: post #56

steveklabnik wrote: post #46

Earlier quoted context omitted.

Rust has separate atomic types for doing atomic operations, so currently, none of them are. So, if you wanted an atomic type, you'd find it here: https://doc.rust-lang.org/stable/std/sync/atomic/index.html In other words, no, it shouldn't be a problem, at least in my understanding.

Right, but the point is that to date, being careless about asking for an atomic type explicitly would not lead to buggy behavior. But now it will, so some folks are going to be stumped when they use their old habits and get flakey results. Not that there's anything to be done, other than warning folks that they can't just widen their integer types and expect it to work without checking for this case.

The situation where the atomicity of integer operations matter is when there are multiple references to a single memory location, at least one of which is mutable.

The entire basis of the memory protection model of Rust is that it makes the above impossible in safe code. If you attempt to create such a situation, the compiler will fail to compile your code. Every single integer operation could stop being atomic and not a single line of safe rust would break.

Re: Rust: 128 bit integers preparing to be released

#73

Post by ben0x539 » Sun, Dec 04, 2016, 8:50 AM UTC

barsonme wrote: post #61

dbaupp wrote: post #52

Earlier quoted context omitted.

I don't see the obvious problem (fwiw, I really dislike such rhetorical devices): presumably net.IP could a struct that contains a [16]byte and an isV4 flag.

The problem is [16]byte would always be wasting 12 bytes for IPv4 addresses if you only used one type for both. So, two types must be made which requires extra code and doesn't allow for == comparison which is what OP (GP? whomever...) was complaining about not being able to do since net.IP is []byte. Sorry for the rhetorical device.

Isn't the indirection overhead of a []byte more expensive than a spare 12 inline bytes?

Re: Rust: 128 bit integers preparing to be released

#74

Post by lorenzhs » Sun, Dec 04, 2016, 9:06 AM UTC

foota wrote: post #69

A fun rule of thumb is that 1 decimal digit is roughly 3 binary digits (because 2^3 is eight, which is almost ten.)

That's terribly far off. On the other hand, 2^10 and 10^3 are reasonably close at 1024 and 1000. That's good enough for many things. But it's also the difference between a Kibibyte and a Kilobyte, and so forth.

Re: Rust: 128 bit integers preparing to be released

#75

Post by drfuchs » Sun, Dec 04, 2016, 9:37 AM UTC

the_duke wrote: post #71

drfuchs wrote: post #45

Earlier quoted context omitted.

The RFC doesn't seem to mention anything about the atomicity (or lack thereof) of loads and stores of variables of the 128-bit types. From the discussion, it seems that on a number of current architectures, they're not going to be atomic. Does this cause any problems in the Rust view of the world? Will there be unanticipated issues for developers who have been getting along just fine so far unknowingly assuming that…

I what drfuchs might be getting at is that 128bit integers would need two registers on a 64bit architecture. Or four on a 32 bit one. LLVM supports arbitrary length integer types, regardless of the platform. Rust already has u64 and i64 on 32bit architectures. But even if something fits in one register, a variable isn't thread safe anyway. Rust DOES NOT allow a mutable reference to exist simultaneously with non-mutab…

Thanks, but to be even more explicit, I'm thinking of a lower level than thread safety and the nice atomic references Rust provides in "safe" code: Consider a systems-y program that handles signals, or even hardware interrupts, or mmaps a chunk of shared memory. Any Read of a 32-bit variable will produce a value that was Written previously, no matter what; the hardware guarantees it. But a Read of a 128-bit variable may result in a value that has the high 64 bits from one earlier Write, and the low 64 bits from a more recent Write that was interrupted (or vice-versa). That's different than what many folks have ever experienced, messes up some algorithms, and is sure confusing the first time you see it.

True, this won't come up in a run-of-the-mill program, but if Rust is going to supplant C for OS work, or DataBase implementations, this is an issue to be aware of.

Succinctly: If you're in unsafe code, using 128-bit integers, you may experience behavior you've never seen before.

Re: Rust: 128 bit integers preparing to be released

#76

Post by Tempest1981 » Sun, Dec 04, 2016, 9:40 AM UTC

foota wrote: post #69

A fun rule of thumb is that 1 decimal digit is roughly 3 binary digits (because 2^3 is eight, which is almost ten.)

I've used this many times -- handy for order-of-magnitude sanity checks. Sure, log2(10) is 3.32 or so, but it's still a quick way to remember that 32-bits is good for a billion, and 64-bits is good for a quintillion (ok, 9 quintillion unsigned)

Re: Rust: 128 bit integers preparing to be released

#77

Post by eropple » Sun, Dec 04, 2016, 9:44 AM UTC

PeCaN wrote: post #22

pkulak wrote: post #15

Earlier quoted context omitted.

GUIDs are usually 128 bits. So are IPv6 addresses. Could be nice to store them in a single, native type? Probably no easier than a byte array though...

Neither one is used like an integer though. As in, you don't really add GUIDs together¹, so there's no real benefit over a byte array or struct. 1. I guess having bit mask operations for IPv6 addresses could be useful.

IP addresses are used like integers all the time. Ask your friendly neighborhood sysadmin how a network mask works.

(Maybe you want to foreach over an array every time you want to apply one. I'd rather not.)

Re: Rust: 128 bit integers preparing to be released

#78

Post by [deleted] » Sun, Dec 04, 2016, 9:45 AM UTC

dbaupp wrote: post #55

drfuchs wrote: post #47

Earlier quoted context omitted.

Not in a way that complies into one or two machine instructions. So, your array code is an order of magnitude or two too slow. Never mind having to write it at all. Added: I'm talking about implementing specific, optimized hash functions on 128-bit values (e.g. GUIDs, IPv6 addresses), and not generic hash functions that can take any length input (although many of them speed up linearly in the size of int that gets us…

Whatever one can do on an i128, one can do "manually" on an array of bytes, e.g. coerce to a pair of u64s to avoid having to manipulate each byte individually.

[deleted]

Re: Rust: 128 bit integers preparing to be released

#79

Post by snovv_crash » Sun, Dec 04, 2016, 9:48 AM UTC

drfuchs wrote: post #75

the_duke wrote: post #71

Earlier quoted context omitted.

I what drfuchs might be getting at is that 128bit integers would need two registers on a 64bit architecture. Or four on a 32 bit one. LLVM supports arbitrary length integer types, regardless of the platform. Rust already has u64 and i64 on 32bit architectures. But even if something fits in one register, a variable isn't thread safe anyway. Rust DOES NOT allow a mutable reference to exist simultaneously with non-mutab…

Thanks, but to be even more explicit, I'm thinking of a lower level than thread safety and the nice atomic references Rust provides in "safe" code: Consider a systems-y program that handles signals, or even hardware interrupts, or mmaps a chunk of shared memory. Any Read of a 32-bit variable will produce a value that was Written previously, no matter what; the hardware guarantees it. But a Read of a 128-bit variable…

That kind of non-safe memory sharing doesn't exist in Rust, unless you explicitly mark code as 'unsafe'. If you want to write a variable, nobody else is allowed to read it until you are finished, and this is enforced at compile time via the language design. The same is true for all data structures.

Re: Rust: 128 bit integers preparing to be released

#80

Post by eropple » Sun, Dec 04, 2016, 9:49 AM UTC

kevhito wrote: post #48

kevhito wrote: post #39

Earlier quoted context omitted.

I wasn't able to find any real justification beyond (a) one vague mention of "some algorithms... such as certain cryptographic algorithms" and (b) the fact that clang supports it. Can you point to something more specific? Justification (b) in particular smells bad to me.

Oh, just found this: > The Duration type could be simplified with this: instead of using a u64 for seconds with a seperate u32 for nanoseconds, it could just be a single u128/i128 count of nanoseconds. Of course, just a single u64 at ns precision would get you 500+ years of range. But ok.

Five hundred years and eighty-four years? Recorded human history is almost ten times that range and history to which we can get precise dates is nearly five times that range. There are financial debts being paid, today, that exist from nearly the limit of that range (Dutch debts dating from 1624) even if you left a mere quarter of it for the future. So why are you middlebrowing at this?