Announcing Rust 1.27 • Hacker News Board

Re: Announcing Rust 1.27

#31

Post by weavie » Thu, Jun 21, 2018, 10:28 PM UTC

TheCycoONE wrote: post #25

weavie wrote: post #18

Earlier quoted context omitted.

Reading up an static vs dynamic dispatch may help - https://en.wikipedia.org/wiki/Dynamic_dispatch . Essentially Box is static dispatch. You know at compile time which exact methods you are going to call. Box is dynamic dispatch. Since Foo is a trait, at compile time you won't know which methods are called, it depends on the type of the object passed in (as long is it implements the Foo trait).

Your example is misleading. If Foo is a trait Box and Box are the same thing. Impl Foo is for static dispatch. Illustrating the need to dump the old unqualified syntax.

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. When would you use Box vs Box?

Re: Announcing Rust 1.27

#32

Post by steveklabnik » Thu, Jun 21, 2018, 10:35 PM UTC

weavie wrote: post #31

TheCycoONE wrote: post #25

Earlier quoted context omitted.

Your example is misleading. If Foo is a trait Box and Box are the same thing. Impl Foo is for static dispatch. Illustrating the need to dump the old unqualified syntax.

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.

Re: Announcing Rust 1.27

#33

Post by jacobolus » Thu, Jun 21, 2018, 10:54 PM UTC

pcwalton wrote: post #27

_wmd wrote: post #22

Earlier quoted context omitted.

Heh. You can barely move your mouse across the screen without some layer in the architecture executing some SIMD instruction. It's everywhere, and it's going nowhere. Everything from counting the length of a string to rasterizing the text you're reading right now.

I wish font rasterization used SIMD more, but it frequently doesn't. The final blitting step usually does, but important things like the Gaussian blur used for subpixel AA color defringing are still not accelerated on Mac, for instance :(

I thought macs gave up on subpixel aa after the advent of retina displays.

Re: Announcing Rust 1.27

#34

Post by eridius » Thu, Jun 21, 2018, 10:55 PM UTC

pcwalton wrote: post #27

_wmd wrote: post #22

Earlier quoted context omitted.

Heh. You can barely move your mouse across the screen without some layer in the architecture executing some SIMD instruction. It's everywhere, and it's going nowhere. Everything from counting the length of a string to rasterizing the text you're reading right now.

I wish font rasterization used SIMD more, but it frequently doesn't. The final blitting step usually does, but important things like the Gaussian blur used for subpixel AA color defringing are still not accelerated on Mac, for instance :(

Good news, macOS isn't doing subpixel AA any more as of macOS 10.14! ;)

But seriously, if SIMD would be useful there, why doesn't it use it?

Re: Announcing Rust 1.27

#35

Post by tzahola » Thu, Jun 21, 2018, 10:58 PM UTC

steveklabnik wrote: post #12

algesten wrote: post #11

Earlier quoted context omitted.

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…

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

Re: Announcing Rust 1.27

#36

Post by harry8 » Thu, Jun 21, 2018, 10:58 PM UTC

Anyone happen to know when inline asm will hit stable?

Re: Announcing Rust 1.27

#37

Post by flipgimble » Thu, Jun 21, 2018, 10:59 PM UTC

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.

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 lived text pressing and file compression where data access is more random could benefit from SIMD.

Re: Announcing Rust 1.27

#38

Post by oldgeezr » Thu, Jun 21, 2018, 11:09 PM UTC

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?

A friend of mine is playing with neural networks and training them to play reversi. He's working with a lot of matrices so he tried AVX extensions and CUDA. AVX runs circles around CUDA, probably because of the setup time of moving things back and forth to the GPU. Also, CUDA can be a big pain in the ass to get working.

Re: Announcing Rust 1.27

#39

Post by pcwalton » Thu, Jun 21, 2018, 11:09 PM UTC

eridius wrote: post #34

pcwalton wrote: post #27

Earlier quoted context omitted.

I wish font rasterization used SIMD more, but it frequently doesn't. The final blitting step usually does, but important things like the Gaussian blur used for subpixel AA color defringing are still not accelerated on Mac, for instance :(

Good news, macOS isn't doing subpixel AA any more as of macOS 10.14! ;) But seriously, if SIMD would be useful there, why doesn't it use it?

Well, I'm not Apple, so I can only speculate. I wouldn't be surprised if core low-level font rasterization isn't that well maintained, though. Often that stuff was written in the '90s and early aughts and so hasn't been touched.

Re: Announcing Rust 1.27

#40

Post by vvanders » Thu, Jun 21, 2018, 11:15 PM UTC

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…

Nope, I'm well aware. Built/worked on two android based 3D graphics stacks at two different companies and I've worked directly with just about every mobile GPU vendor aside from PowerVR(which is pretty similar to all the other tiled GPUs that are out there).

Your GPU is actually running much less than you'd expect. Unless pixels are changing there's a 95% chance that everything on the system is sleeping and just the display controller is being kept spun up. Battery requirements mean that DVCS on any mobile chipset is going to be really aggressive.

Either way GPU compute has a pretty large overhead both in terms of latency and scheduling. Earlier GPUs didn't schedule nice(hello waiting 16.6ms for your next compute request) and generally the type of places where you use SIMD(3D transforms, audio processing, etc) are so tightly coupled with other CPU operations that even the act of moving them to the SIMD registers is something you need to consider before diving into it. A lot of times waiting for some work queue to complete(or adding pipeline latency by waiting for next frame) just isn't feasible.