[rust-dev] IsRustSlimYet (IsRustFastYet v2)

Matthieu Monrocq matthieu.monrocq at gmail.com
Thu Jul 4 12:52:08 PDT 2013


On Thu, Jul 4, 2013 at 9:48 PM, Daniel Micay <danielmicay at gmail.com> wrote:

> On Thu, Jul 4, 2013 at 1:02 PM, Björn Steinbrink <bsteinbr at gmail.com>
> wrote:
> > Hi,
> >
> > On 2013.07.05 02:02:59 +1000, Huon Wilson wrote:
> >> It looks like it's a lot more consistent than the original [IRFY],
> >> so it might actually be useful for identifying performance issues.
> >> (Speaking of performance issues, it takes extra::json ~1.8s to parse
> >> one of the 4 MB mem.json file; Python takes about 150ms; the `perf`
> >> output http://ix.io/6tV, a *lot* of time spent in allocations.)
> >
> > This is to a large part due to stack growth. A flamegraph that shows
> > this can be found here:
> >
> > http://i.minus.com/1373041398/43t7zpBOcgy3CeDpkSht0w/inUqVLvZGEUfx.svg
> >
> > Setting RUST_MIN_STACK to 8000000 cuts runtime in half for me.
> >
> > Björn
>
> I find this is the case for many benchmarks. With segmented stacks,
> we're behind Java, and without them Rust can get close to C++.
>
> I think it should be part of the API in the task module, allowing
> segmented stacks to be used only when they make sense. The first task
> spawned by the scheduler can just have a large fixed stack.
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>

You are here assuming that one will not create many schedulers, which the
current design allows.

(Not necessarily a bad idea, per se, just wanted to point out a possible
new limitation)

-- Matthieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20130704/f9938575/attachment.html>


More information about the Rust-dev mailing list