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

Re: Rust: 128 bit integers preparing to be released

#141

Post by staticassertion » Sun, Dec 04, 2016, 3:15 PM UTC

chrisseaton wrote: post #117

dardie wrote: post #106

Earlier quoted context omitted.

It's built into the type system and checked statically at compile time. In rust, there can only be one 'owner' of a stored value. Ownership can be transferred, borrowed by multiple readers, or borrowed by a single writer. This ensures (at compile time) that there at any given time there is only ever one single writer OR multiple readers. Rust programs are guaranteed to be free of race conditions at compile-time. The…

Right - I get that the compiler ensures it is only accessed by one thread at a time. But what I was asking was at runtime, when ownership transfers how does Rust ensure that writes to the value by the previous owner appear to the new owner before the transfer of ownership appears to the new owner? You can statically guarantee that only one thread owns the object, but you can't statically guarantee the order in which…

> you need to ensure that there is an explicit memory barrier yourself when you transfer the object.

To be clear, you need to write the code yourself, but the compiler won't let you transfer ownership between threads without doing so.

There is no way to compile your code without proving to the compiler that you're data race free.

Re: Rust: 128 bit integers preparing to be released

#142

Post by Manishearth » Sun, Dec 04, 2016, 3:15 PM UTC

Senji wrote: post #87

Manishearth wrote: post #83

Earlier quoted context omitted.

All the Rust OSes written right now use pretty tightly scoped unsafe code. The OS isn't just unsafe-blocks-everywhere. The compiler would force you to use an atomic. Once you realize no AtomicUint128 atomic exists, you may try to explicitly use unsafe to make things work, but even then that requires a lot more explicitness than just an unsafe block. You will realize your mistake some point here. Unsafe in Rust doesn'…

What stops you from manually entering a critical region yourself before you do the assignment?

Could you elaborate on what you mean here? The compiler stops you from trying to mutate things when they're not uniquely owned or atomic (or behind a mutex). When you have a non-unique reference you need to use a bunch of unsafe function calls to force mutation on it.

Re: Rust: 128 bit integers preparing to be released

#143

Post by Manishearth » Sun, Dec 04, 2016, 3:19 PM UTC

chrisseaton wrote: post #98

dbaupp wrote: post #51

Earlier quoted context omitted.

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.

Does Rust run a memory barrier when ownership is transferred? How does it ensure that the previous owner has finished all its writes when a new owner take over?

All of the standard library primitives that let you view writes from other threads (mutexes and mpsc senders) have memory barriers in them at some point.

The language itself doesn't know about memory barriers. It gives you the tools for enforcing thread safety provided your synchronization abstractions have memory barriers in the right place.

Re: Rust: 128 bit integers preparing to be released

#144

Post by w8rbt » Sun, Dec 04, 2016, 3:42 PM UTC

pkulak wrote: post #15

aroman wrote: post #3

What sorts of applications/domains need or benefit from having 128 bit integers?

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...

Then you could do this:

    ping6 42540577535212633203815888880477462122

Like you can do this:

    ping 2158835347
    PING 2158835347 (128.173.54.147) 56(84) bytes of data.
    64 bytes from 128.173.54.147: icmp_seq=1 ttl=52 time=20.4 ms
    64 bytes from 128.173.54.147: icmp_seq=2 ttl=52 time=20.5 ms

Re: Rust: 128 bit integers preparing to be released

#145

Post by Const-me » Sun, Dec 04, 2016, 3:44 PM UTC

bluejekyll wrote: post #2

Sweet! IPv6 perfection. besides GPUs, does anyone have experience with any processors that support 128 natively?

PCs have a set of 128-bit registers for like 15 years, both Intel and AMD.

For integer/fixed point math, the functionality is here since SSE2: https://en.wikipedia.org/wiki/SSE2

Re: Rust: 128 bit integers preparing to be released

#146

Post by pcwalton » Sun, Dec 04, 2016, 4:37 PM UTC

chrisseaton wrote: post #117

dardie wrote: post #106

Earlier quoted context omitted.

It's built into the type system and checked statically at compile time. In rust, there can only be one 'owner' of a stored value. Ownership can be transferred, borrowed by multiple readers, or borrowed by a single writer. This ensures (at compile time) that there at any given time there is only ever one single writer OR multiple readers. Rust programs are guaranteed to be free of race conditions at compile-time. The…

Right - I get that the compiler ensures it is only accessed by one thread at a time. But what I was asking was at runtime, when ownership transfers how does Rust ensure that writes to the value by the previous owner appear to the new owner before the transfer of ownership appears to the new owner? You can statically guarantee that only one thread owns the object, but you can't statically guarantee the order in which…

> But the other person answered - you need to ensure that there is an explicit memory barrier yourself when you transfer the object.

The channels do this.

Re: Rust: 128 bit integers preparing to be released

#147

Post by paulddraper » Sun, Dec 04, 2016, 4:42 PM UTC

lorenzhs wrote: post #74

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.

> terribly far off

lg 10 is 3.322

3 is ten percent accurate. 3.333 is one percent accurate.

Re: Rust: 128 bit integers preparing to be released

#148

Post by p0nce » Sun, Dec 04, 2016, 4:53 PM UTC

amelius wrote: post #129

pornel wrote: post #128

Earlier quoted context omitted.

It could (there are 3rd party Rust libraries for arbitrary-size integers), but Rust focuses more on low-level features. Types that have fixed size at compile time are more useful in Rust and can be optimized much better.

I didn't mean dynamically sized integers. I meant at-compile-time-arbitrarily-sized-integers ;)

I implemented those for D: https://github.com/d-gamedev-team/gfm/blob/master/integers/g... It's nothing special when you have adhoc templates.

Re: Rust: 128 bit integers preparing to be released

#149

Post by bluejekyll » Sun, Dec 04, 2016, 4:55 PM UTC

Const-me wrote: post #145

bluejekyll wrote: post #2

Sweet! IPv6 perfection. besides GPUs, does anyone have experience with any processors that support 128 natively?

PCs have a set of 128-bit registers for like 15 years, both Intel and AMD. For integer/fixed point math, the functionality is here since SSE2: https://en.wikipedia.org/wiki/SSE2

I've not had a chance to do more than rely on my compiler to target those. I guess I should play with them more.

Re: Rust: 128 bit integers preparing to be released

#150

Post by gkafkg8y8 » Sun, Dec 04, 2016, 4:55 PM UTC

amelius wrote: post #88

Perhaps a stupid question, but can't this be generalized to arbitrary size integers?

It would also good to address arbitrary size floating point numbers in Rust.

Huon Wilson worked on an implementation a year ago:

https://github.com/huonw/float

Related- there was a discussion a few years back in Reddit about future-proofing math/numbers in Rust:

https://www.reddit.com/r/rust/comments/1uy7rt/an_appeal_for_...

However, when it comes to speed, working with primitive types has gotta be faster if supported natively, so anything else anytime soon will play second fiddle.