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

Writing a small ray tracer in Rust and Zig

nelari.us

Post reply on HN
Print view View original

81–90 of 98 posts

Re: Writing a small ray tracer in Rust and Zig

#81

Post by pcwalton »

OskarS wrote: post #61
steveklabnik wrote: post #57

Earlier quoted context omitted.

To reply to both you and your parent at once, yes, the reason this is in the nursery is that it's not a complete resource yet. I agree that this particular example is bad; it's showing the right pattern for the wrong example. The right way is to use rayon, which is similar to OpenMP in this sense. Each thread would get a pointer to the chunk of the buffer it's operating on. You don't need to write any unsafe code to…

It's good to hear that there's an idiomatic Rust way of doing this that doesn't require unsafe but is still performant. I figured there was, but to an outsider it was not obvious how. This is not actually the first time I've seen this example code. I was wondering how Rust solved this issue (parallel rendering into a single framebuffer) in a way that satisfied the borrow checker, and came across this example. It was…

Here's an article explaining how rav1e, an AV1 encoder aiming for production quality, solves this problem: https://blog.rom1v.com/2019/04/implementing-tile-encoding-in...

Re: Writing a small ray tracer in Rust and Zig

#82

Post by steveklabnik »

OskarS wrote: post #61
steveklabnik wrote: post #57

Earlier quoted context omitted.

To reply to both you and your parent at once, yes, the reason this is in the nursery is that it's not a complete resource yet. I agree that this particular example is bad; it's showing the right pattern for the wrong example. The right way is to use rayon, which is similar to OpenMP in this sense. Each thread would get a pointer to the chunk of the buffer it's operating on. You don't need to write any unsafe code to…

It's good to hear that there's an idiomatic Rust way of doing this that doesn't require unsafe but is still performant. I figured there was, but to an outsider it was not obvious how. This is not actually the first time I've seen this example code. I was wondering how Rust solved this issue (parallel rendering into a single framebuffer) in a way that satisfied the borrow checker, and came across this example. It was…

Oh, someone on Reddit posted the rayon using code https://www.reddit.com/r/programming/comments/c7sgvw/writing...

Re: Writing a small ray tracer in Rust and Zig

#83

Post by gmueckl »

pcwalton wrote: post #79
gmueckl wrote: post #50

Earlier quoted context omitted.

To me, this somehow says that most truely interesting problems can only be solved efficiently in Rust using unsafe. Granted, my definition of interesting may be a bit limited, but my initial takeaway here is that Rusts safety story is much more limited than its proponents claim.

> To me, this somehow says that most truely interesting problems can only be solved efficiently in Rust using unsafe. Even Vec is implemented with unsafe code under the hood. Rust isn't about not using unsafe code anywhere : it's about encapsulating that unsafe code in reusable abstractions that can be easily audited. This is how essentially all languages work to begin with: unless you're using CompCert, the compiler…

Wait, so how exactly is Rust better than C++ again? If I need to bring my own unsafe code to the party, where is the gain? Especially, if - in your words - "This is how essentially all languages work to begin with". I can build "safe" abstractions in any other language, too, can I not?

Re: Writing a small ray tracer in Rust and Zig

#84

Post by CUViper »

gmueckl wrote: post #83
pcwalton wrote: post #79

Earlier quoted context omitted.

> To me, this somehow says that most truely interesting problems can only be solved efficiently in Rust using unsafe. Even Vec is implemented with unsafe code under the hood. Rust isn't about not using unsafe code anywhere : it's about encapsulating that unsafe code in reusable abstractions that can be easily audited. This is how essentially all languages work to begin with: unless you're using CompCert, the compiler…

Wait, so how exactly is Rust better than C++ again? If I need to bring my own unsafe code to the party, where is the gain? Especially, if - in your words - "This is how essentially all languages work to begin with". I can build "safe" abstractions in any other language, too, can I not?

In other languages, nothing ensures that those safe abstractions are actually used in safe ways. You can keep a dangling reference to a C++ vector, but Rust will make sure your references are valid, and you can only escape that with raw pointers in an unsafe block.

Re: Writing a small ray tracer in Rust and Zig

#85

Post by CUViper »

xiphias2 wrote: post #18
oconnor663 wrote: post #3

