161–170 of 173 posts
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.
Earlier quoted context omitted.
As a side note, what are some use cases for 128 floats?
how about bit look up tables.
fn is_token(c: u8) -> bool
Earlier quoted context omitted.
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.)
Earlier quoted context omitted.
As a side note, what are some use cases for 128 floats?
Some numerically unstable problem require a lot of precision of solve successfully. Similarily, well-behaved problems can be solve with 32-bit floats, but many require 64-bit floats.
Earlier quoted context omitted.
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).
That is a cool link though, I'm gonna give it a deeper read.
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.
There are? It looks closer to 2^14. 2^50mm is around 7.5 au. Sorry to nitpick, but I thought this was a super interesting point!
I rounded a bit over-zealously, thanks for nit picking. It is indeed 2^47.6333. (also assuming you meant 47 not 14.)
Earlier quoted context omitted.
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.
Unless you’re planning to do reverse engineering, or planning to work on a compiler, learning assembler is mostly pointless. In most cases, real-world algorithms contain both vector code in the inner loops, and scalar code everywhere else. When coding assembler you need to use it for both, and assembler ain’t exactly user-friendly. Using C or C++ language with SSE intrinsics is the way to go. All modern compilers support them.
Intel’s documentation is the best so far, but there’s no offline searchable version. I’ve created one: https://github.com/Const-me/IntelIntrinsics/releases
Memory layout is a king. You need to keep the input and output data SSE-friendly: aligned, dense, sequential access patterns are preferred. This could mean you need to [re]design some parts of your software specifically for SSE.
There’re multiple generations of hardware. When writing manually-vectorized code, the compiler won’t tell you what CPUs it’ll run on. SSE2 is the most compatible. Here’s some statistics about Windows users: http://store.steampowered.com/hwsurvey/ click on “Other settings”
glhf
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…
"On September 20, 2013, NASA abandoned further attempts to contact the craft.[76] According to A'Hearn,[77] the most probable reason of software malfunction was a Y2K-like problem (at August 11, 2013, 00:38:49, it was pow(2,32) of one-tenth seconds from January 1, 2000)"