LLVM build times

F

freebuser

Is this normal? still hasn't finished.

1636073097297.png


Under virtualbox client with host as below:

1636073268535.png
 
Yes. It is normal.

P.S.

freebuser said:
Under virtualbox client with host as below:
Click to expand...
The host specs are irrelevant. How much resource have you allocated for the guest? i.e. CPU/core, RAM, and HDD or SSD?

Some tips and tricks to boost performance, a little bit:

VMM's guest setup:
* Increase the number of processors.
* Allocate more memory.
* Use an SSD if it's possible.
* Don't use "Dynamically allocated" for Hard disk. Select the "fixed size".

VMM's host setting (Windows)

* Power management:
1. Run powercfg.cpl
2. Select one of the power profiles -- preferably the High performance, but it doesn't matter.
3. Select "change advanced power setting".

4. In the "process power management" section:
Set "minimum" to 100%.
Set "cooling policy" to "active".
Set "maximum" to 100%.

* Disable the swaping:
1. Run the SYSDM.CPL
2. Advanced tab | Virtual memory | Change
3. Set them all to "no paging file".

* Disable the "Virus & threat protection" if it is possible.

* To reduce background tasks -- some of them are heavy on the HDD:
1. Don't run windows programs when running VMM, and
2. Disable ComputerRestore on your VMM drive, e.g. C:
Disable-ComputerRestore -Drive "C:\"

* [NOT SURE] vmware runs as a service. But I'm not sure about vbox. I don't have it installed right now.
Do your own research, and if you find out that it is run as service then change these settings too:

1. Run the SystemPropertiesAdvanced.exe
2. Advanced | Performance | Settings | Processor scheduler
3. Set it to "Background service".

Guest OS (FreeBSD):
* Set the dev.cpu.0.freq to the max or turbo.
* Change the kern.hz in the /boot/loader.conf:
Code: 
kern.hz=100
 
diizzy said:
Since you're running Windows 10 Pro I can highly recommend Hyper-V (included) over Virtualbox.
Click to expand...
Hyper-V is the best option, esp. for Windows/NT guests. But I had a problem using FreeBSD on the Hyper-V.
emulators/open-vm-tools didn't work. The port is necessary for changing the resolution (GUI). I'm not aware of current status.

When I was comparing vmware and vbox, I noticed that vmware was using less resources -- both RAM and CPU.
It wasn't a precise comparison though. Personally, I prefer to use vmware player. But it (the free version) doesn't have snapshot feature.
 
vigole said:
Hyper-V is the best option, esp. for Windows/NT guests. But I had a problem using FreeBSD on the Hyper-V.
emulators/open-vm-tools didn't work. The port is necessary for changing the resolution (GUI). I'm not aware of current status.

When I was comparing vmware and vbox, I noticed that vmware was using less resources -- both RAM and CPU.
It wasn't a precise comparison though. Personally, I prefer to use vmware player. But it (the free version) doesn't have snapshot feature.
Click to expand...

Is that to run in desktop mode? I only ssh to the Freebsd guest, rarely work directly on the guest.
 
By the way, enabling Hyper-V conflicts with Android AVD. If by any chance you are using Android AVD, then you have to setup a dual-boot system.
One for the Hyper-V, i.e. hypervisorlaunchtype on and one for non hyper-V usage, i.e. hypervisorlaunchtype off.
 
You also want to change this setting in poudriere.conf:
Code: 
# List of packages that will always be allowed to use MAKE_JOBS
# regardless of ALLOW_MAKE_JOBS. This is useful for allowing ports
# which holdup the rest of the queue to build more quickly.
ALLOW_MAKE_JOBS_PACKAGES="pkg llvm* gcc* rust firefox node* mame"
That way the LLVM builds will use more than one core which will greatly reduce their build times. I've added a couple of other ports too, as they were regularly holding up the queue.
 
SirDice said:
You also want to change this setting in poudriere.conf:
Code: 
# List of packages that will always be allowed to use MAKE_JOBS
# regardless of ALLOW_MAKE_JOBS. This is useful for allowing ports
# which holdup the rest of the queue to build more quickly.
ALLOW_MAKE_JOBS_PACKAGES="pkg llvm* gcc* rust firefox node* mame"
That way the LLVM builds will use more than one core which will greatly reduce their build times. I've added a couple of other ports too, as they were regularly holding up the queue.
Click to expand...
Unless you're really memory constrained you can just set like -j2 or -j3 something globally
 
diizzy said:
Unless you're really memory constrained you can just set like -j2 or -j3 something globally
Click to expand...
You could set this:
Code: 
# By default MAKE_JOBS is disabled to allow only one process per cpu
# Use the following to allow it anyway
# ALLOW_MAKE_JOBS=yes
But it's not always that beneficial, it depends on your builds and the system itself. Sometimes it's better to have 4 jobs all compiling on a single core (on a 4 core machine) and finish at the same time than having 4 jobs running each using all 4 cores (and thus steal each others resources) and taking a lot longer to complete.
 
