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

41–50 of 80 posts

Re: Announcing Rust 1.27

#41

Post by jononor »

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…

The screen of a mobile device is off just as much (or more) as it is on. More and more processing is happening in the background, when user is not actively doing something.

Re: Announcing Rust 1.27

#42

Post by steveklabnik »

tzahola wrote: post #35
steveklabnik wrote: post #12

Earlier quoted context omitted.

You did, except that it’s not one pointer, it’s two. This is one way that rust is different than C++; the vtable isn’t stored with the data, but separately, with the “trait object” itself being two pointers to the two things.

>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 points to a vtable pointer, and then all of the data.

In other words, in Rust, a pointer to a shape is

  (pointer to vtable, pointer to data)
whereas, in C++, a pointer to a shape is

   (pointer to shape)
where shape is

   (pointer to vtable, data)
If that's incorrect, I'm quite happy to be corrected! This isn't an area I'm an expert in.

Re: Announcing Rust 1.27

#43

Post by steveklabnik »

harry8 wrote: post #36

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.

Re: Announcing Rust 1.27

#44

Post by stormbrew »

tzahola wrote: post #35
steveklabnik wrote: post #12

Earlier quoted context omitted.

You did, except that it’s not one pointer, it’s two. This is one way that rust is different than C++; the vtable isn’t stored with the data, but separately, with the “trait object” itself being two pointers to the two things.

>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...

A C++ object with virtual methods and some members looks like this, if you put it in terms of C:

  struct ClassVTable {
   void (*firstMethod)();
   void (*secondMethod)();
  }

  struct Class {
   struct ClassVTable *virt;
   int firstMember;
   int secondMember;
  };
and a pointer to it looks like:

  struct Class *objectRef;
A language that uses fat pointers, like rust, has this separated completely:

  struct Class {
   int firstMember;
   int secondMember;
  };

  struct FatPointerToClass {
   struct ClassVTable *virt;
   struct Class *data;
  }

  FatPointerToClass objectRef; // note lack of pointer, it'd be stored on the stack directly for eg.
This means a much simpler object layout in exchange for passing around larger pointers, and it's a good fit for trait-based typing since it doesn't require you to know all possible interface subtypes of the object in order to describe or use its layout.

(please note that I'm using C struct to be precise about the concept, and this should not be taken as a perfectly verbatim description of the actual object layouts in memory)

Re: Announcing Rust 1.27

#45

Post by stochastic_monk »

seanmcdirmid wrote: post #7
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…

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?

Also, if your code has a lot of branching (most of my work wouldn’t benefit from offloading to GPU), or if the data being processed in parallel at a time is too small to make up for memory transfer, it can be the right approach and provide a huge performance boost.

Re: Announcing Rust 1.27

#46

Post by KwanEsq »

steveklabnik wrote: post #8
kbd wrote: post #4

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?

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?

Re: Announcing Rust 1.27

#47

Post by db48x »

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?

Yes, the next edition will allow breaking changes, while still allowing you to use crates written in the older edition.

Re: Announcing Rust 1.27

#48

Post by Coding_Cat »

stormbrew wrote: post #44
tzahola wrote: post #35

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...

A C++ object with virtual methods and some members looks like this, if you put it in terms of C: struct ClassVTable { void (*firstMethod)(); void (*secondMethod)(); } struct Class { struct ClassVTable *virt; int firstMember; int secondMember; }; and a pointer to it looks like: struct Class *objectRef; A language that uses fat pointers, like rust, has this separated completely: struct Class { int firstMember; int seco…

Oh, I didn't know that: this is also great for serializing code where you might have an array of `Class`, it would still be a POD-type to use C++ language.

Re: Announcing Rust 1.27

#49

Post by steveklabnik »

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?

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.

Re: Announcing Rust 1.27

#50

Post by steveklabnik »

db48x wrote: post #47
KwanEsq wrote: post #46

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?

Yes, the next edition will allow breaking changes, while still allowing you to use crates written in the older edition.

some forms of breaking changes. This is of that kind, though we cannot make arbitrary ones.
Post reply on HN