Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust: 128 bit integers preparing to be released

github.com

Post reply on HN
Print view View original

51–60 of 173 posts

Re: Rust: 128 bit integers preparing to be released

#51

Post by dbaupp »

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…

One of Rust's strongest features is its ability to outlaw data races. In this case, the 128-bit types only provide mutations that take &mut self, that is, a unique unaliased pointer, meaning there's no way to concurrently mutate and hence they are automatically atomic, in a sense.

Re: Rust: 128 bit integers preparing to be released

#52

Post by dbaupp »

barsonme wrote: post #50
dbaupp wrote: post #37

Earlier quoted context omitted.

Rust offers non-allocating fixed-sized arrays, so a GUID could be a (wrapper around) [u8; 16] and an IPv6 address could be [u16; 8].

So does Go, so a net.IP could be [16]byte or [4]byte, but I'm sure you can see the obvious problems that might occur there (with having two separate IP types). Most UUID libraries I've seen and written use [16]byte as the concrete UUID type.

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.

Re: Rust: 128 bit integers preparing to be released

#54

Post by Gankro »

drfuchs wrote: post #47
Gankro wrote: post #36

Earlier quoted context omitted.

If you can't already hash/compare an array of bytes, something terrible has happened with your language design.

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…

Rust isn't hashcode based. You don't define how to hash a type in that way. You define hashing algorithms which operate on arrays of bytes. All a type has to do to implement hashing is specify how to feed its bytes into a hasher.

Hashers provide conveniences for feeding in a u8, u16, u32, u64, etc., but most hashers just implement this as casting the value to an array of bytes and using the generic implementation. This is because most algorithms are defined in terms of bytes. Evidently there isn't any interesting optimization to do by statically knowing you have a u32 vs a u64 for these algorithms (appears to be the case for SipHash, XXHash, and Fnv).

And indeed, u128 continues this tradition in the PR: https://github.com/rust-lang/rust/pull/37900/files#diff-2327...

Re: Rust: 128 bit integers preparing to be released

#55

Post by dbaupp »

drfuchs wrote: post #47
Gankro wrote: post #36

Earlier quoted context omitted.

If you can't already hash/compare an array of bytes, something terrible has happened with your language design.

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.

Re: Rust: 128 bit integers preparing to be released

#56

Post by drfuchs »

steveklabnik wrote: post #46
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…

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.

Re: Rust: 128 bit integers preparing to be released

#57

Post by steveklabnik »

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.

In Rust, you don't get buggy behavior in this kind of case: your program fails to compile.

Re: Rust: 128 bit integers preparing to be released

#58

Post by latrasis »

steveklabnik wrote: post #41
cyphreak wrote: post #27

Earlier quoted context omitted.

Why would they? Do you have any idea how much money a vuln like that would be worth? You've threatened to kill people on twitter and you think someone would turn something like that over to the team out of charity? You're delusional. I've never seen a million-dollar exploit, but DAMN if this wouldn't be close.

I can't believe that I (apparently) have to say this, but I 1. Would certainly not threaten to kill anyone on twitter. 2. Would certainly not threaten to kill someone for reporting a security vulnerability in Rust. In fact, as I said above, I would prefer that people report them, so that everyone using Rust can be safe from vulnerabilities.

Just want to say I really admire your work. It's sad to see people trolling like this.

Re: Rust: 128 bit integers preparing to be released

#59

Post by int_19h »

dbaupp wrote: post #52
barsonme wrote: post #50

Earlier quoted context omitted.

So does Go, so a net.IP could be [16]byte or [4]byte, but I'm sure you can see the obvious problems that might occur there (with having two separate IP types). Most UUID libraries I've seen and written use [16]byte as the concrete UUID type.

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.

I think the point was that when it's a mere alias, you can end up passing an array of the right size and type that is not an IP address.

Re: Rust: 128 bit integers preparing to be released

#60

Post by wtallis »

leereeves wrote: post #30
gravypod wrote: post #13

Earlier quoted context omitted.

For finance probably but it's mostly useful for statistics from what I understand. I know fortran and Cobol code that banks use and is used for science (tm) often defines numbers this large for certain operations. One such i can think of is a map reduce of large datasets. Let's say you want to find as a result a huge sum. 2^128 is a bit bigger then 2^64 and that difference may be big enough to provide the computation…

What number in finance is bigger than 2^64?

The sum of the whole planet's annual GDPs, expressed as US dollars with a precision of cents, requires about 53 bits. Choose a smaller unit or start considering long time spans, and you can easily get uncomfortably close to overflow.
Post reply on HN