[rust-dev] IsRustSlimYet (IsRustFastYet v2)
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>
> > 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rust-dev