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

Re: Rust: 128 bit integers preparing to be released

#151

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

pettou wrote: post #104

steveklabnik wrote: post #23

Earlier quoted context omitted.

128 bit floats were removed years ago (June of 2014), here's the meeting notes from the time: https://github.com/rust-lang/meeting-minutes/blob/master/wee... (as with all old Rust stuff, please remember that details very much might have changed between then and now.) In other words, they weren't removed because we fundamentally didn't want them. They were removed because of maintainability, usability, and usefulness…

When you say "details very much might have changed between then and now", are there any news on bringing in the float128 type? I mean, do you happen to know whether there is any reasonable chance of having it in Rust at all?

Nobody since then has championed it, so there's been no progress. Because of that, I'm not aware of how much effort it would be to add; the compiler has changed a lot since those days. That might make it easier or harder.

Re: Rust: 128 bit integers preparing to be released

#152

Post by ycmbntrthrwaway » Sun, Dec 04, 2016, 5:00 PM UTC

aroman wrote: post #3

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

NS-3 network simulator uses 128bit integers to measure time and they have 3 implementations (search page for int64x64): http://code.nsnam.org/ns-3-dev/file/38d46996c708/src/core/mo...

It would be much easier for them to just build on top of i128.

Also, you can see that one of the implementations is copied from Cairo, so it seems graphics libraries have some use for 128-bit integers too.

Re: Rust: 128 bit integers preparing to be released

#153

Post by Gankro » Sun, Dec 04, 2016, 5:03 PM UTC

the_duke wrote: post #94

amelius wrote: post #88

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

LLVM supports arbitrarily sized integer types, but sadly it's not exposed in Rust. The only language I've seen where this is possible is Julia (which uses LLVM too).

Swift uses them in the standard library to do cute things like a space efficient `Int63?`, but doesn't currently expose them as a general user facility.

Re: Rust: 128 bit integers preparing to be released

#154

Post by dbaupp » Sun, Dec 04, 2016, 5:04 PM UTC

ben0x539 wrote: post #73

barsonme wrote: post #61

Earlier quoted context omitted.

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?

Yes, and a []byte is even going to have at least as much inline overhead: it stores 24 bytes (length, capacity, pointer), and of course plus the 4 bytes of actual data. Even on a 32-bit platform, the []byte inline storage is 12 bytes.

Re: Rust: 128 bit integers preparing to be released

#155

Post by sctb » Sun, Dec 04, 2016, 5:08 PM UTC

cyphreak wrote: post #6

People still care about Rust? After the quadratic hashes and rumored memory issues, I'd have thought people would've dropped interest in it by now.

We've banned this serial troll, of course, but the immune response from the community was particularly healthy here.

Re: Rust: 128 bit integers preparing to be released

#156

Post by FreeFull » Sun, Dec 04, 2016, 5:15 PM UTC

eropple wrote: post #124

baq wrote: post #112

Earlier quoted context omitted.

You're not adding addresses together, that doesn't make sense. You're adding ints to addresses, it's a completely different property, even if the representation happens to fit into the same amount of bits. Nothing more than a convenient coincidence.

You're right, I'm not adding addresses together. If you read my post, I say I'm adding to addresses, which you do to--now hold onto your hat--find the next one in sequence. And that, quite obviously, works because they are integers and map to an address space that matches the complete space, from 0x00000000 to 0xFFFFFFFF (and the equivalent 128-bit space for IPv6) of their bit length. It's not "a convenient coinciden…

I think what baq is saying is that IP addresses are torsors http://math.ucr.edu/home/baez/torsors.html . It makes sense to give them a type where you can't add two IP addresses to each other (but you can still subtract to get an integer, and add integers).

Re: Rust: 128 bit integers preparing to be released

#157

Post by steveklabnik » Sun, Dec 04, 2016, 5:39 PM UTC

latrasis wrote: post #58

steveklabnik wrote: post #41

Earlier quoted context omitted.

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.

Thanks. It's pretty much just a part of my life at this point.

Re: Rust: 128 bit integers preparing to be released

#158

Post by MaulingMonkey » Sun, Dec 04, 2016, 5:42 PM UTC

Veedrac wrote: post #138

TillE wrote: post #130

Earlier quoted context omitted.

Floating point is awful if you care about precision.

What scenario would you need more than 53 bits of precision in a time variable for? Even eropple's somewhat excessive subsecond-accurate timing for an event several hundred years ago has plenty of room to spare with 53 bits.

"Absolute" timestamps. If you're using a double to represent, say, epoch time (technically relative to the relatively recent 1/1/1900), your precision has dropped off to about half a microsecond or so. I read GPU profiling results in nanoseconds.

You can work around the problem - time since program start, time since capture start, etc. - of course, this can lead to fun edge cases, where e.g. Windows 95/98 crashed due to a 32-bit milliseconds timer rollover after around 50 days. For comparison, pow(2,53) nanoseconds is only a little over 100 days. Of course, a floating point value won't roll over in quite the same way, but...

The problem is surmountable if you throw enough edge case handling at the problem. Force the devs to be vigilant about choosing the necessary precision, the proper time to measure relative to, for each possible application of anything time related, etc...

... or you could just throw more bits at the problem, and suddenly my accounting software can accurately calculate compound interest on both a 400 year old debt, and a 49 nanosecond debt clearing HFT trades, if that's your kind of thing - without as many edge cases to worry about.

EDIT: Use pow(x,y) formatting since HN collapses x double-star y to simply xy ...

Re: Rust: 128 bit integers preparing to be released

#159

Post by seeekr » Sun, Dec 04, 2016, 5:59 PM UTC

Manishearth wrote: post #142

Senji wrote: post #87

Earlier quoted context omitted.

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.

Not GP, but iiuc he is just stating: In order to prevent these kinds of race conditions you can just use any regular locking mechanism. (As you could with many other cases where you'd like to introduce atomicity manually.)

Re: Rust: 128 bit integers preparing to be released

#160

Post by Veedrac » Sun, Dec 04, 2016, 6:29 PM UTC

MaulingMonkey wrote: post #158

Veedrac wrote: post #138

Earlier quoted context omitted.

What scenario would you need more than 53 bits of precision in a time variable for? Even eropple's somewhat excessive subsecond-accurate timing for an event several hundred years ago has plenty of room to spare with 53 bits.

"Absolute" timestamps. If you're using a double to represent, say, epoch time (technically relative to the relatively recent 1/1/1900), your precision has dropped off to about half a microsecond or so. I read GPU profiling results in nano seconds. You can work around the problem - time since program start, time since capture start, etc. - of course, this can lead to fun edge cases, where e.g. Windows 95/98 crashed du…

Yeah, sorry, that was a bit of a knee-jerk response from me. I took TillE's comment to be more a statement of the general (IMO unfounded) mistrust of floating point, and my comment was intended to take it in that light. Once you have values in the domain you're interested in, floating point more than suffices for precision, and generally handles rounding better than the equivalently-sized fixed point variable.

I do agree that a general timestamp needs to be domain-agnostic, and I'm certainly not saying Rust should use it, not least because Rust aims to preserve the semantics of underlying APIs.