On 10/29/13 11:43 PM, Ben Kloosterman wrote:
What i think hasnt been discussed ( though it has previously) is how
much of a penalty segmented stacks represent and what it could be ..
No, we tried all sorts of optimizations. Look in the history at the
scheduler code. That path was heavily optimized in the common case.
In terms of memory allocations a faster expansion or greater reuse from
a segment pool ( Why does the scheduler segment pool start empty. I
would have thought you would have 2Meg worth pre allocated - one runs
in the context of a microbench the other allocated before hand ( like C
stacks) ) . a 4^N expansion of each stack would result in more
contigous stacks. And if stack is unused for a long time hand some
segments back.
We tried it. The performance cost was still very high compared to C.
I know Jonathan Shapiro also thinks that we didn't try hard enough, but
when you're competing against C function calls (2 ns?) there is
extremely little wiggle room. Even 10 instructions means you're at least
2x slower.
In terms of the stack size check , as has been mentioned you can do
more with some analysis , each method gives an indication of worst
cases stack growth , these can then be added together to reduces checks
by 80% and hence significantly reduce the performance impact .
Citation for the 80% number?
Patrick
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
