111–120 of 173 posts
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)
Earlier quoted context omitted.
Not really. They are never added, subtracted, multiplied, or divided. They are never compared for greater-than or less-than. Possibly they are compared for equality. About the only mathematical operations I can think of which are ever done to them are bitwise-anding, bitwise-inclusive-oring, and testing for zero (and, as mentioned, equality).
Yes, really. I mean, I add to IP addresses regularly. How else do you enumerate a subnet (like, what do you think nmap does)? How else do you place, say, twelve machines at 172.17.0.120 through .131? If you're doing string concatenation, you are screwing up. Perhaps it's not enough of a screwup to impact what you do--but definitely wrong enough to impact what I do unless I were to do a lot of extra work in modeling a…
Earlier quoted context omitted.
Measuring time in picoseconds. The current unix timestamp is roughly 2^70 picoseconds, so won't fit in 64 bits.
Can you present any imaginable situation where resolution of arbitrary time/dates to a billionth of a second is not adequate?
Earlier quoted context omitted.
To be fair, you basically never need scale and precision at the same time. Debts from 400 years ago aren't known down to the nanosecond.
I can think of astronomical measures from a couple hundred years ago that are at least second-accurate. Do you want to have DurationSecondsOnly and Duration as types? =)
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.
That's already the case: simply reading a 64-bit integer in a 32-bit processor is not atomic, and that's already possible today.
But that's not a problem in Rust. How would you access the same 128-bit integer from more than one thread?
- You pass the thread a copy of the value: the thread's copy can't be accessed by any other thread, so whether or not it's atomic doesn't matter.
- You pass the thread a mutable reference (&mut) to the value: one of Rust's rules is that there can be only one &mut to a memory location, and while that &mut exists, nothing else can read or modify the value. Therefore it's the same case: only one thread can access the value, so whether or not it's atomic doesn't matter.
- You pass the thread a non-mutable reference (&) to the value: another of Rust's rules is that while any non-mutable reference exists, nothing can modify the value, so the reads not being atomic don't matter.
- You wrap the value in something like a Mutex: the Mutex has a lock which prevents concurrent accesses in the middle of a write.
- You use an Atomic version of the 128-bit integer: this one doesn't exist, so can't be used.
The main reason for all the interest in Rust is that the compiler protects you from many kinds of mistakes. Accessing the same variable from more than one thread, without using a lock or an atomic, is one of the things the compiler protects you from.
Earlier quoted context omitted.
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?
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…
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 the processor will apply the instructions your compiler generates, without barriers.
But the other person answered - you need to ensure that there is an explicit memory barrier yourself when you transfer the object.
Earlier quoted context omitted.
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).
However, Julia is a dynamic language and Rust is a static one.
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).
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.