CPU and RAM Resources Allocations Increase for OpenSCAD
Thank you for the tip Alan.
On May 20, 2018 12:32 PM, alan@lxorguk.ukuu.org.uk wrote:
On Sun, 20 May 2018 12:10:50 -0700 (MST)
Still_learning sprocketsjohn@gmail.com wrote:
As an additional note, one of the threads opened in the process indicates
that this is a time critical process, so aside from critical system
functions, OpenSCAD.exe has first call on system resources.
Also, the swap/page RAM capacity is 20 gb, plus system RAM of 8 gb is
still
well short of the
22+ gb size of the openscad.exe incidence.
I agree that a machine with faster processors and 64 GB of RAM would
probably speed things up.
I am not complaining about OpenSCAD, only trying to understand its
quirks.
If OpenSCAD would be best served on a stand alone dedicated server, I can
live with that and building a suitable machine is not a big deal, only
$$$.
Shouldn't cost you much. OpenSCAD is single threaded so there is no point
buying an expensive system to run it. If you need multithreading you need
to move to one of the altenatives that does multi-thread although they
tend to be less nice to use in other ways.
You'll get the same general performance from a dirt cheap i3 as an
equivalent top end processor with the same turbo frequency and TDP. You
can even turn off hyperthreading on it.
Alan
If that is not an option, the next thing would be a RAM upgrade to about
32GB (yes I know it is expensive - but the CPU having to wait for data
Can be cheaper to pick up a second hand Xeon server or workstation. Not
only do they have sufficient sockets to do it with smaller memories but
they also take older RAM and require registered RAM that won't work on
desktops. Makes a 64GB E5-26x0 v1 system really quite cheap. E56xx
systems are even cheaper but a shade slower - they use DDR2 registered
ECC RAM which is dirt cheap.
Last I checked I could pick up a hex core Xeon 5690 (3.4GHz) box with 48GB
of RAM for about €350 (€400 or so for 72GB) which is the same price as
32GB of DDR4 for a current system and not much different to 32GB of DDR3
!
Alan
There are several elephants in the room. single threaded underlying
library in openSCAD is one but one of the others is the $fn=250.
Its worth noting that $fn can be set per operation.
e.e. sphere(r=10, center=true, $fn=100) will only affect that sphere.
So you might have a cylindrical curve where a high polycount is required
to get a smooth surface whjilst at the same time using a sphere to do
rounding on a filletted edge. In which case using $fn=8 for eth sphere
and $fn=250 for eth cylinder will vastly improve the overal speed of
your solution.
Multi-threading in OpenSCAD itself will not make a huge difference
as this is still limited by the final union. Some measurements can
be found in https://github.com/openscad/openscad/pull/1980
It would be just one useful puzzle piece which combined with other
things could really speed up rendering.
ciao,
Torsten.
For small models and/or low-mid $fn, maximise single thread CPU speed + CPU
cache size.
For larger models and/or high $fn, add memory. CPU is useless if you swap.
If you have swapping, add memory.
If you can't add memory, get a small SSD for swapping (or larger for global
replacement).
But this will be slow. For me, swapping to HDD was useless, swapping to SDD
worked but slowly.
Get the fastest memory you can, get an interleaved memory motherboard
(unusual on laptops).
However, 20+GB does point to overly optimistic design parameters...
Add $$$ to the multi-thread bounty
https://www.bountysource.com/issues/394455-multi-threaded-geometry-rendering
, tho that may take a while...needs research into latest CGAL versions.
Having observed Windows internals with OpenSCAD & large models, I can
explain many of the earlier observations. But if you are swapping to HDD the
explanation is simple, it is churning chunks of memory & waiting on I/O,
more than calculating geometry.
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!
Sent from: http://forum.openscad.org/
p.s. Note that I did not mention GPU. Save your money for CPU & memory.
Still_learning, can you share your code? Sometimes there are particular
issues where a small coding change can make a big difference, lots of
co-incident points for example.
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!
Sent from: http://forum.openscad.org/
There's also a branch that has the ability to turn off implicit unions --
it would be fantastic if that and the multithreading were available as an
experimental option in nightly builds for people to play with and see how
they affect the ability to use multiple cores in practise. It's
heartbreaking to see an 8-core machine sitting there spinning on a single
cpu for so long during rendering, while these potentially useful branches
sit bitrotting.
Cheers,
Len.
On Mon, 21 May 2018 at 08:22, Torsten Paul Torsten.Paul@gmx.de wrote:
Multi-threading in OpenSCAD itself will not make a huge difference
as this is still limited by the final union. Some measurements can
be found in https://github.com/openscad/openscad/pull/1980
It would be just one useful puzzle piece which combined with other
things could really speed up rendering.
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
There was a thread a while back about how performance was degraded
because one of the RAM caches was overflowing. Getting dirt cheap RAM
is not always as good a deal as you might imagine
Jon
On 5/20/2018 3:47 PM, alan@lxorguk.ukuu.org.uk wrote:
If that is not an option, the next thing would be a RAM upgrade to about
32GB (yes I know it is expensive - but the CPU having to wait for data
Can be cheaper to pick up a second hand Xeon server or workstation. Not
only do they have sufficient sockets to do it with smaller memories but
they also take older RAM and require registered RAM that won't work on
desktops. Makes a 64GB E5-26x0 v1 system really quite cheap. E56xx
systems are even cheaper but a shade slower - they use DDR2 registered
ECC RAM which is dirt cheap.
Last I checked I could pick up a hex core Xeon 5690 (3.4GHz) box with 48GB
of RAM for about €350 (€400 or so for 72GB) which is the same price as
32GB of DDR4 for a current system and not much different to 32GB of DDR3
!
Alan
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I think union time is proportional to the square of the number of facets of
the two items being unioned. With a "number" of spheres with 61738 facets I
don't think it will finish in a life time.
The way to estimatet how long it will take is to run it with $fn set to
small numbers and look at how the time increases with $fn. Then you can
predict how long it will be for $fn=250. It will be a gross underestimation
because it doesn't take into account swapping, etc. But I am sure it will
show you it is totally impractical to work with such values of $fn in
OpenSCAD.
On 21 May 2018 at 01:29, jon jon@jonbondy.com wrote:
There was a thread a while back about how performance was degraded because
one of the RAM caches was overflowing. Getting dirt cheap RAM is not
always as good a deal as you might imagine
Jon
On 5/20/2018 3:47 PM, alan@lxorguk.ukuu.org.uk wrote:
If that is not an option, the next thing would be a RAM upgrade to about
32GB (yes I know it is expensive - but the CPU having to wait for data
Can be cheaper to pick up a second hand Xeon server or workstation. Not
only do they have sufficient sockets to do it with smaller memories but
they also take older RAM and require registered RAM that won't work on
desktops. Makes a 64GB E5-26x0 v1 system really quite cheap. E56xx
systems are even cheaper but a shade slower - they use DDR2 registered
ECC RAM which is dirt cheap.
Last I checked I could pick up a hex core Xeon 5690 (3.4GHz) box with 48GB
of RAM for about €350 (€400 or so for 72GB) which is the same price as
32GB of DDR4 for a current system and not much different to 32GB of DDR3
!
Alan
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On Mon, May 21, 2018 at 10:16:37AM +0100, nop head wrote:
I think union time is proportional to the square of the number of facets of
the two items being unioned. With a "number" of spheres with 61738 facets I
don't think it will finish in a life time.
The way to estimatet how long it will take is to run it with $fn set to
small numbers and look at how the time increases with $fn. Then you can
predict how long it will be for $fn=250. It will be a gross underestimation
because it doesn't take into account swapping, etc. But I am sure it will
show you it is totally impractical to work with such values of $fn in
Weeeelllll....
This means to me that there is work to be done. Is unioning inherently
quadratic?
Well, yes it is: You have to check for each pair of triangles if they
intersect. Right?
Wrong! For example, you can split up the working space is small
cubes. Go through the list of triangles once, and those that are small
and land in 1 or two of those cubes, you place in a "bin" for that
cube. The big trangles and those that are unlucky go into a bin for
"other". Now from a theoretical point-of-view, the algorithm will
probably still be O(N^2) But from a practical point-of-view, in say
the case where you are unioning a bunch of near-perfect spheres, you
will be able to handle 90 or 99% of the items in O(N) time. This
improves the "feasable dataset size" by a big margin.
In practise, I work at low $fn, until for the final render I increase
it.
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
-- BitWizard writes Linux device drivers for any device you may have! --
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.