> But rendering in separate threads turned out to be (unsurprisingly) harder than the way I would do it in C++...It was a bit frustrating to figure out how to accomplish this. Googling yielded a few stack overflow posts with similar questions, and were answered by people basically saying use my crate! Based on some discussion in r/rust ( https://www.reddit.com/r/rust/comments/c7t5za/writing_a_smal... ) I went ahead a…

I still don't understand why Rayon is not part of the Rust standard library. Rust was created to have easy and safe multithreading on the CPU, and Rayon is the clear winner in this space, for me it feels like something that should be part of Rust.

If Rayon were in the standard library, we would never be able to make breaking changes, whereas in a crate we can possibly release a Rayon 2.0. For instance, we might want to make some low-level changes in the way iterators split their workload, per current experiments in rayon-adaptive: https://github.com/rayon-rs/rayon/issues/616

Re: Writing a small ray tracer in Rust and Zig

#86

Post by sitkack »

Tuna-Fish wrote: post #23
sitkack wrote: post #10

Earlier quoted context omitted.

unsafe is the tool u are looking for.

No, there are plenty of safe ways to achieve this in the standard library. The chunks and split families of functions on slices are all designed to do pretty much exactly this.

My comment really upset folks, https://doc.rust-lang.org/src/core/slice/mod.rs.html#991-100...

unsafe is the mechanism that GP needs to use to get multiple contiguous mutable borrows.

There is nothing wrong with unsafe, it is used to build all of the safe abstractions in Rust.

Re: Writing a small ray tracer in Rust and Zig

#87

Post by sitkack »

saagarjha wrote: post #16
sitkack wrote: post #10

Earlier quoted context omitted.

unsafe is the tool u are looking for.

:(

All of Rust's safe abstractions are on top of unsafe. It isn't a bad thing, it just need to be used with rigor.

Splitting a single slice into two mutable slices is done via https://doc.rust-lang.org/std/primitive.slice.html#method.sp... if you want more than that, you will need to roll your own.

I think it would be a great exercise to implement what you are asking for, the docs link directly to the source.

https://doc.rust-lang.org/src/core/slice/mod.rs.html#991-100...

Re: Writing a small ray tracer in Rust and Zig

#88

Post by unrealhoang »

gmueckl wrote: post #83
pcwalton wrote: post #79

Earlier quoted context omitted.

> To me, this somehow says that most truely interesting problems can only be solved efficiently in Rust using unsafe. Even Vec is implemented with unsafe code under the hood. Rust isn't about not using unsafe code anywhere : it's about encapsulating that unsafe code in reusable abstractions that can be easily audited. This is how essentially all languages work to begin with: unless you're using CompCert, the compiler…

Wait, so how exactly is Rust better than C++ again? If I need to bring my own unsafe code to the party, where is the gain? Especially, if - in your words - "This is how essentially all languages work to begin with". I can build "safe" abstractions in any other language, too, can I not?

C++ doesn't have the tool to do so. Just like you can build abstraction for raw data in any language, but only the compiler in static typed language will scream at you at compile time if you use it the wrong way and dynamic language will just believe you will do the right thing.

Re: Writing a small ray tracer in Rust and Zig

#89

Post by eridius »

gmueckl wrote: post #83
pcwalton wrote: post #79

Earlier quoted context omitted.

> To me, this somehow says that most truely interesting problems can only be solved efficiently in Rust using unsafe. Even Vec is implemented with unsafe code under the hood. Rust isn't about not using unsafe code anywhere : it's about encapsulating that unsafe code in reusable abstractions that can be easily audited. This is how essentially all languages work to begin with: unless you're using CompCert, the compiler…

Wait, so how exactly is Rust better than C++ again? If I need to bring my own unsafe code to the party, where is the gain? Especially, if - in your words - "This is how essentially all languages work to begin with". I can build "safe" abstractions in any other language, too, can I not?

In general you don't need to bring your own unsafe code to the party. The standard library contains most of the unsafe code you'll need to use in your normal code, and a handful of well-supported crates (like rayon) provide the more advanced utilities that the standard library doesn't. In most cases you're only writing `unsafe` if you're interacting with C.

And when you do decide you need to use `unsafe` for a non-FFI purpose, Rust provides the tooling to explicitly define the abstraction barrier such that clients of your code don't have to care (or even know) that you're using unsafe internally.

Re: Writing a small ray tracer in Rust and Zig

#90

Post by eridius »

the_duke wrote: post #51
cyphar wrote: post #47

Earlier quoted context omitted.

The problem is that several of those standard library components are no longer recommended for general usage: * As with "syscall", users are strongly suggested to use "golang.org/x/crypto" for crypto primitives like AEAD. All of the crypto bits in the standard library are probably still "okay" but there are better interfaces and more efficient implementations in "golang.org/x/crypto". * The "flags" package is basical…

I agree and I'm not advocating for Rust's std to gain things like http clients or template engines. But some parts of the ecosystem end up in a lot of projects. Conservatively extending std would be good for the language, IMO. To set a standard, reduce compile times, and ease the burden for companies that have hard review requirements for each dependency. Some things I'd like to see in std in a few years: * `serde` *…

I think we could strike a balance. Don't put this stuff in the standard library, but have a category for crates that are officially blessed (or even maintained by) the core team, such that if you trust the Rust stdlib then you should be comfortable trusting these crates. Then provide binary distributions for the built crates for all tier 1 platforms at least (ideally for any platform where a binary distribution of the stdlib is available) and teach cargo how to download those. This way we maintain the ability to version these crates and have breaking changes, but without the overhead of having to recompile these crates.
Post reply on HN