Brian Anderson wrote: > >However, this would force the compiler to do quite a lot of > >optimisation if this was going to work efficiently (e.g. as > >efficiently as a conventional for loop). > > It would definitely require a lot of compiler magic, which is > somewhat contrary to Rust's goal of making everything have a > well-defined cost-model.
I can see what you are saying: making the costs transparent. But there are some optimisation transformations that everyone feels that they can count on -- e.g. elimination of temporaries in C code -- i.e. I know that the compiler will fix this up, so there is no cost. > All task stuff is in the library now, partly because it allows more > freedom to experiment. It does take away the compiler's ability to > do any special optimizations with tasks. > > There's definitely a lot of opportunity to improve and influence the > design of the task system still. It would be good if the option was left open to bring it back into the compiler some day, so that later on more optimisation could be done if someone felt that that would be useful. Eric Holk wrote: > It's definitely nice from the standpoint of having fewer languages > forms for users to learn and implementers to debug. It reminds me of > how task join and status notifications got a lot simpler when we > implemented them in terms of messages. However, iterators need to be > really fast, and in most cases the compiler should be able to > optimize them into a really tight loop. I really doubt Rust's task > system will ever be able to be this fast. Sounds like an interesting challenge! > The key benefit of having tasks and communication is that we can > innovate in the task system without having to modify the > compiler. Tasks and communication are still an integral part of the > language, even if their interface is only through the standard > library. For example, communication safety is enforced by the kind > system. The runtime is also very much aware of tasks, and many > dynamic scheduling optimizations can happen here. > > For example, one scheduling trick I think would be worth trying is > making it so when you send a message to a port and the task that > owns the port is blocked on that port, the sending task could yield > directly to the receiving task. I think this might improve > performance for tasks that primarily receive small messages, do a > minimal amount of processing, and then go back to waiting. Yes, I think that choosing whether to yield directly on message passing or spawning is a powerful control that the runtime has. It could make a big difference to performance. For example in my 100,000 task example, if the spawning task yielded directly to the spawned task, and the spawned task ran to completion before yielding, then there would be no explosion of tasks. However then there would also be no parallelism (unless the spawning task was rescheduled onto another core). So that is a pretty powerful choice the runtime is making. The question is how to tune the runtime to make the right choices, over all the possible use patterns of tasks. > There's a spectrum of things various languages call tasks. Rust's > are more like lightweight threads. As such, they should be really > cheap to create and you can comfortable create many thousands of > them, but they will probably always cost more than a function call, > for example. Other languages have lighter task-like things that > could be used for things like iterators, but they tend to require > extensive code transformations to implement efficiently. You're talking about emulating coroutines with a transformation into normal called code? (I forget the name of the transformation.) If you have a cheap coroutine switch operation that shouldn't be necessary. I think I need to study Rust's implementation more. Reading about LLVM's lack of support for coroutine switches was disappointing -- although maybe that has improved. > Rust's design philosophy seems to eschew these high level code > transformations in favor of making it easier to predict what output > the compiler will generate for various programs. Okay. I will watch the list and keep thinking about it and studying Rust more, and see if I can contribute anything later on when I am more up to speed. Jim -- Jim Peters (_)/=\~/_(_) [email protected] (_) /=\ ~/_ (_) Uazú (_) /=\ ~/_ (_) http:// in Peru (_) ____ /=\ ____ ~/_ ____ (_) uazu.net _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
