[Gridflow-dev] excessive stack usage?
claudiusmaximus at goto10.org
Sun Aug 24 11:59:28 EDT 2008
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
> 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).
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.
More information about the Gridflow-dev