On Thu, Jul 4, 2013 at 9:48 PM, Daniel Micay <danielmi...@gmail.com> wrote:
> On Thu, Jul 4, 2013 at 1:02 PM, Björn Steinbrink <bstei...@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@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
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
