Hard to say without seeing your model but I guess there are a lot of
objects that need to be unioned at the end.

Sometimes it can be done in 2D. For example if you make a grill in a panel
by subtracting hundreds of cylinders it will be very slow but if you
subtract circles from a square and then linear_extrude it to make a 3D
panel it will be instantaneous.

On Sat, 13 Jun 2020 at 11:05, amundsen roald.baudoux@brutele.be wrote:

Use 2D as much as possible to avoid 3D difference(). E.g. don't subtract
cylinders, linear extrude a difference of two circles.

Similarly for the two channels, linear extrude the difference of two
squares.

Don't set $fn if you are 3D printing. Set $fa and $fs. I use $fa = 6 and
$fs = 0.25. Sometimes I lower $fa to 1 to when milling.

On Mon, 15 Jun 2020 at 12:10, amundsen roald.baudoux@brutele.be wrote:

Setting $fn to 360 is an obvious culprit, but it's not the real problem.

There's another segment that seems to be doing too much work. (And is
also harder to understand than it needs to be.)

On 6/15/2020 4:09 AM, amundsen wrote:

This steps around the circle three times.  The second and third times
are identical to the first and can be eliminated.

It would then be stepping from 0 to 3*360 by 1/3.  The multiply-by-3 is
cancelled by the divide-by-3s in the body, making the whole thing
unnecessarily complex.  The effect is to step around the circle by 1/9
degree increments; it could do that directly, eliminating all of the
divides.

Net, this is building 9720 linear-extruded blocks 2/3 of which are
redundant.

After eliminating the redundant blocks, you'll still have 3240 of them. 
That's a lot.

I'd have to figure out how big the stair steps involved really are to
know if you need that much resolution.  But assuming for the moment that
you do, you still probably don't need it all the time.  You could do
much of your work at much lower resolution, and only render at full
resolution when you're ready to print.

Something like:

step = 1/9;
[...]
for ( i = [0:step:degres]) {
a = [sin(i) * (enclosure_radius-global_thickness), cos(i) * (enclosure_radius-global_thickness)];
d = [sin(i+step) * (enclosure_radius-global_thickness), cos(i+step) * (enclosure_radius-global_thickness)];
f = [sin(i) * enclosure_radius, cos(i) * enclosure_radius];
g = [sin(i+step) * enclosure_radius, cos(i+step) * enclosure_radius];
reference = [0,0];
translate([0,0,base_thickness]) {
translate([0,0,0]) {
linear_extrude(height = (sin(i * nombre_vagues) * 10)+10, center = false, convexity = 10) {
polygon(points = [a,f,g,d], convexity = 100);
}
}
}
}

and then set "step" to different values depending on what you're doing.

Note:  Your blocks were 1/3 degree wide and stepped in 1/9 degree
intervals; mine are "step" wide, with "step" intervals.

A more advanced answer might be to stop using linear_extruded blocks -
which have flat tops - and instead use polyhedra.  With a polyhedron you
could have a top that slopes, which will more naturally fit the sine
wave that you're trying to generate.  You could probably get away with
many fewer steps that way.  It looks like 1-degree or 2-degree steps
might well be fine

Here's a variation that renders in ~90 seconds for me, versus >10
minutes for even a simplified version of the original.  And the fidelity
is pretty good, maybe even better than the original.  I had to guess at
a value for enclosure_radius; the original didn't provide one.  Dropping
precision to 60 takes it down to 42.  Setting step to 5 and precision to
60 makes it render in 25 seconds.  The fidelity there is probably not
good enough for production, but is probably good enough for
pre-production work.

Somebody should check my polyhedra.  My 3D geometry isn't quite good
enough for me to be sure that the "top" isn't really a quadrilateral,
that it really does need to be split into two triangles.

enclosure_radius=50;
global_thickness = 20;
nombre_vagues = 6;
degres = 360;
base_thickness = 2;
wall_thickness = 4;
precision = 360;
step = 2;
union() {
for ( i = [0:step:degres]) {
abot = [sin(i) * (enclosure_radius-global_thickness), cos(i) *
(enclosure_radius-global_thickness), 0];
dbot = [sin(i+step) * (enclosure_radius-global_thickness), cos(i+step) *
(enclosure_radius-global_thickness), 0];

    fbot = [sin(i) * enclosure_radius, cos(i) * enclosure_radius, 0];
    gbot = [sin(i+step) * enclosure_radius, cos(i+step) * enclosure_radius, 0];
    
    h1 = (sin(i * nombre_vagues) * 10)+10;
    h2 = (sin((i+step) * nombre_vagues) * 10)+10;
    
    atop = abot + [0,0,h1];
    dtop = dbot + [0,0,h2];
    ftop = fbot + [0,0,h1];
    gtop = gbot + [0,0,h2];
    
    reference = [0,0];
translate([0,0,base_thickness]) {
        polyhedron(points=[abot, dbot, fbot, gbot, atop, dtop, ftop, gtop], faces=[
            [0,1,3,2],
            [4,5,1,0],
            [0,2,6,4],
            [5,7,3,1],
            [2,3,7,6],
            [7,5,4],
            [4,6,7]
        ], convexity=10);
        }
}
difference() {
    union() {
        cylinder(h = base_thickness, r = enclosure_radius + wall_thickness, $fn =

precision);
cylinder(h = 64, r = enclosure_radius -20, $fn = precision);
translate([0,0,1]) {
cube([wall_thickness * 2 + 4, enclosure_radius * 2 + 2 * wall_thickness

• 40, 2], center = true);
  }
  translate([5, enclosure_radius+14, 3]) {
  cube([2,20,2], center = true);
  }
  translate([-5, enclosure_radius+14, 3]) {
  cube([2,20,2], center = true);
  }
  translate([5, -enclosure_radius-14, 3]) {
  cube([2,20,2], center = true);
  }
  translate([-5, -enclosure_radius-14, 3]) {
  cube([2,20,2], center = true);
  }
  }
  cylinder(h = 64, r = enclosure_radius - 24, $fn = precision);
  }
  }