SirDice said:
You also want to change this setting in poudriere.conf:
Code: 
# List of packages that will always be allowed to use MAKE_JOBS
# regardless of ALLOW_MAKE_JOBS. This is useful for allowing ports
# which holdup the rest of the queue to build more quickly.
ALLOW_MAKE_JOBS_PACKAGES="pkg llvm* gcc* rust firefox node* mame"
That way the LLVM builds will use more than one core which will greatly reduce their build times. I've added a couple of other ports too, as they were regularly holding up the queue.
Click to expand...

I did that and still only one builder is compiling. Is there any other setting I need to change for this to work?
 
freebuser said:
I did that and still only one builder is compiling.
Click to expand...
How many cores does the machine have? By default it will spawn a number of jobs depending on the core count.

Code: 
# parallel build support.
#
# By default poudriere uses hw.ncpu to determine the number of builders.
# You can override this default by changing PARALLEL_JOBS here, or
# by specifying the -J flag to bulk/testport.
#
# Example to define PARALLEL_JOBS to one single job
# PARALLEL_JOBS=1

# How many jobs should be used for preparing the build? These tend to
# be more IO bound and may be worth tweaking. Default: PARALLEL_JOBS * 1.25
# PREPARE_PARALLEL_JOBS=1

Another thing that can happen is that this port is a dependency for a bunch of other ports. Those will all need to wait until that dependency is built. If you regularly have a port that's holding up the queue you probably want to add it to ALLOW_MAKE_JOBS_PACKAGES so it gets built as fast as possible.
 
SirDice said:
How many cores does the machine have? By default it will spawn a number of jobs depending on the core count.
Click to expand...

6 cores (12 threads). Just checked the resource monitor it seems it is using 6 threads (I specified this using J6 in poudriere.)
So it seems working but does not reflect in the web monitoring.
 
poudriere also has ability to use precompiled binaries, look for poudriere bulk -b
I use it specifically for devel/llvm and lang/rust so that notebook is not stressed by compiling both from source.
 
SirDice said:
How many cores does the machine have? By default it will spawn a number of jobs depending on the core count.

Code: 
# parallel build support.
#
# By default poudriere uses hw.ncpu to determine the number of builders.
# You can override this default by changing PARALLEL_JOBS here, or
# by specifying the -J flag to bulk/testport.
#
# Example to define PARALLEL_JOBS to one single job
# PARALLEL_JOBS=1

# How many jobs should be used for preparing the build? These tend to
# be more IO bound and may be worth tweaking. Default: PARALLEL_JOBS * 1.25
# PREPARE_PARALLEL_JOBS=1

Another thing that can happen is that this port is a dependency for a bunch of other ports. Those will all need to wait until that dependency is built. If you regularly have a port that's holding up the queue you probably want to add it to ALLOW_MAKE_JOBS_PACKAGES so it gets built as fast as possible.
Click to expand...

vigole said:
Setting ccache(1) (CCACHE_DIR) may help too.
Click to expand...

Setting -J6 and changing the options to minimal and setting ccache I was able to compile the LLVM11 in just over an hour, this is an improvement from nearly 16hrs of compiling of LLVM11 before.
 
  • Thanks
Reactions: a6h
One thing I'm noticing from OP's screenshot is that he's got LLVM 11 and LLVM 12 compiling at the same time. I'd say that's problematic. On my profile page, one of the comments there (Date July 3, 2021) mentions that the -jN flag only works if ALL deps have been satisfied for a given port. Another comment from the same thread also mentions that the -jN flag (where N=4) for LLVM 10 cuts the compile time down from 2.5 hours to 50 minutes, a 3-fold improvement. My processor is a Ryzen 5 1400 3.4 Ghz. Would be nice if I could link to specific profile posts...
 
Your post explains my experiences. I have "ALLOW_MAKE_JOBS=yes" & "PARALLEL_JOBS=numberofcores+1".
llvm takes 16 hours for me. But that's ok , because on the other cores other packages are being compiled simultaneously.
 
After posting earlier today about my port upgrading practices I decided to take a look at poudriere. llvm12 seems to also only use one job for me:
Code: 
[130i386-default] [2021-11-05_18h19m44s] [parallel_build:] Queued: 108 Built: 103 Failed: 0   Skipped: 0   Ignored: 0   Tobuild: 5    Time: 05:52:41
        [04]: devel/llvm12              | llvm12-12.0.1_6           build           (05:04:48 / 05:17:12)
[05:53:15] Logs: /usr/local/poudriere/data/logs/bulk/130i386-default/2021-11-05_18h19m44s
(Me trying to copy top output, LOL)
Code: 
CPU: 25.4% user,  0.0% nice,  2.4% system,  0.7% interrupt, 71.5% idle

At one point it was building gcc10 simultaneously but GCC finished hours before, so I dunno.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top