[Gridflow-dev] excessive stack usage?

[Mathieu Bouchard]

On Tue, 19 Aug 2008, Claude Heiland-Allen wrote:
> Claude Heiland-Allen wrote:
>> I had a problem with a large (but not excessively large, and not
>> recursive) gridflow patch segfaulting seemingly at random.
> hmm, seems i need to read man pages (specifically 'man bash') more
> thoroughly - that says it is measured in 1024 byte increments, so it was
> originally 8MB and i set it to 100MB...
>> (Debian Lenny bash default, at
>> least I didn't change anything..):
>> $ ulimit -s
>> 8192

What that is, is that I removed the "mode 6" from internals of GridFlow, 
so that they become easier to modify, but it caused it to use much more 
stack than usual in some situations, especially because I'm trying to 
avoid big mallocs because big mallocs are really slow in OSX. So really, 
the solution is to increase the stack size, at least until I get to do the 
rest of the modifications in the GridFlow internals.

"mode 6" is the mode in which a GridInlet expects to modify and own the 
buffers that it gets. "mode 0" was also removed, in which a GridInlet 
expects to not see any data (this is used by [#dim] [#type] [#finished]) 
but I removed them so that I can simplify internals to a point where I 
could complexify them in a different way more easily. The point is to 
eventually get to better speed optimisations. Removing "mode 6" slowed 
down by only a few %, except perhaps on OSX where I can only suppose that 
it sped up a lot (but I couldn't test it because I didn't have the OSX box 
anymore).

So, that's the kind of thing I'm thinking about, when I think about 
GridFlow internals nowadays, now that Ruby is out of the way, etc. If 
you're curious about those changes, I suppose that we could start a 
discussion about it. Perhaps it would be cool to have this discussion so 
that eventually you can add GridFlow support to pdlua (!!!) and also that 
I feel fine with other externals using GridFlow's internals because 
GridFlow's internals would not need to change anymore in the future, as 
I'd accept forever backwards-compatibility with that (that's why I didn't 
call it "1.0" yet).

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec