12 ms·
New Rust runtime turned on. What next?
- pshc 13y agoExcerpt from Graydon's (BDFL) reply: > Despite all these caveats I have a very strong sense that writing the > runtime in Rust will go a long way to validate Rust in the domains it's > aiming for: concurrent and systems programming. Even in the task > scheduler, where there's quite a bit of unsafe code, the shared-nothing > nature of unique types forces you to consciously break the type system > to share memory, and that seems to go a long way to making parallel > programming easier to reason about. Yes, even just reading it seems much clearer since the mutability, lifetime and ownership of each value and reference is spelled out, not just "some Foo* that you have to remember special validity rules about". It's noticeably easier to reason about. Really interesting! When Rust matures (and this dogfooding-via-self-bootstrap is going to accelerate its maturation) it's going to be seriously revolutionary for, for example, modern multi-core video game development. Really excited.
- zhemao 13y agoYes, please. Anything but C++. The progress of Rust and Go make me hopeful for the future.
- charliesome 13y agoGo (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.
- TylerE 13y agoWhen latency matters, just use pool allocation, which makes the GC irrelevant.
- pcwalton 13y agoPools are still traced.
- spullara 13y agoIf 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 13y ago[deleted]
- klausa 13y agoTargeting 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.
- spullara 13y agoThere are concurrent collectors that do not stop the world (e.g. Azul's) that you might want to look at for game development.
- fhd2 13y agoThat'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.
- usea 13y agoI don't completely disagree with your point, and I would not be a person to advocate Go for game development, but "wholly unsuitable" isn't true. A large number of successful games are released that depend on runtimes with similar garbage collectors. Most notably games running on the JVM and CLI. These are "real games" with real performance considerations. See: Minecraft, Terraria, Magicka, AI War, and many more.
- charliesome 13y agoThe JVM and CLR both have generational garbage collectors, which reduces the impact of most GC pauses quite significantly. Go's GC on the other hand is non-generational, which means every GC pause must perform a full scan of all objects in the system.
- usea 13y agoSorry, I misread your post as saying GC in general is wholly unsuited for game development. My mistake.
- charliesome 13y agoI've updated my post, sorry for the confusion!
- seanmcdirmid 13y agoIs there a reason why future work on Go's runtime couldn't fix this problem?
- AndreasFrom 13y agoNot at all, it just takes work.
- sanxiyn 13y agoI wouldn't say impossible, but yes, there are reasons this is difficult to fix in Go compared to Java and C#, and intentionally so. Quoting from http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article (emphasis mine): "To give the programmer this flexibility, Go must support what we call interior pointers to objects allocated in the heap. The X.buf field in the example above lives within the struct but it is legal to capture the address of this inner field, for instance to pass it to an I/O routine. In Java, as in many garbage-collected languages, it is not possible to construct an interior pointer like this, but in Go it is idiomatic. This design point affects which collection algorithms can be used, and may make them more difficult, but after careful thought we decided that it was necessary to allow interior pointers because of the benefits to the programmer and the ability to reduce pressure on the (perhaps harder to implement) collector."
- gillianseed 13y agoI disagree with your 'wholly unsuitable', I came across this game engine (Garage engine) written in Go which certainly doesn't jitter due to the garbage collector. http://www.youtube.com/watch?v=iMMbf6SRb9Q http://www.youtube.com/watch?v=iMMbf6SRb9Q http://www.youtube.com/watch?v=BMRlY9dFVLg http://www.youtube.com/watch?v=BMRlY9dFVLg https://github.com/vova616/GarageEngine https://github.com/vova616/GarageEngine So I say your statement is exagerrated, certainly stop-the-world garbage collectors isn't ideal for games, but it's not 'wholly unsuitable' as long as the gc sweeps aren't costly enough to impact consistent framerate. Had they been 'wholly unsuitable' then the XNA platform would have been dead upon arrival.
- Tichy 13y agoJust avoid producing too much garbage then?
- hamstergene 13y agoWhy is it everytime people talk about replacing C++, someone always comes in and sticks Go into discussion? What does Go have to do with C++?
- masklinn 13y agoOne of the original description/assertion of Go was as a "systems language done right". Many have not been able to move on from that to the effective "a somewhat better java".
- agumonkey 13y ago> dogfooding-via-self-bootstrap Very rare thing. Ok maybe not in language design. But rare otherwise.
- dkhenry 13y agoI think its much less common in language design then we might give it credit for. Many languages run on a VM that is written in C including the likes of Java, Javascript, C#, Ruby and Python ( even PyPy compiles down to C ). I am sure there are others besides C that are self sustaining, but they are _very_ rare
- plorkyeran 13y agoWriting the runtime for a language in that language is fairly unusual, but writing compilers in the language they compile is a similar idea and has always been a popular activity.
- Locke1689 13y agoI think you have a somewhat inaccurate mental model of how things are done. For one, it doesn't really make sense to talk about the CLR when you talk about bootstrapping C#. My project (the Roslyn C# compiler) is a 100% C# implementation of the C# compiler. One thing to keep in mind is that we don't target the CLR. The C# compiler is not a compiler from C# to the CLR, it's a compiler from C# to the CIL (Common Intermediate Language). It's completely reasonable to imagine a machine which runs CIL in hardware instead of in a VM. In this case the answer to the question of whether or not the C# compiler is bootstrapped is, "Yes. Completely." Moreover, it wouldn't make sense to ask whether or not the CLR is self-hosted -- it's called the "Common Language Runtime" for a reason. It's a language-independent virtual machine. In this sense, implementing it in C++ makes just as much sense as implementing it in machine code. Now, my argument here was meant to be without loss of generality. To ask whether or not a language is bootstrapped shouldn't really depend on a runtime, since any language which requires a runtime cannot, by definition, have the runtime written in said language. In this sense, we should only ask whether or not the compiler is bootstrapped, not the entire environment.
- krichman 13y agoI, too, think Rust is going to be revolutionary in the video game industry. Were I a game programmer I would start learning now. In two years at least 51% of all new video game code will be in Rust.
- usea 13y agoI 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 code written in C# for Unity. I think the median game budget is shrinking. More and more games are being made as small projects by small teams. Steam greenlight, kickstarter, humble bundle, and other avenues are enabling curation and funding of smaller games. Unity is far more suited for this kind of development than C++. If you look at smaller studios' job listings, a lot of them prefer experience with Unity. The trend is in full swing at this point. I have no sources to site for the above information. Take it with a grain of salt.
- jzelinskie 13y agoIn 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. Not to mention, you'll also be battling against the traction of their current codebase, which they'll probably hesitant to rewrite in a new language. From a business perspective, I don't think management in some of the larger companies would let that decision fly, either.
- copx 13y agoAll 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.
- martijn_himself 13y agoI 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?
- NickPollard 13y agoVideo 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't just put a bigger processor in or distribute the code over an array of servers. These are other requirements mean that most high level AAA games have to be written to be very highly performant, and in particular, to have reliably consistent latencies. Traditional Garbage Collected languages (Java, C#), whilst achieving high throughput, often struggle with predictable latencies as when GC kicks in, particularly in Stop-The-World collectors, you can get a 10-20ms pause which means you will drop a frame or two. This leads to stuttering which is undesirable. Even modern generational collectors still struggle not to have occasional bad pauses. If something like Azul's continuously compacting collector becomes viable for games, this might be solved, but until it does it is hard (but not impossible) to write high performance (soft) real time games in a GCed language. The result is that most games are written in C++ (sometimes with a small embedded scripting language, mainly Lua, which uses GC) where memory management can be controlled. The downside of this is developer time - it takes large teams of developers lots of time to write games, because the code is largely written at a low level. Rust is higher level than C++ and allows many useful and safe idioms, including a more functional style and better use of immutability. In general, like other higher level languages, Rust would allow a developer to be more productive than in C++, allowing games to be developed more quickly, with fewer developers. It does this whilst still allowing manual control over memory - some parts can be handed over to GC, whilst others can be carefully allocated to the stack or heap and managed manually. This allows predictable allocation and cleanup overhead, and therefore more deterministic frame times. As a games developer, I am extremely interested in Rust as a potential game development language. Disclaimer: I haven't actually written any Rust yet, only looked at code and thought about the potential. I've spent 5 years doing AAA console development in C++.
- batgaijin 13y agoSo they are still using libuv after the rewrite?
- pcwalton 13y agoYes (as the Windows IOCP support is invaluable). But we will probably need to add threading support to it.
- fzzzy 13y agoWhat do you mean add threading support? Last time I used libev (I thought libuv was just libev plus Windows) it allowed creating multiple loops for use in multiple threads just fine. Do you mean adding the ability to move file descriptors across threads into another loop?
- dbaupp 13y agoThe rewrite was essentially to facilitate using libuv more. To paraphrase Brian Anderson: "we needed to rewrite io, and we've just taken a detour to port the runtime."
- deleted 13y ago[deleted]
- pkulak 13y ago> it does implement TCP and UDP on both IPv4 and IPv6 I thought this sort of thing was usually handled by the OS. Can you even get raw sockets on most systems? Or by "implemented TCP", do they mean they can give you back a Unix TCP/UDP socket?
- pcwalton 13y agoBy "implement" it means "integrated into the scheduler".
- roryokane 13y agoHere’s a properly formatted version of the link: https://gist.github.com/roryokane/6189765 https://gist.github.com/roryokane/6189765 (The original message is in Markdown; I just put it in a Gist where it would be rendered as such.)
- dkhenry 13y agoI 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 paragraph about the current scheduler implementation and how basic it is )
- pcwalton 13y agoThree reasons. First, we don't control the kernel and we don't want to make assumptions about thread spawning being cheap on every OS. Second, it lets us implement work stealing, which is a proven method for dynamic parallelism. Third, it lets us do some operations such as RPC from task to task entirely in userspace with no trip through the scheduler or OS kernel.
- jzwinck 13y agoGood points. A counterpoint for #3 is that you could do kernel bypass RPC by installing a driver, but Rust developers probably don't want to write all those drivers, and Rust users wouldn't want to install them. Work (task) stealing is very compelling, and a little paradigm shift is no bad thing. If Rust or any new systems language stands a chance, it should aim high and not too close to the past.
- oconnor0 13y agoAnd then drivers would be required for each OS creating an additional porting burden.
- srisa 13y agoWhat 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.
- 13y ago
- andrewflnr 13y agoI really wish I had space in my TODO list to start a project in Rust. I don't think there's another dev tool I'm more excited about.
- tyleregeto 13y agoI'm feeling the same way, Rust looks fantastic. There are a few things in the language I'm not huge fan of, I don't like overly subtle things in a language. For example, some of the functionality around semi colons seem like they will be a common source of stupid programmer bugs that are difficult to track down. Perhaps the compiler will catch that stuff. Go kinda ruined other languages for me with multiple return values, its something I miss when working in every other language now. And reading through the docs I keep hoping I would stumble across that, though that would create a lot of problems when interfacing with C. Type inference is a huge win, standard libraries looks solid, love the potential around marking variables as mutable, and any language that has no null values makes me happy. Overall, I wish I had more time too.
- usea 13y agoI have limited experience with Rust, but the semicolon stuff you're describing has been one of the most surprisingly positive aspects about it for me. I thought it sounded kind of like a dumb gimmick that just adds subtlety (read: removes simplicity) to something for no reason. However, in practice I've found is really great for making the intent of your code more visible (less cluttered). I miss it when I'm doing C#. Also, I've never come across a situation with too few/extra semicolons causing any kind of logic errors. The compiler will complain at you if you get it wrong.
- chrismorgan 13y agoI had the same experience; having briefly touched Matlab and loathed its difference between semicolon (don't print result) and no semicolon (print result) I was very dubious of it—why not just put `return` there? But when you combine it with the almost-everything-is-an-expression way of doing things, it actually works really well. Makes some forms of state machine exceptionally elegant, for example. So much so that Python has lost some of its charm for me. Also, the type checker ensures that you'll hear about it if you lack a semicolon and emit a value other than unit from a block, without then using it.
- btipling 13y agoI tried to give Rust a try to build some stuff but my project required HTTP and there's no easy SSL solution in place right now. Hope it comes along. I don't have time to contribute much otherwise I would.
- kibwen 13y agoTo quote Brian Anderson (the OP), one of the next steps in the I/O rewrite is "Implementing a new HTTP client on top of rt::io, possibly using Chris Morgan's HTTP code, for use in Servo". So hopefully within the year we'll see the beginnings of a robust HTTP lib that's worthy of a Mozilla-brand browser engine.
- btipling 13y agoThat's awesome!
- chrismorgan 13y agoNote that that is HTTP; SSL will be likely to come quite a bit further down the track.
- zokier 13y agoUse FFI to use some C SSL library? http://static.rust-lang.org/doc/tutorial-ffi.html http://static.rust-lang.org/doc/tutorial-ffi.html
- Dn_Ab 13y agoI haven't written anything in Rust yet but one of its most interesting aspects is its support for linear types. I expect that will share the same kind of perspective enriching attribute of learning logic, array or functional paradigms. While it's certainly not the first language to support substructural types, it looks the only one with a decent chance of developing a meaningful ecosystem. The linear logic of J.-Y. Girard suggests a new type system for functional languages, one which supports operations that ``change the world''. Values belonging to a linear type must be used exactly once: like the world, they cannot be duplicated or destroyed. Such values require no reference counting or garbage collection, and safely admit destructive array update http://homepages.inf.ed.ac.uk/wadler/topics/linear-logic.html http://homepages.inf.ed.ac.uk/wadler/topics/linear-logic.htm... An interesting bit of trivia about linear types is they are in some sense the closest thing to programming a quantum computer this side of qubits (where no cloning dictates qubit variables can only be used once in a function term).
- oconnor0 13y agoI believe Clean also uses linear types.
- masklinn 13y ago> 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?
- smosher 13y ago> 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.
- masklinn 13y ago> I've been assured that it's the plan. Excellent [twirls mustache] > I have no idea how much of it works right now though. Yeah I don't expect it to work at this point, but knowing it's one of the end-goals is good.
- pcwalton 13y ago> 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? Right now it's the former, but Aaron Todd has a pull request to switch it to the latter.
- brson 13y agoThe implementation on master currently uses a single queue, but very shortly it will be converted to work stealing. Tasks can be 'pinned' to their own scheduler (i.e. thread) with `spawn_sched(SingleThreaded)`, and this is very important for tasks that call foreign code that blocks. That's about the extent of the configurability at the moment, but I anticipate at least one other 'mode' in the future for coping with blocking tasks that don't want to be pinned to a specific thread.