[Gridflow-dev] excessive stack usage?

[Claude Heiland-Allen]

Mathieu Bouchard wrote:
> 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.

That's fine.

> "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).

is there an explanation of the different modes somewhere?  a gridflow 
internals cheatsheet would be handy, better would be structured code 
documentation in the places that matter (I use doxygen for pdlua 
internals, mostly for my own benefit - the internals don't change much 
so I forget how they work...)

> 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).

Yes, it would be nice to write externals compatible with GridFlow (eg, 
an IFS external would be much nicer speedwise than a 
[#store]X[#draw_image pixel] loop type thing).

pdlua support would most likely take the form of a lua package, so you 
can '' require("gridflow") '' , which would fail if gridflow hasn't been 
loaded or so.


Claude