A still more advanced answer would construct the entire outer ring as a
single polyhedron, but that exceeds what I want to do today.  (But it
would probably be faster still.)

OpenSCAD only uses one core so it won't go above 12.5%. It does use
enormous amounts of RAM so if it causes swapping you will get less than one
core fully used.

The reason it is so slow is that CGAL uses infinite precision rationals to
represent numbers instead of floating point. As soon as you have curves or
rotation most coordinates become irrational, so the numbers explode, eating
up CPU and memory.

On Tue, 16 Jun 2020 at 14:57, Kevig Kevigsp@hotmail.com wrote:

On 6/15/2020 11:53 PM, amundsen wrote:

I didn't time that one.  But excess objects never helps.

Preview uses your GPU.  Render does not.

It's basically the same as yours, except that where you have a
linear-extruded block with a flat top, it has a polyhedron with a
slanted top.  (Actually, it seems that the top isn't flat, that it needs
to be split into two triangles.  I'm not good enough at visualizing 3D
geometry to confirm that it has to be that way.)  The "bot" values are
your original a,d,f,g coordinates, the bottom of each block; the "top"
values are the same XY coordinates but Z is the top of the block.

Because yours uses flat tops and so must stair-step, you need a lot of
tiny blocks to get a reasonably smooth top surface.  Since this scheme
uses slanted tops it can get a smooth top surface with many fewer blocks.

On 6/16/2020 7:12 AM, nop head wrote:

Nit:  the fraction will depend on what kind of processor you have.

I've never understood the relationship between "sockets", "cores" and
"virtual processors", but I have 1/2/4 and at the moment OpenSCAD is
topping out at ~30% for me.  I assume that it's not reaching 50% because
of competition from other processes.

On Tue, 16 Jun 2020 15:21:27 +0000
Jordan Brown openscad@jordan.maileater.net wrote:

So an x86 processor is a heirarchy

At the bottom you have hyperthreads which are individual threads of code
execution. They share the same silicon directly. The idea is that a
processor has a bunch of things it can be doing at once and the front end
of the processor is responsible for keeping as many of those units busy
at a time as it can. Having two threads of execution helps to ensure that
if one of them stalls say waiting for a value not in cache the other can
fill the gaps, or if one is floating point heavy and the other is integer
and so on...

Cores are instances of the above. They usually share the larger caches.

Sockets are physically separate things plugged into the motherboard and
don't share caches but also don't share heatsinks and thus some thermal
limits.

(there is also another layer in there for some things which are managed
by groups of processors like power, but that's not important here).

In the AMD case however (and a tiny number of Intel ones) the socket layer
is a bit more confused because for the threadripper/epyc they are
essentially built as multiple sockets but all one on thing you stick on
the motherboard.

The ARM world is similar except that I don't believe any ARM does
hyperthreading (and there are good architectural reasons why what makes
sense in one kind of CPU design does not in others)

ARM (and one upcoming x86) also sometimes has big/little where some of
the processors are big and fast and eat power and some are slow and don't.

"Virtual processors" is a windows-ism. What it means depends on what
Windows wants it to mean. On a desktop it probably matches hyperthreads
but that depends on what Windows feels like doing, and if you are running
under a hypervisor (which you may or may not magically be depending how
Windows installed and your configuration).

For a current bottom end x86 desktop you'll have 1 socket, 2 cores and
4 hyperthreads. OpenSCAD can use 1 hyperthread of one core, which if the
other thread is idle is typically around 60-70% of the core's total
performance. So your 30% sounds about right.

A perfectly parallelising OpenSCAD would thus be about 3 times faster on
that box than the current one. A realistic number would probably be
nearer twice. In comparison judging by the performance of some other
toolkits I can easily believe that you'd get a thousand fold performance
improvement by using better algorithms. It's just that the availability
of those in open source is limited and writing them is seriously hard
stuff.

Alan

On 6/17/2020 12:43 PM, amundsen wrote:

The simplest example is two cubes positioned corner to corner:

cube(1);
translate([1,1,0]) cube(1);

but you can encounter it in any number of circumstances.  In this
particular case, I believe the vertical edges of the central cylinder
(which is really an extruded polygon) were periodically lining up with
the vertical edges of the inner sides of the blocks that form the sine wave.

That's not really a surprise, because:

• The cylinder probably has a number of sides that is an exact
  multiple of one degree, and
• The outer blocks are spaced exact multiples of one degree, and
• The inner edges of the blocks are positioned exactly at the radius
  of the cylinder and so exactly at the radius of the cylinder's
  vertical edges.