12 ms·
Rust: 128 bit integers preparing to be released
- bluejekyll 10y agoSweet! IPv6 perfection. besides GPUs, does anyone have experience with any processors that support 128 natively?
- gravypod 10y agoTechnically anyone with a modern Intel CPU has access to the SIMD instructions needed for using 128 bit registers. We probably won't see larger then 64bit bus/address access for some time as we don't need it currently.
- justincormack 10y agoRisc-V has a 128 bit design (as well as 32 and 64), although no one is currently implementing it.
- Const-me 10y agoPCs 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 https://en.wikipedia.org/wiki/SSE2
- bluejekyll 10y agoI've not had a chance to do more than rely on my compiler to target those. I guess I should play with them more.
- Const-me 10y agoA couple of advices for you then. 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 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/ http://store.steampowered.com/hwsurvey/ click on “Other settings” glhf
- aroman 10y agoWhat sorts of applications/domains need or benefit from having 128 bit integers?
- gravypod 10y agoFinance and scientific computing.
- foota 10y agoIs this for implementing faster high precision floating point? It didn't mention 128 bit float.
- gravypod 10y agoFor 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 needed for getting to Mars rather then getting to the moon on 2^8 machines.
- foota 10y agoFun fact: there are ~2^50 millimetres from here to mars
- spladug 10y agoThere 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!
- Dylan16807 10y agoI assume you meant to type 47 rather than 14?
- steveklabnik 10y agoThis title implies some things that aren't quite right. Let's take a step back. The current release of stable Rust is 1.13, beta is 1.14, nightly is 1.15. New features land on master, hence 1.15. So this means that, if it does land, it will become available on nightly soon. But it's still behind a feature flag. So it won't actually come out in Rust 1.15. I am not on the relevant subteam here, so I am not 100% sure of the procedure, but usually, stuff has to sit in nightly for a full release cycle to be eligible for stabilization. So if this lands tonight, it'll be in nightly 1.15, 1.16 will be its full cycle, and it'll be elligible for release in 1.17, which would be March 16, 2017.
- geoffreyiy1 10y agoYea I didn't know how to word it without it becoming more of a sentence and less of a title.
- steveklabnik 10y agoTotally fair! I'm not sure what I would have said either.
- cyphreak 10y agoPeople 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.
- steveklabnik 10y ago> After the quadratic hashes Reference: http://accidentallyquadratic.tumblr.com/post/153545455987/rust-hash-iteration-reinsertion http://accidentallyquadratic.tumblr.com/post/153545455987/ru... (bugs happen, fix is in the queue, life goes on) > rumored memory issues Rumors are just rumors. If you (or anyone else) has more than FUD here, please email https://www.rust-lang.org/security.html https://www.rust-lang.org/security.html .
- kbd 10y agoThanks for the link to the explanation of the hash table bug! > One proposal is that hash tables ought to retain their insertion order... This seems to be something that a lot of hash table implementations are converging on: https://morepypy.blogspot.com/2015/01/faster-more-memory-efficient-and-more.html https://morepypy.blogspot.com/2015/01/faster-more-memory-eff... Do you happen to have a link to the discussion for the Rust proposal?
- steveklabnik 10y agoI don't happen to have a link handy, no. I'm not even sure if it's a formal proposal or something someone happened to suggest one time, off the top of my head.
- tatterdemalion 10y agoHere's the discussion about this problem on Rust's internals forum: https://internals.rust-lang.org/t/help-harden-hashmap-in-libstd/4138 https://internals.rust-lang.org/t/help-harden-hashmap-in-lib...
- cyphreak 10y agoWhy 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.
- andars 10y agoIn case anyone else is interested in reading it, the relevant RFC is here: https://github.com/rust-lang/rfcs/blob/master/text/1504-int128.md https://github.com/rust-lang/rfcs/blob/master/text/1504-int1...
- drfuchs 10y agoThe 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 all operations are atomic, which they have been just by virtue of how the hardware works?
- steveklabnik 10y agoRust 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 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.
- drfuchs 10y agoRight, 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.
- steveklabnik 10y agoIn Rust, you don't get buggy behavior in this kind of case: your program fails to compile.
- searealist 10y agoWhy was this feature accepted whereas 128 bit floats were removed from Rust?
- steveklabnik 10y ago128 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/weekly-meetings/2014-06-24.md#removing-f128 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 concerns. The RFC with justifications for why this was added (and all the related discussion) is already linked elsewhere in this thread. The same could still happen with f128 in the future.
- kevhito 10y agoI 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.
- steveklabnik 10y agoI wasn't involved in the discussion really, so I don't have anything off-hand. I can see why (b) might smell a bit bad, but think of it this way: we share a backend with clang, and so if they think support is mature enough to ship, then that's a very positive sign.
- kevhito 10y agoOh, 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.
- partycoder 10y agoIf you like this subject take a look at gmplib (gnu multiple precision big number library)
- foota 10y agoA fun rule of thumb is that 1 decimal digit is roughly 3 binary digits (because 2^3 is eight, which is almost ten.)
- lorenzhs 10y agoThat'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.
- deleted 10y ago[deleted]
- paulddraper 10y ago> terribly far off lg 10 is 3.322 3 is ten percent accurate. 3.333 is one percent accurate.
- Tempest1981 10y agoI'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)
- IshKebab 10y agoIsn't it easier to remember 10 bits ~= 1000? 32 is about 310, or 1000 1000 * 1000.
- Keyframe 10y agoNot really. BCDs are (can be) four bits per decimal digit. That's something different though.
- amelius 10y agoPerhaps a stupid question, but can't this be generalized to arbitrary size integers?
- the_duke 10y agoLLVM 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).
- youjiuzhifeng 10y agoHowever, Julia is a dynamic language and Rust is a static one.
- SolarNet 10y agoI find your usage of the word static ambiguous. Also Julia is more static than you might expect, and besides it's still a compiled language, it just has a `dynamic` type (ala C# for example) as it's default type. It seems dynamic - like most lisps do - because it supports recompiling a function in a running session (however it doesn't change already compiled code, so not that dynamic).
- m0th87 10y agoYeah, Julia and lisps demand more nuance than static or dynamic labels. This goes into the details for Julia: http://stackoverflow.com/a/28096079 http://stackoverflow.com/a/28096079 Compilation strategy and code hotswapping are independent of static vs dynamic types. Java is statically typed, however its implementations support interpreted execution and code hotswapping.
- StreamBright 10y agoAs of? Would you mind elaborating?
- isoos 10y agoDart (the VM version, not the dart2js output) has arbitrarily sized integer types (`int`), as well as fixed-length ones if you need better maths support (SIMD with vector and matrix calculations).
- qwertyuiop924 10y ago...And once we get Emotion Engine support, Rust will at long last be usable for PS2 hacking.
- interdrift 10y agoSuch large. Very 128. Much bits. Wow.
- marysimpson 10y agoEver require the services of a hacker with discretion and top servicing, i implore you to try your very best to hire only professionals. It will increase your chances of getting your job completed. i was able to hire the services of an elite, asides the fact that i was provided a permanent solution to the service that was rendered me but gave a very efficient customer experience. gmail- pauleta.steelbreaker. M-+19283233115