Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Rust 1.27

blog.rust-lang.org

Post reply on HN
Print view View original

71–80 of 80 posts

Re: Announcing Rust 1.27

#71

Post by littlestymaar »

KwanEsq wrote: post #46
steveklabnik wrote: post #8

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?

IIRC, it will take two editions before removing something: at the first edition the compiler will lint against it (which is already quite a big change: you get tons of new warnings you need to fix) and one edition later, it's an error.

Edit: I didn't see the answer from steveklabnik below. Apparently, it's not clearly decided yet.

Re: Announcing Rust 1.27

#72

Post by pjmlp »

vvanders wrote: post #9
seanmcdirmid wrote: post #7

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.

Have you tried to use Renderscript as well?

Re: Announcing Rust 1.27

#73

Post by sametmax »

computerphage wrote: post #2

The new syntax for dynamically-dispatched traits, “dyn Trait”, is an example of Rust’s persistently excellent consideration of what should be explicit and what should be implicit. Python’s mantra of “explicit is better than Implicit” mostly captures my general feeling, but you can’t make everything explicit. Back before impl Trait existed, just Box seemed very clear. Now that there’s an important thing to differentia…

Python is my goto language but let's not forget it disrespects it's own mantra very often. Like a certain pirate would say, "it's more what you call a guideline than actual rules".

Duck typing is implicit interface.

Foo().bar() is an implicit Foo.bar(Bar()) as self is only explicit on declaration, not call.

__init__ is called and passed parameters implicitly.

__new__ is an implicit class method.

Some time the magic is nice to have. Sometime it's like yield.

Yield implicitly turns your function into a very different object, which makes everybody goes wtf the few first times.

They fixed that with async / await, but I still wish we had a "gen def" to allow yield in bodies, like we have "async def".

Re: Announcing Rust 1.27

#74

Post by stefan_ »

flipgimble wrote: post #37
vvanders wrote: post #9

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.

I don't want to worry you, but on a mobile device with a screen the GPU is always spinning. That is where the pixels come from after all. I get your point that there are energy efficiency tradeoffs to consider. However for massively data parallel tasks like image operations, 3d graphics, machine learning, vision etc, I haven't seen SIMD implementation come close to GPU compute in terms of efficiency. Perhaps short li…

Pixels on screen come from the display controller, which on mobile is often a distinct piece of IP from the GPU, unlike desktop systems. Scenarios like watching a video full screen can often happen without GPU involvement at all.

Re: Announcing Rust 1.27

#75

Post by steveklabnik »

lewisinc wrote: post #66
steveklabnik wrote: post #49

Earlier quoted context omitted.

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.

I feel like a warning for one edition and error on the next would make it straightforward as to how much time is left to update the code.

That’s generally true, the question is, do you warn in 2015 or 2018?

That being said, this particular fix is 100% automatable, and rustfix can already do it, so the time to update is “a few seconds”.

Re: Announcing Rust 1.27

#76

Post by steveklabnik »

tzahola wrote: post #68
steveklabnik wrote: post #42

Earlier quoted context omitted.

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…

That’s absolutely correct. I get it now, that you meant the “pointer to the vtable” under “vtable” in your original post.

Ah, I see. Yes, I should probably have been more clear there. Thanks for pointing that out.

Re: Announcing Rust 1.27

#77

Post by cesarb »

simias wrote: post #69
dbaupp wrote: post #62

Earlier quoted context omitted.

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!().

That and GCC's format is not exactly great. I'm generally looking unfavorably towards NIH but in this instance I really hope they figure out something better.

GCC's format mostly exposes parts of GCC's internal machine description language (to the point that, in the past, most of it was documented only on the "GCC internals" part of the manual). It comes from a simpler time.

Re: Announcing Rust 1.27

#78

Post by eternalban »

computerphage wrote: post #3

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…

Correct my possible misunderstanding but isn't this fabled "power" at best x4 performance gain and not really in the same league as GPU-esque?

Re: Announcing Rust 1.27

#79

Post by antoinealb »

eternalban wrote: post #78
computerphage wrote: post #3

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…

Correct my possible misunderstanding but isn't this fabled "power" at best x4 performance gain and not really in the same league as GPU-esque?

Depending on your operations, e.g. With small buffers that fit in a cache line, transfers to GPU memory could cause GPU esque performance of less than 4x, even less than 1x whereas SIMD still provides benefits.

Re: Announcing Rust 1.27

#80

Post by vvanders »

pjmlp wrote: post #72
vvanders wrote: post #9

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.

Have you tried to use Renderscript as well?

No because RS abstracts away how the computation is queued, what latency is involved and has some pretty non-trival overhead in the framework its self.

Like I mentioned above, earlier GPUs are pretty poor at fine grained scheduling + latency and NEON has pretty ubiquitous support on the target devices we were shipping.

Post reply on HN