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

New Rust runtime turned on. What next?

mail.mozilla.org

Post reply on HN
Print view View original

61–70 of 118 posts

Re: New Rust runtime turned on. What next?

#61

Post by srisa »

dkhenry wrote: post #16

I am no language designer, but I wonder why use libuv and have to worry about implementing a scheduler and all the other components of a run time loop in your language when the kernel will do this for you. I think it would make more sense to provide a better interface to existing kernel structures then leverage a third party library and then re implement kernel functions around it ( I am mainly thinking about the par…

What if someone wants to write a kernel with Rust? This might be a very naive question taking into account my ignorance of language and kernel design.

Re: New Rust runtime turned on. What next?

#62

Post by stormbrew »

dbaupp wrote: post #58
nimrody wrote: post #53

Earlier quoted context omitted.

You forget a few points: * Games require portability. Not many platforms will have a rust compiler (Not to mention that current C++ compilers are very mature and highly optimizing). * Current C++ libraries. They are probably heavily templates-based and will be difficult to port.

> * Games require portability. Not many platforms will have a rust compiler (Not to mention that current C++ compilers are very mature and highly optimizing). Rust uses LLVM as the backend, so any platform that Clang supports, Rust can too. (And also, it has the optimisations built in.) In fact, there's already support in the compiler for x86, x86-64, arm, and mips. (I'm not sure if mips actually works, but arm defin…

Really the portability that matters in this case (games) is probably Windows, which llvm and clang do not target very well at this point.

Re: New Rust runtime turned on. What next?

#63

Post by masklinn »

> tasks are now migrated across threads by the scheduler, whereas in the old scheduler a single task was always run in the same thread.

Is that done by having a single task queue with multiple schedulers, or through work-stealing by schedulers with no ready tasks in their queue?

Would this open the possibility of configuring schedulers (including individually)? E.g. ensuring a given task stays pinned on a specific scheduler, and said scheduler accepts no more task, that kind of things?

Re: New Rust runtime turned on. What next?

#64

Post by marijn »

srisa wrote: post #61
dkhenry wrote: post #16

I am no language designer, but I wonder why use libuv and have to worry about implementing a scheduler and all the other components of a run time loop in your language when the kernel will do this for you. I think it would make more sense to provide a better interface to existing kernel structures then leverage a third party library and then re implement kernel functions around it ( I am mainly thinking about the par…

What if someone wants to write a kernel with Rust? This might be a very naive question taking into account my ignorance of language and kernel design.

Look at https://github.com/pcwalton/zero.rs . It's not very far yet, but it proves that it is viable to run Rust without a runtime.

Re: New Rust runtime turned on. What next?

#65

Post by [deleted] »

spullara wrote: post #47
pcwalton wrote: post #12

Earlier quoted context omitted.

Pools are still traced.

If you pool everything, the GC never runs and tracing is irrelevant. However, getting to there is very difficult. Better is to just make sure you throw almost everything away before the next GC, have a small permanent runtime set of objects and accept 10-20ms stop the world young gen collections.

[deleted]

Re: New Rust runtime turned on. What next?

#66

Post by klausa »

spullara wrote: post #47
pcwalton wrote: post #12

Earlier quoted context omitted.

Pools are still traced.

If you pool everything, the GC never runs and tracing is irrelevant. However, getting to there is very difficult. Better is to just make sure you throw almost everything away before the next GC, have a small permanent runtime set of objects and accept 10-20ms stop the world young gen collections.

Targeting 30fps, you have 33ms to render whole frame. Losing 20 ms of that to GC would make things… challenging.

And if you're targeting 60fps, that's 16ms. Stop the world for 20ms, and you've missed 1 and 1/4 of a frame.

Re: New Rust runtime turned on. What next?

#67

Post by fhd2 »

TylerE wrote: post #11
charliesome wrote: post #9

Earlier quoted context omitted.

Go (at least as it stands today with its non-generational, stop the world, mark and sweep GC) is wholly unsuitable for video game development where unpredictable latency must be avoided.

When latency matters, just use pool allocation, which makes the GC irrelevant.

That's how people manage to make games despite GC, but I always thought it's a huge hack, having been there. If all you do with your GC is fight it, is it actually a good idea to have it?

One thing that makes me excited about Rust is that GC is optional.

Re: New Rust runtime turned on. What next?

#68

Post by copx »

jzelinskie wrote: post #59
usea wrote: post #45

Earlier quoted context omitted.

I think you may be overestimating the pace of change. C++ is quite entrenched for industrial-strength game projects. The network effect is strong, the tooling is mature, and the projects are largely driven by C++ experts. Even if we see Rust 1.0 by the end of the year, it will take a lot of time for that kind of change to occur in the industry, if it ever does. I think you're much more likely to see 51% of new game c…

In addition to your point, I'd like to stress that it is the game engines that are C++. Many engines provide a higher level interface for developers actually make games. You probably won't hook the game developers on Rust. If you want to pitch Rust to the engine guys, you're going to be battling against their toolchains that have been developed for decades and have some of the best static analysis tools under the sun…

All good points but there is one strong argument in favor of Rust: memory safety. It seems to be the norm for games these days to CTD (crash to desktop) sooner or later. I find that unacceptable to the point that it makes me angry.

C++ makes it way too easy to corrupt random sections of memory.. which leads to random CTDs. Rust was designed from the ground up to prevent these dreadful bugs.

AAA games are overwhelmingly written by relatively inexperienced, overworked cowboy coders on a tight schedule who are expected to write optimized code. Expecting C++ code without memory corruption bugs in that situation is simply unrealistic.

As a customer I truly hope the industry adopts Rust or another language where memory corruption is impossible or only possible if you explicitly ask for it. I am so sick of CTDs.

Re: New Rust runtime turned on. What next?

#69

Post by smosher »

masklinn wrote: post #63

> tasks are now migrated across threads by the scheduler, whereas in the old scheduler a single task was always run in the same thread. Is that done by having a single task queue with multiple schedulers, or through work-stealing by schedulers with no ready tasks in their queue? Would this open the possibility of configuring schedulers (including individually)? E.g. ensuring a given task stays pinned on a specific sc…

> Would this open the possibility of configuring schedulers ...

I've been assured that it's the plan. I have no idea how much of it works right now though. I've only done one build with the new rt and it doesn't involve tasks.

Re: New Rust runtime turned on. What next?

#70

Post by DanWaterworth »

jzelinskie wrote: post #59
usea wrote: post #45

Earlier quoted context omitted.

I think you may be overestimating the pace of change. C++ is quite entrenched for industrial-strength game projects. The network effect is strong, the tooling is mature, and the projects are largely driven by C++ experts. Even if we see Rust 1.0 by the end of the year, it will take a lot of time for that kind of change to occur in the industry, if it ever does. I think you're much more likely to see 51% of new game c…

In addition to your point, I'd like to stress that it is the game engines that are C++. Many engines provide a higher level interface for developers actually make games. You probably won't hook the game developers on Rust. If you want to pitch Rust to the engine guys, you're going to be battling against their toolchains that have been developed for decades and have some of the best static analysis tools under the sun…

If you want to pitch Rust to the engine guys, you're going to be battling against their toolchains that have been developed for decades and have some of the best static analysis tools under the sun.

I've never used static analysis tools for C++, but from what I've heard, the reason they need to be so advanced is because C++ is so difficult to analyse. Rust, on the other hand, with it's strong, static type system, may not even require extra static analysis tools to be used effectively.

Post reply on HN