On 04/07/2013 23:33, Patrick Walton wrote:
stack segment allocation is the slow path in C malloc, because it's in
a high storage class.
If the segments are allocated from a selection of standard sizes, can
you not have a (hardware) thread-local pool for each size and dump to a
shared pool?
Rust makes heavy use of FFI to call out to C, and C doesn't use
segmented stacks, so Rust assumes they need 2MiB of stack space.
If we get rid of everything in the standard library calling out to C,
it might just mean a reasonable 10-30% performance hit but I don't see
that happening soon.
___
On Windows there's a better way than DWARF or SJLJ to catch exceptions I
learned today. (I have no idea what I am talking about, but here goes from
what I read...)
Windows uses it's own exception handling mechanism known as SEH. GCC
supports SEH on Win64 (and has plans I think later for Win32?)
Still the cost is 10* and the stack is only 2* part of it..so there are
bigger issues .
Speaking of stacks sIngularity used segmented stacks..and it did not give a
big issues ( and that is for the whole OS) .. maybe someone should have a
closer look. Here is a quote . Note the compiler analysis t
On Thu, Jul 4, 2013 at 10:16 PM, Benjamin Striegel
wrote:
> Would moving away from segmented stacks also allow us to bring jemalloc
> back?
Not if we still have them as an optional feature. We'll still hit the
same problem as before.
___
Rust-dev mailin
Would moving away from segmented stacks also allow us to bring jemalloc
back?
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Incidentally, the mingw guys plan to have x32 SEH (not just x64 SEH)
working and available in 2014... something about letting a Borland patent
having to expire...
On Thu, Jul 4, 2013 at 8:25 PM, Thad Guidry wrote:
> Luqman and I found out today some interesting bits from the mngw guys on
> IRC.
Luqman and I found out today some interesting bits from the mngw guys on
IRC...
I'm going to continue documenting what I find on the Wiki page
https://github.com/mozilla/rust/wiki/Note-getting-started-developing-Rust
under a new 64bit Windows building section.
But here is the info so far:
(
I s
On 2013-07-04 10:02:29, Graydon Hoare wrote:
> On 13-07-03 11:32 PM, Lilly Matsson wrote:
> >Hello!
> >
> >I recently made a post on Reddit
> >(http://www.reddit.com/r/rust/comments/1hk25r/rust_on_64bit_windows_7/)
> >asking about 64-bit Windows support, and kibwen urged me to post here to
> >start
On Thu, Jul 4, 2013 at 7:49 PM, Daniel Micay wrote:
> On Thu, Jul 4, 2013 at 6:33 PM, Patrick Walton wrote:
>> On 7/4/13 12:58 PM, Daniel Micay wrote:
>>>
>>> You can create many threads with fixed stacks, they just start off
>>> using 4K instead of however much smaller our segmented stacks will
On Thu, Jul 4, 2013 at 6:33 PM, Patrick Walton wrote:
> On 7/4/13 12:58 PM, Daniel Micay wrote:
>>
>> You can create many threads with fixed stacks, they just start off
>> using 4K instead of however much smaller our segmented stacks will be.
>> A scheduler will just be more expensive than a regul
On Thu, Jul 4, 2013 at 5:33 PM, Patrick Walton wrote:
> 1. There is no way for the compiler or runtime to know ahead of time how
> much stack any given task will need, because this is based on dynamic
> control flow.
There is, unfortunately, no easy way for the user to know ahead of
time either.
On 7/4/13 12:58 PM, Daniel Micay wrote:
You can create many threads with fixed stacks, they just start off
using 4K instead of however much smaller our segmented stacks will be.
A scheduler will just be more expensive than a regular lightweight
task.
The 15-100% performance hit from segmented st
On 13-07-04 12:12 PM, Matthieu Monrocq wrote:
> I thought that .po files were mostly used to translate bits and pieces,
> such as strings used in GUIs, and not full-blown text files such as
> tutorials ?
This is what it was designed for. But it appears to have been extended
to use in documentatio
On Thu, Jul 4, 2013 at 3:52 PM, Matthieu Monrocq
wrote:
>
> 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
You can create many threads
On Thu, Jul 4, 2013 at 9:48 PM, Daniel Micay wrote:
> On Thu, Jul 4, 2013 at 1:02 PM, Björn Steinbrink
> 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 identif
On Thu, Jul 4, 2013 at 1:02 PM, Björn Steinbrink 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 take
On Thu, Jul 4, 2013 at 2:26 AM, Graydon Hoare wrote:
> On 13-07-03 05:06 PM, Tim Chevalier wrote:
>
> > I don't know of any such proposal already, so I encourage you to take
> > the lead. Of course, even with the translations in the tree, there's
> > the risk that they could become out of sync wi
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; Pyt
On 13-07-03 11:32 PM, Lilly Matsson wrote:
Hello!
I recently made a post on Reddit
(http://www.reddit.com/r/rust/comments/1hk25r/rust_on_64bit_windows_7/)
asking about 64-bit Windows support, and kibwen urged me to post here to
start some kind of discussion about the current state of 64-bit Wind
Hello!
I recently made a post on Reddit (
http://www.reddit.com/r/rust/comments/1hk25r/rust_on_64bit_windows_7/)
asking about 64-bit Windows support, and kibwen urged me to post here to
start some kind of discussion about the current state of 64-bit Windows
support.
So, what is the deal? What nee
On 13-07-04 09:02 AM, Huon Wilson wrote:
Hi,
Corey Richardson has hooked up a spare computer to be a basic [bench
slave]; and I've played around with an interface showing timing and
memory profiles, [IRSY]. (It's very much in progress; e.g. I'm going to
add the information from -Z time-passes to
Hi,
Corey Richardson has hooked up a spare computer to be a basic [bench
slave]; and I've played around with an interface showing timing and
memory profiles, [IRSY]. (It's very much in progress; e.g. I'm going to
add the information from -Z time-passes to the memory profile graph.)
It looks
23 matches
Mail list logo
