51–60 of 80 posts
Anyone happen to know when inline asm will hit stable?
Stabilizing inline asm in its current form would be a mistake. It's simply not ready.
[0]: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais...
Anyone happen to know when inline asm will hit stable?
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.
Anyone happen to know when inline asm will hit stable?
There are a lot of inline-asm related bugs in the compiler. I'm hitting them almost daily (I'm writing a kernel, so a fair bit of asm is going on here). You can see them in the bug tracker[0]. Stabilizing inline asm in its current form would be a mistake. It's simply not ready. [0]: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais...
Earlier quoted context omitted.
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?
Very useful. SIMD has a much lower barrier to use (doesn't need graphics drivers, GPGPU frameworks etc., almost universally available and fallbacks are easily implemented) and is much easier to target (same language, same toolchain, same memory model). Also notice that the execution model of GPUs and CPUs is quite different. You need a far larger "breadth" of execution to efficiently use a GPU, compared to a CPU.
Earlier quoted context omitted.
The linked thread is good, but the short answer: Box If Foo is a struct, this is a single pointer to the heap. If Foo is a trait, this is a double pointer: a pointer to the data on the heap, and a pointer to a vtable for its methods. These two things are very different, but look similar. That's the mistake. This change separates the two. Now: Box is always the latter, a "trait object". We have to keep the old syntax…
>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?
#![deny(bare_trait_objects)]
EDIT: just realized I mis-parsed "you" in parent. Oh well.
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.
Furthermore, there are worries that depending on the llvm behavior might impede work on alternative rust backends, such as cretonne.
Any idea what SIMD in Rust via WebAssembly will look like?
Earlier quoted context omitted.
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?
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.
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. :)