Experimental features available in release build #687

Closed
kintel opened this Issue Mar 4, 2014 · 16 comments

5 participants

@kintel
openscad member

If an experimental feature was enabled in a previous snapshot installation, the release version will remember this and make the feature available.
We should either #ifdef away the implementation or make sure we handle this by ignoring the preference setting.

@kintel kintel added this to the 2014 Q1 milestone Mar 4, 2014
@GilesBathgate

If you are referring to the concat feature, what is holding you back from enabling it permanently in the new release? It seems like a good and well tested feature, so why is it still flagged as experimental?

@t-paul
openscad member

Just ignoring preferences would still cause the warning message I think. I'll prepare a patch to skip the actual registration.

@t-paul t-paul self-assigned this Mar 4, 2014
@kintel
openscad member

concat has shown to cause major recursion issues, and enabling it without handling the recursion issues is likely to cause a lot of pain.

@nophead
@kintel
openscad member

The fix only worked when severely limiting it. When I increased the recursion limit to 1000, things started to exhaust the stack before that limit is reached.
When using concat() in practice, even 1000 might be too few to be able to build more complex objects.
..unless I misunderstand which fix you're referring to..

@nophead
@kintel
openscad member

Right, if we can find the stack size, this will make us able to dynamically limit recursion depth.
We still have an issue that we use way too much stack. I'm sure this is fixable with some tedious refactoring. Alternatively implement smth. like tail recursion optimization as that's the most usual case of runaway stack usage.

@t-paul t-paul closed this in 0c2f2b0 Mar 4, 2014
@nophead
@kintel
openscad member

Yep, currently smth. between 1MB and 8MB I think, depending on OS, version and user settings. In addition, default stack size for created threads tend to be small, but we manually bump it to 1MB.
We put way too much data on the stack, so the correct solution is to keep this under control (both memory usage and stack usage).

@GilesBathgate

@nophead Your stack size measurement method seems very "to the metal".

I admit I don't know much about the finer details of how the stack is laid out in memory. And I would assume (like you) that the stack is a contiguous block. I have the feeling that the stack might go from a low to high address on one arch, and from high to low on a different arch. (which you could account for). What I am unsure about is what happens when Address layout randomisation is used.

Is there not some API in the standard c libraries that gives you the amount of stack available, and the amount your process is currently using, and would take care of all the platform dependent idiosyncrasies. (If there are any)

@nophead
@GilesBathgate

It might work... It does depend on the stack memory being contiguous though which after reading this I am not to sure it will be:
http://stackoverflow.com/questions/5086577/is-stack-memory-contiguous

@nophead

I think the only way it can be non-contiguous in user space is if the compiler has support for it and it is enabled. Presumably we have control over that and no motivation to enable it.

@GilesBathgate

Well...either way I think a better approach would be to use a heap based stack as you suggested i.e. std::stack 8MB is a huge amount of memory to need, and OpenSCAD is an interpreted, language so it should be able to have the same recursion depth as a language like say for example Python. I use a QStack<T> in RapCAD, although It doesn't handle recursion very well apparently :/

time ./rapcad recurse.rcad -p
function foo(i){
  writeln(i);
  return foo((i+1));
}

a=foo(1);

1
...
...
32327
Segmentation fault (core dumped)

real    0m1.024s
user    0m0.171s
sys 0m0.093s
@GilesBathgate

Ooops, wrong version of time

Command terminated by signal 11
0.22user 0.16system 0:00.72elapsed 54%CPU (0avgtext+0avgdata 35812maxresident)k
0inputs+0outputs (0major+9152minor)pagefaults 0swaps
@donbright
openscad member

for anyone working on this (even though it is totally off topic) ... it might be helpful to note that the Windows cross-build system sets the stack size for Windows to be the same as on linux, so that bugs will act the same. (dont remember where the issue is on this, but its in the build files).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment