Should we increase the stack size?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Should we increase the stack size?

MichaelAtOz
Administrator
I was playing around with old/example24.
With n=6 I get a crash with  Exception Code: c00000fd, usually stack overflow.
That is a contrived problem.
However with let() & a bunch of other new developments there are more people doing list processing & recursion. So this may be more of a problem in the future.

Double it?
Admin - PM me if you need anything,
or if I've done something stupid...

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: Should we increase the stack size?

kintel
Administrator
> On Apr 9, 2017, at 19:38, MichaelAtOz <[hidden email]> wrote:
>
> I was playing around with old/example24.
> With n=6 I get a crash with  Exception Code: c00000fd, usually stack
> overflow.
> […]Double it?
>
https://github.com/openscad/openscad/issues/1446

The crash happens during CSG tree normalization (for preview purposes). This likely won’t be fixed by increasing stack size - we’ll just push the problem ahead of us.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Should we increase the stack size?

wolf
In reply to this post by MichaelAtOz
To quote Wikipedia (https://en.wikipedia.org/wiki/Menger_sponge):
 "The Menger sponge is a closed set; since it is also bounded, the Heine–Borel theorem implies that it is compact. It has Lebesgue measure 0. It is an uncountable set." And because the set is uncountable, there will always be a level that blows the stack. (Uncountable means that there are more elements in the set than there are integers. Thus, with a finite memory size available trying to represent the set accurately is folly - remember my comments on "Lattice Structure".
Besides, my experience has always been that the upper practical limit for OpenSCAD lies around 100 000 items to be unioned, attempting to do one million is where the folly starts. Why? Thermal expansion values range around 1e-5, and unless you control temperature uniformity inside your printer to be within 1 degree Celsius, thermal expansion issues alone will make that kind of accuracy impossible - let alone backlash in your mechanical system. A Menger Sponge of level 4 has 160 000 individual cubes that need to be unioned, level 6 involves 20^6=64million cubes - way too much.
My suggestion is to close both issue 451 and issue 1446, the reason being that they set targets for software that are unrealizable in hardware, because the software demands more storage place and computing time than is available in the universe we live in. But if MichaelAtOz is supplying me with a return ticket to the alternative universe he suggested in "Lattice Structure", I can go there and return with an OpenSCAD that has no bugs, does all work in zero memory and zero time. . .
Speaking of time: issue 451 and issue 1446, when run with level 4, produce the same geometry:

but require substantially different time:
Issue451-4
// Fractal depth (number of iterations)
n=4;
Compiling design (CSG Tree generation)...
ECHO: version = [0, 0, 0]
Rendering Polygon Mesh using CGAL...
Geometries in cache: 1811
Geometry cache size in bytes: 1316952
CGAL Polyhedrons in cache: 48
CGAL cache size in bytes: 103213696
Total rendering time: 0 hours, 34 minutes, 39 seconds
   Top level object is a 3D object:
   Simple:        yes
   Vertices:   109484
   Halfedges:  330006
   Edges:      165003
   Halffacets:  77358
   Facets:      38679
   Volumes:         2
Rendering finished.

Issue 1446:
level 4
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometries in cache: 1770
Geometry cache size in bytes: 1287104
CGAL Polyhedrons in cache: 2
CGAL cache size in bytes: 96977888
Total rendering time: 3 hours, 21 minutes, 5 seconds
   Top level object is a 3D object:
   Simple:        yes
   Vertices:   144104
   Halfedges:  634416
   Edges:      317208
   Halffacets: 278844
   Facets:     139422
   Volumes:         2
Rendering finished.

The - for me - most interesting part is that the Menger Sponge provides me with a test bed for testing the capabilities of a boolean operations library - what is the speed increase relative to the above observations?
MichaelAtOz has suggested that the parallel processing approach currently readied for implementation roughly halves rendering time. Above examples suggest that with different programming a sixfold increase in speed is possible, and my own experiments in that direction indicate that 1000-10000 times faster rendering is possible even without parallel processing - but also that it would require rather radical changes to OpenSCAD.
Thank you for that test bed.

wolf
Reply | Threaded
Open this post in threaded view
|

Re: Should we increase the stack size?

MichaelAtOz
Administrator
> where the folly starts. Why? Thermal expansion values range around 1e-5, and unless you control temperature uniformity inside your printer

Depends on what type of printer you use...in what universe ;)
I wasn't going to print it, I just wanted lots of threads for testing.

Which triggered the thought
"However with let() & a bunch of other new developments there are more people doing list processing & recursion. So this may be more of a problem in the future. "


Admin - PM me if you need anything,
or if I've done something stupid...

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!