This all makes sense.  What I am not clear on is how much of a
performance hit I would take vs my 8 core 4 GHz desktop

On 6/16/2020 9:50 AM, Doug Moen wrote:

I don't think the number of cores makes much difference unless you have
multiple instances open.

On Tue, 16 Jun 2020 at 14:57, jon jon@jonbondy.com wrote:

On Tue, Jun 16, 2020 at 01:50:22PM +0000, Doug Moen wrote:

Or you tell everybody to bring their own SD card. (or supply everybody
with...)

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

The SD sockets on RPI's are not very robust in my experience. It might be
better for them to bring their own USB stick.

On Tue, 16 Jun 2020 at 15:15, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:

On Tue, Jun 16, 2020 at 02:59:35PM +0100, nop head wrote:

So... for Openscad, to be able to make better use of the available
performance on the pi, a "roadmap" for openscad might include: "make
better use of multiple cores".

Keep in mind that intel hit peak-clock-frequency somewhere around a
decade ago. But Moore's law says that transistors keep getting
cheaper, so even though still significant improvements keep being made
in how much work can be done in each CPU clock cycle, in the future
we'll be getting more and more cores in a chip. Currently even the
cheap hardware (e.g. pi) has four cores because they don't know what
otherwise to do with the available transistors!

Roger.

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

On Tue, 16 Jun 2020 09:57:04 -0400
jon jon@jonbondy.com wrote:

If it behaves like most applications a huge one. The PI 4 is pretty fast
for an embedded ARM CPU but it's basically a repurposed media player
engine.

The sysbench table I have to hand scores a PI4 at 394, and a bottom end
Intel i3-8100 at 4210.

The PI4 is 4 core so as this is still a single threaded app unless you
are playing with some of the experimental forks you are actually about
100.

The i3-8100 is 2 core HT so you'll get around 1500 for a typical workload
single threaded with the other thread idle and one core idle.

Going to a fancy high end x86 processor actually doesn't help you that
much because they add cores/threads for the most part. In fact you'd
probably do better with a 'Pentium Gold' branded bottom end 2 core CPU at
4GHz than the i3-8100 as the bottom end desktop CPU has better thermals
(my cheapo low core count box will beat the pants off my dual Xeon with
OpenSCAD unlike say ImplicitCAD)

So with an 8MB PI4 the generic numbers say you'd see a 10 fold loss of
performance. However really someone needs to time actual examples because
generic benchmarks and specific apps can be very different.

Alan

There are experimental versions of OpenSCAD using multiple cores for
rendering but that isn't what is slow for me. I do all my work in preview
mode and only render the STLs to print them. Most don't take long,
especially compared to printing them. E..g 38 parts to make a 3D printer
take 7 minutes to render individually. The slowest one is the shelf bracket
at 78 seconds, most take less than 10s. Drawing the preview from scratch,
which does render() some of the parts takes 4 minutes. The killer is every
simple change takes at least 23 seconds to redraw currently. Most of that
time is running the script, so hard to see how multiple cores would help
that.

On Tue, 16 Jun 2020 at 15:32, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:

On 16.06.20 15:57, jon wrote:

Unless someone completes the "Multi-threaded Geometry
rendering" issue (earning the current bounty of $1060),
the number of cores does not matter much.

So comparing my 2 years old Dell XPS 13 with i7-8550U
@ 4GHz max using the Menger Sponge level 3 example, I
see (even including the monitor in the Raspi price):

Notebook  | Raspi 4 (8GB) | Ratio

35 seconds | 2:46 minutes  |  1 : 4.7
~2200€    | ~250€        | 8.8 : 1

I guess the performance hit is not as bad as one
would imagine while the price is very nice.

I certainly would not suggest using a Raspi for very
complex stuff, but there's lots of things that it will
be able to do in a reasonable way. Especially when
looking at the 64bit/8GB model.

ciao,
Torsten.

Not entirely - it's crept up from 4GHz to 5GHz over that time, but short
of some major process change it's now a slow gain. For high core count
parts the change is even bigger - but that doesn't help OpenSCAD.

The current bounds on processor design are primarily thermal. The size
bound has partly been broken by 7nm and upcoming 5nm processes, but
even more so by the ability to put lots of small dies together in
one device even using different processes.

Single threaded CPU performance has increased a bit more than the clock
rate (instructions per clock has improved) but nothing compared to the
effect of going from 12 cores to 64 cores in the same time (or 2 to 8 in
the consumer space).

(and neither can touch the performance gain for suitable workloads on
GPU based computation)

We had the rapid disk space doubling era, the memory doubling era,
the clock speed doubling era, we are now in the core count doubling era.

The most important thing though is that you can probably beat all of those
gains comprehensively by the use of better algorithms.

Alan

On 16.06.20 17:02, Alan Cox wrote:

Yes! That! So if anyone knows a mathematician who
would be interested in helping with that in the long
run, there's a much bigger gain to be had than any
multi-thread/multi-process support with current CGAL
can ever deliver.

Right now the balance is:

• CGAL: slow, but quite often reliable
• others: faster, breaking geometry worse than CGAL

What would be awesome:

Fast multi-threaded algorithm with GPU support :-)
No need for theoretical correctness, what we need
is a reliable, robust engineering solution.

There's a number of libs claiming that, but all of
those were unmaintained last time I looked. Maybe
time to checked again if things changed...

ciao,
Torsten.