61–70 of 80 posts
Earlier quoted context omitted.
Wasm doesn’t support SIMD yet, so no way to tell.
Thanks, wasn't able to easily discern how far along the browser SIMD wasm implementations were. Do you see a future where wasm has its own std::arch module?
Earlier quoted context omitted.
Not slated any time soon. There are major questions about the approach; the current implementation is "do whatever LLVM does" which is not in itself stable, and so cannot be our final implementation.
clang manages with "Do whatever gcc does" I wonder why that isn't good enough. Doing nothing useful now as we might want to do something more useful later than what we can now seems a bit self defeating, but I may be missing the point because I want to us inline assembly language in unsafe blocks.
Anyone happen to know when inline asm will hit stable?
SIMD on stable is very exciting news. SIMD unlocks the power of the GPU-esque parallelism that is already inside your CPU. While compilers do try very hard to take advantage of this automatically, it’s not always predictable and can make performance fragile. This is what people are talking about when they refer to “low level control”. Don’t expect that with Rust 1.27 you’ll need to understand SIMD to get anything don…
How useful is SIMD on CPU these days given that most of the touted original applications (back in the MMX SSE days) have been moved over to GPUs?
Earlier quoted context omitted.
Still really useful. We use NEON on Android all the time since there's not a great API there and spinning up a GPU on a mobile device is not something you want to do unless you absolutely have to.
> We use NEON on Android all the time since there's not a great API there and spinning up a GPU on a mobile device is not something you want to do unless you absolutely have to. True regarding Android's APIs being awful, but taken literally, your statement implies that even Core Animation on-GPU compositing from 2007 is bad, which I'm sure you didn't mean. :)
Earlier quoted context omitted.
>We have to keep the old syntax working for stability reasons Will Rust 2018 enable you to remove the old syntax? Or is that a bigger change than the opt-in is allowed to cover?
This kind of change is the kind an edition can make, though I’m not 100% sure if the plan for 2018 is to warn or error on the older syntax.
Earlier quoted context omitted.
Ah ok, I'm back to being confused again then! Is this right: If Foo is a struct then Box is static dispatch. If Foo is a trait Box is dynamic dispatch, but then so is Box - but that is the regrettable point. So from now on, if Foo is a trait we should be writing Box , which is largely syntactic sugar to make the situation more clear? I don't fully understand what the release notes are saying about using impl Trait. W…
You are right. It’s not that you would use Box , but when taking about the two features, it’s easier to compare them, as they’re actually distinct syntactically.
Earlier quoted context omitted.
>This is one way that rust is different than C++; the vtable isn’t stored with the data Which “data” is the vtable stored with in C++? An object contains only a pointer to its vtable, not the vtable itself...
My understanding is that, generally (because (again in my understanding) this is all compiler-specific, not mandated by the standard) is that in C++, there's a single pointer that points to the combo of the vtable and then the data, after it. See http://www.drdobbs.com/cpp/storage-layout-of-polymorphic-obj... for example. While a Shape is a position, outline, and fill, if you have virtual functions, the pointer point…
I get it now, that you meant the “pointer to the vtable” under “vtable” in your original post.
Earlier quoted context omitted.
clang manages with "Do whatever gcc does" I wonder why that isn't good enough. Doing nothing useful now as we might want to do something more useful later than what we can now seems a bit self defeating, but I may be missing the point because I want to us inline assembly language in unsafe blocks.
Clang isn't using LLVM's inline asm directly, it translates from the (stable) GCC format into the internal LLVM one. rustc could theoretically do the same translation, but implementing that is significantly more work than just stabilizing the current implementation of asm!().
Earlier quoted context omitted.
> Rust’s trait object syntax is one that we ultimately regret. Would someone please explain the problem (and the solution) for someone who doesn't know Rust yet?
A trait is like an interface. A struct implementing a trait means it takes on the methods of that interface (but there's more to it, because a trait can have default implementations of of the trait methods). If you want to express something like "this is a variable that holds something that fulfils this trait", without knowing the _actual_ type it is, that variable effectively has an unknown runtime size. std::io::Re…