FreeCAD and multicores - multithreads

[easyw-fc]

ldd libGeomBase.so

On my Linux I cannot find this lib both searching on /usr/lib

Code: Select all

find /usr/lib -name libGeomBase

nor after extracting Appimage and searching there

Code: Select all

./FreeCAD_0.19-17175-Linux-Conda_Py3Qt5_glibc2.12-x86_64.AppImage  --appimage-extract
cd squashfs-root
find . -name libGeomBase

On win instead the TKGeomBase.dll is present, and there multicore is working.

[wmayer]

On my Linux I cannot find this lib both searching on /usr/lib

Oops! Of course libTKGeomBase.so

[easyw-fc]

Oops! Of course libTKGeomBase.so

Code: Select all

user@user:~$ find /usr/lib -name libTKGeomBase.so
/usr/lib/x86_64-linux-gnu/libTKGeomBase.so
user@user:~$ cd /usr/lib/x86_64-linux-gnu/
user@user:/usr/lib/x86_64-linux-gnu$ ldd libTKGeomBase.so
	linux-vdso.so.1 (0x00007ffe01729000)
	libTKG3d.so.7 => /usr/lib/x86_64-linux-gnu/libTKG3d.so.7 (0x00007f1b3d47d000)
	libTKG2d.so.7 => /usr/lib/x86_64-linux-gnu/libTKG2d.so.7 (0x00007f1b3d222000)
	libTKMath.so.7 => /usr/lib/x86_64-linux-gnu/libTKMath.so.7 (0x00007f1b3cdc4000)
	libTKernel.so.7 => /usr/lib/x86_64-linux-gnu/libTKernel.so.7 (0x00007f1b3ca1a000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1b3c691000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1b3c2f3000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1b3c0db000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1b3bcea000)
	libtbb.so.2 => /usr/lib/x86_64-linux-gnu/libtbb.so.2 (0x00007f1b3baae000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1b3b88f000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f1b3b687000)
	libtbbmalloc.so.2 => /usr/lib/x86_64-linux-gnu/libtbbmalloc.so.2 (0x00007f1b3b449000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1b3b245000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f1b3ded0000)

So it seems libtbb.so.2 is involved...
The riddle is getting deeper

PS to test the multicore / multithread, it is enough to open the linked STEP file (I just used a script to calculate also the loading time).
The STEP file is downloadable at this dropbox link (it is possible to download it without the need to register, clicking on 'No thanks, continue to view'), and posted at this forum's thread.

[ickby]

It seems that the call of the mesher uses true for parallel meshing independent of operating system (no if else guards):
https://github.com/FreeCAD/FreeCAD/blob ... t.cpp#L928

Last parameter is the parallel switch:
https://www.opencascade.com/doc/occt-6. ... a492180ac6

[nic]

@easyw-fc

Ubuntu 18.10, Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz (4 cores):

Code: Select all

 freecad-daily: 0.19~pre1~201907012108~ubuntu18.10.1 

Code: Select all

loading... 
loading time = 150.33986639976501s
displaying time = 1.4871551990509033s

edit: add Freecad "about"

Code: Select all

OS: Ubuntu 18.10 (i3/i3)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.
Build type: Release
Python version: 3.6.8
Qt version: 5.11.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: French/Switzerland (fr_CH)

[sgrogan]

May be this post would be also relevant

If I remember correctly, I was testing the Boolean OPs. I don't think I tested the tessellation. The way I understand it is, OCC will use openmp and it's internal multi-threading algorithms if USE_TBB isn't st at compile time, and will use TBB if the flag is set. My experiments at the time showed that there was no increase in CPU usage or speed when using TBB vs. not using it, for boolean ops. A good way to test this is to make a large array of intersecting shapes with draft array with fuse=true.

I believe that the 12.1.2 libpack based versions on win don't depend on TBB (I will verify later with depends), as @looo has confirmed the conda based builds do use tbb.

