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

111–118 of 118 posts

Re: New Rust runtime turned on. What next?

#111

Post by jzelinskie »

pcwalton wrote: post #103
jzelinskie wrote: post #101

Earlier quoted context omitted.

Didn't realize Rust had support for this. At the end of your recent example, it pretty much says doing so sacrifices the runtime entirely. I know Go doesn't support calling from C for reasons similar to this. Where does further development on this functionality sit on the priorities list for Rust?

You don't actually have to sacrifice the runtime entirely anymore; since the runtime is written in Rust you can just start it manually if you want. Making this smoother is a priority. (Brian mentions this in the email, regarding #[start].)

That's very cool. I definitely need to check out things out. Thanks everyone for the interesting discussion.

Re: New Rust runtime turned on. What next?

#112

Post by dbaupp »

kibwen wrote: post #99
marijn wrote: post #64

Earlier quoted context omitted.

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.

I actually don't think we even need zero.rs anymore. Its purpose was to provide noop implementations for all the "lang items" that the compiler expects to find in the stdlib. However, post-0.7 the compiler no longer requires a lang item to be provided unless you actually use a feature that requires it. For an example, see the code at https://github.com/doublec/rust-from-c-example , which is fully runtimeless.

zero.rs (or something like it) is still required, because there's certain lang items that are required/useful (e.g. #[start], destructors, failure, vector bounds checks).

(e.g. https://github.com/huonw/rust-malloc/blob/master/zero.rs)

Re: New Rust runtime turned on. What next?

#113

Post by dkhenry »

j_s wrote: post #109
dkhenry wrote: post #95

Earlier quoted context omitted.

We can imagine something that runs the CLR in hardware, and we can imagine something that runs the JVM in hardware ( actually those things exist , but they don't and both the CLR and JVM are incapable of creating programs that _can_ run on hardware without C shims. Rust is in almost the same boat since they are using the LLVM, but the LLVM differs from the JVM and CLR since it can generate stuff to run on hardware wi…

> actually those things exist , but they don't Not sure what you were trying to say here; one "Java in hardware": http://en.wikipedia.org/wiki/PicoJava

Really big formatting fail. There should be a close parenthesis after the exist. I know the JVM in hardware implementations "exist", but they aren't real implementations since they lack many of the OS like features (Threads , I/O , ... ) That the JVM gives you. Even though we can run byte code in hardware we can't just copy a class file to a processor and execute it. It still needs a run time and a OS to make it full spec.

Re: New Rust runtime turned on. What next?

#114

Post by hga »

NickPollard wrote: post #92
martijn_himself wrote: post #83

Earlier quoted context omitted.

I am intrigued by this. Could you (or anyone) give me a 'explain this to me like I'm a 5 year old' synopsis why you think this is going to revolutionise video game development?

Video game development has several constraints that aren't commonly found in other development such as web development. In particular, for real-time games running at 30 or 60fps (frames-per-second), you have only 33 or 16ms respectively to process an entire frame of updates. Most game development targets fixed hardware such as consoles (PlayStation, Xbox) or mobiles (iPhone, Android), so if your code is slow, you can…

"most high level AAA games have to be written to be very highly performant"

On non-custom hardware like x86 and x86_64 Azul's continuous GC as of when I last checked requires a software write barrier, which is pretty expensive, a 20% or greater penalty.

Re: New Rust runtime turned on. What next?

#115

Post by krichman »

pcwalton wrote: post #78
stormbrew wrote: post #62

Earlier quoted context omitted.

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

We've been focused on first class Windows support since day one. The only major issue for LLVM itself that I'm aware of is the lack of PDB debug info, which is less of a problem for Rust because the system debuggers don't debug Rust in the first place. Most of the clang problems for Windows that I'm aware of relate to all the MSVC extensions in windows.h, which is not a problem for Rust as it doesn't use system heade…

I don't know if you'll see this, but I've been wanting to contribute to Rust for a while now. I've checked through the Github issues, but it's not really clear to me what I should do if there's one I think I can do. How should I approach it?

Re: New Rust runtime turned on. What next?

#116

Post by lucian1900 »

masklinn wrote: post #90
lucian1900 wrote: post #87

Earlier quoted context omitted.

I would think the harder platforms are the consoles: they often come with their own compilers that only support C and C++.

Wasn't that in part due to PPC or custom silicon? The 360 and PS4 are now on x86-64, it should be possible for them to use a more sensible toolchain. also, even before that there were people using "non-standard" toochains e.g. http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

The PS3 and Xbox360 won't go away in the next 5 years. The issue is not so much PPC (which should get support anyway), but various other silly things, like needing to rely on certain interactions between the compiler and runtime library. This is not a huge issue, but any extra bump will deter people from trying.

And indeed it's possible to have an alternate toolchain, but lots of work that is best avoided most of the time.

Re: New Rust runtime turned on. What next?

#117

Post by pcwalton »

krichman wrote: post #115
pcwalton wrote: post #78

Earlier quoted context omitted.

We've been focused on first class Windows support since day one. The only major issue for LLVM itself that I'm aware of is the lack of PDB debug info, which is less of a problem for Rust because the system debuggers don't debug Rust in the first place. Most of the clang problems for Windows that I'm aware of relate to all the MSVC extensions in windows.h, which is not a problem for Rust as it doesn't use system heade…

I don't know if you'll see this, but I've been wanting to contribute to Rust for a while now. I've checked through the Github issues, but it's not really clear to me what I should do if there's one I think I can do. How should I approach it?

Thanks! There are "E-easy" and "A-an-interesting-project" tags on GitHub that you can check out if you're interested.

Re: New Rust runtime turned on. What next?

#118

Post by spullara »

klausa wrote: post #66
spullara wrote: post #47

Earlier quoted context omitted.

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.

There are concurrent collectors that do not stop the world (e.g. Azul's) that you might want to look at for game development.
Post reply on HN