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

21–30 of 80 posts

Re: Announcing Rust 1.27

#21

Post by Entalpi »

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?

In matemathics (and thus HPC/scientific computing/image processing/data science/scientific computing/etc) it is very common to multiply different matrices together which SIMD brings huge speedups for.

Re: Announcing Rust 1.27

#22

Post by _wmd »

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?

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.

Re: Announcing Rust 1.27

#23

Post by majewsky »

makmanalp wrote: post #17
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?

Stuff like compression algorithms, some codecs (not all use GPU), some high-performance parsers, some encryption stuff (e.g. openssl), some databases (often column stores, also redis I think), language VMs etc use SIMD. More generally SIMD is useful when you are repetitively performing the same instruction on a long stream of data but you don't want to send it over to the GPU because you don't want to incur the many…

> [when] you can't rely on a GPU being there (e.g. embedded)

Also, most servers have only very basic GPUs (if at all). Unless you're on a dedicated GPU server for machine learning etc., you're going to work with the CPU only.

Re: Announcing Rust 1.27

#24

Post by jcelerier »

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?

Real-time audio processing is bound to CPUs forever. It's the opposite of the data that works with GPU computations : very small chunks of data (generally between 64 and 512 floats or doubles) that you have to process sequentially. For those, SIMD is particularly useful - I got a ~7* increase in throughput recently when porting an effect from naive processing to AVX2 intrinsics - which means that artists can then put much more instances of the effect in parallel.

Re: Announcing Rust 1.27

#25

Post by TheCycoONE »

weavie wrote: post #18
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?

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.

Re: Announcing Rust 1.27

#26

Post by burntsushi »

kibwen wrote: post #16

SIMD! For anyone curious about the performance impact of this feature and a real-world implementation, check out the PR adding support to the regex library: https://github.com/rust-lang/regex/pull/456

And just because this kind of thing is fun, if you use the right kind of pattern on a big enough file, SIMD can be quite noticeable:

    $ rg-with-simd --version
    ripgrep 0.8.1 (rev 223d7d9846)
    +SIMD +AVX
    $ rg-without-simd --version
    ripgrep 0.8.1
    -SIMD -AVX
    
    $ time cat OpenSubtitles2016.raw.en > /dev/null
    real    0m1.280s
    user    0m0.020s
    sys     0m1.257s
    $ time wc -l OpenSubtitles2016.raw.en
    336602465 OpenSubtitles2016.raw.en
    real    0m4.303s
    user    0m3.132s
    sys     0m1.167s
    $ time rg-with-simd -c 'Sherlock Holmes|John Watson|Professor Moriarty' OpenSubtitles2016.raw.en
    6033
    real    0m2.099s
    user    0m1.750s
    sys     0m0.347s
    $ time rg-without-simd -c 'Sherlock Holmes|John Watson|Professor Moriarty' OpenSubtitles2016.raw.en
    6033
    real    0m4.128s
    user    0m3.781s
    sys     0m0.343s
    $ time rg-with-simd -c 'Sherlock Holmes|John Watson|Irene Adler|Inspector Lestrade|Professor Moriarty' OpenSubtitles2016.raw.en
    6731
    real    0m1.989s
    user    0m1.621s
    sys     0m0.366s
    $ time rg-without-simd -c 'Sherlock Holmes|John Watson|Irene Adler|Inspector Lestrade|Professor Moriarty' OpenSubtitles2016.raw.en
    6731
    real    0m18.417s
    user    0m18.000s
    sys     0m0.403s
Looks like `cat` is still faster, so there's some room for improvement. ;-) With a single pattern, we're almost there:

    $ time rg -c 'Sherlock Holmes' OpenSubtitles2016.raw.en
    5107
    real    0m1.333s
    user    0m0.974s
    sys     0m0.357s
This one is mostly thanks to glibc's memchr implementation (which uses SIMD of course), and the regex crate's frequency based searcher.

Of course, I'm presenting best cases here. Plenty of inputs can make ripgrep run quite a bit more slowly than what's shown here!

The crazy thing is that we're still only barely scratching the surface. Check out Intel's Hyperscan project for some truly next level SIMD use in regex searching!

Re: Announcing Rust 1.27

#27

Post by pcwalton »

_wmd wrote: post #22
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?

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 :(

Re: Announcing Rust 1.27

#28

Post by vvanders »

burntsushi wrote: post #26
kibwen wrote: post #16

SIMD! For anyone curious about the performance impact of this feature and a real-world implementation, check out the PR adding support to the regex library: https://github.com/rust-lang/regex/pull/456

And just because this kind of thing is fun, if you use the right kind of pattern on a big enough file, SIMD can be quite noticeable: $ rg-with-simd --version ripgrep 0.8.1 (rev 223d7d9846) +SIMD +AVX $ rg-without-simd --version ripgrep 0.8.1 -SIMD -AVX $ time cat OpenSubtitles2016.raw.en > /dev/null real 0m1.280s user 0m0.020s sys 0m1.257s $ time wc -l OpenSubtitles2016.raw.en 336602465 OpenSubtitles2016.raw.en real…

Uf da, that's still some good speedups.

BTW as a happy daily user of rg thanks for all the work you put into it, definitely shows.

Re: Announcing Rust 1.27

#29

Post by AndrewGaspar »

eberkund wrote: post #5

Yes!! I have been waiting for the new time helpers to arrive in stable. It may be a small thing but is so much nicer and makes Rust feel more like a higher level language when I can do `some_time.subsec_millis()` rather than `some_time.subsec_nanos() / 1_000_000`.

Heh, was just bemoaning this two days ago. Glad I can use them now.

Re: Announcing Rust 1.27

#30

Post by mping »

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?

There's a big cost of moving stuff in and out of the gpu. Unless it's a big/heavy workload, the CPU will be faster because of this.
Post reply on HN