Have you tried @Marksters OOMP_NUM_THREADS=<num> ? I don't know if the AppImage will respect it, but the daily PPA should. This is used in FEM for calculix, in a subprocess call.

[apeltauer]

I believe that the 12.1.2 libpack based versions on win don't depend on TBB (I will verify later with depends), as @looo has confirmed the conda based builds do use tbb.

I also think that the libpack occ does not have tbb support... :/

But i found this on the opencascade site "https://dev.opencascade.org/doc/overvie ... cmake.html"

USE_TBB --> Indicates whether TBB 3rd party is used or not. TBB stands for Threading Building Blocks, the technology of Intel Corp, which comes with different mechanisms and patterns for injecting parallelism into your application. OCCT remains parallel even without TBB product

[easyw-fc]

Ubuntu 18.10, Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz (4 cores):

@nic, thanks for your feedback.
So on Ubuntu stock, FC acts as a single core @100% instead of using the multi-cores...
I have the same result on Mint..

This is disappointing because the computer becomes quite unresponsive and the cpu get triggered to a high temperature level...

But i found this on the opencascade site "https://dev.opencascade.org/doc/overvie ... cmake.html"

USE_TBB --> Indicates whether TBB 3rd party is used or not. TBB stands for Threading Building Blocks, the technology of Intel Corp, which comes with different mechanisms and patterns for injecting parallelism into your application. OCCT remains parallel even without TBB product

That is interesting... so probably the multicores multithreading present on Win is related to loading and parsing the STEP file, more than the OCC process.

Have you tried @Marksters OOMP_NUM_THREADS=<num> ? I don't know if the AppImage will respect it, but the daily PPA should. This is used in FEM for calculix, in a subprocess call.

Yes, I have tried the @Marksters option, without any result.

ping

Is there anyone that could also test the loading of the STEP file on OSX to check if there multicores are triggered?

[TheMarkster]

You get full 100% usage using FreeCAD for other operations, such as Check Geometry with BOPCheck enabled?

I get these results:

loading...
loading time = 254.71051263809204s
displaying time = 11.42221975326538s

(Inside a Windows host Virtual Box)
OS: Ubuntu 18.04.2 LTS (LXDE/LXDE)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.
Build type: Release
Python version: 3.6.8
Qt version: 5.9.5
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedStates (en_US)

In that VM I don't think CPU usage ever got above 40%.

In Windows, these results:

In Windows FreeCAD CPU utilization is around 30% during the import.

step_import_scr.png (233.39 KiB) Viewed 1862 times

loading...
loading time = 300.809000015s
displaying time = 0.00399994850159s

OS: Windows 10
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.16093 +17 (Git)
Build type: Release
Branch: (HEAD detached at 0.18.1)
Hash: f7dccfaa909e5b9da26bf50c4a22ccca9bb10c40
Python version: 2.7.14
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.2.0
Locale: English/UnitedStates (en_US)

Running a BOPCheck on the whole model gets me to 100% cpu, but during the import I think only 1 CPU was being used at a time.

[easyw-fc]

In Windows, these results:

In Windows FreeCAD CPU utilization is around 30% during the import.

Running a BOPCheck on the whole model gets me to 100% cpu, but during the import I think only 1 CPU was being used at a time.

Hi @TheMarkster,
Thanks for testing.

On windows you have to click on the second tab of the Task manager (Performance) and then click on Resource Monitor...
Then you will be able to see all the CPUs loading...
An other useful tool is Open Hardware Monitor
Please re-test it and see on the Resource Monitor ... you probably will see that FreeCAD CPU utilization is around 30% during the import, but using all of your CPUs.

I don't thinkk that testing Ubuntu on a Win VM is representative of the real multicore utilization... VBox normally assigns as default a single core CPU to the VM hw.

Running a BOPCheck on the whole model gets me to 100% cpu,

You get full 100% usage using FreeCAD for other operations, such as Check Geometry with BOPCheck enabled?

I'll let you know my results later on...
Thx again.