Gentoo tips

You mean to increase writing speeds, right?
This has nothing to do with compiling I'm guessing?

+1 is the (very) old advice for the number of physical cores. So for my 3930k at home it would have been -j7. Instead I use -j12 .

As for the number of simultaneous build jobs, I've never gone above 3. There is always some package along the way which hogs everything.

It may make compilation a bit faster because you keep all the sources and compiled objects in RAM, though -pipe handles that pretty well by itself. Most useful when you have slow HDD.

I though it was physical cores x2 +1. So for you, it would have been -j13. So, I'm guessing you're just skipping the +1.

Has anyone used this:

github.com/InBetweenNames/gentooLTO

I tried it and it worked fine except I couldn't compile elfutils on hardened Gentoo. Everything else compiled fine, although I can't say that the speed increase was that noticeable.

>I though it was physical cores x2 +1
Nope. It's physical + 1.
In any case, what use would be setting it more than the number of logical cores?

MAKEOPTS="-j -l"
EMERGE_DEFAULT_OPTS="--jobs=2 --load-average="

No point launching too many emerge jobs at the same time as they just bottleneck on I/O (or just end up wainting on locks), but we should get another emerge job running when the first can't saturate the CPU. The -l on MAKEOPTS makes sure that even if there are multiple emerge jobs running they combined can only use at most number of threads for compiling, i.e with settings like you could end up with (cpus+1)*(cpus+1) number of threads running at the same time

I probably didn't phrase it correctly.

If I have 2 dual-core CPUs (hyper-threading enabled), wouldn't I use -j4 (or -j5 based on the Gentoo Handbook)?

--load-average=

Shouldn't the load average be equal to the number of threads?

My thinking with that is you want it to be smaller than the --load-average of MAKEOPTS so it'll favour launching new compilation jobs over launching new emerge jobs

>I though it was physical cores x2 +1
Nope. It's physical + 1.
In any case, what use would be setting it more than the number of logical cores?

>compilation times is literally the only thing wrong with Gentoo. How does one improve that?
Number one tip is compile less: Don't use multilib, use ccache (needs to be configured correctly), do some per package USE flag management to limit shit they pull. /var/tmp/portage tmpfs helps, so does gettign faster machine and/or multiple machines and setting up distcc.

some handy aliases
alias e="sudo emerge -av"
alias eu="sudo emerge -av --unmerge"
alias es="sudo emerge -av --sync"
alias ee="sudo emerge -avuDN @world"
alias ec="sudo emerge --depclean && sudo eclean-dist -d"
alias sc="sudo rc-service"

>How does one improve that?
Just don't use bloated programs. Avoid using any DE, avoid anything that requires boost (avoid anything written in C++ if yout can). Also having a decent CPU and an SSD also helps.

That's stupid advice. Just use whatever program is needed, it's only the first installation that matters anyway as after that all updates are done in the background with no downtime to shitposting/anime

>I don't care about what Portage tells me.
HAHAHAHA.

LMAO.

Attached: 177066733-image.png (400x400, 299K)

>EMERGE_DEFAULT_OPTS="--jobs= --load-average="
It is enabled by default, dude.

Use --changed-use (short option -U) instead of --newuse (-N), there's no need to re-compile a package just because a new USE flag gets added that you're not using.

hey retards, anyone knows how to build fast gentoo on musl libs and is it possible to install gentoo use stage4?

Attached: 15310441969850.jpg (625x625, 85K)

when has that ever happened and the version wasn't bumped at the same time?

Why do I see everyone peddling the same jobs = no. of CPU >>logical

gentoo wiki recommended use default shit settings.
try this CFLAGS="-Ofast -mmmx -mssse3 -pipe -flto=8 -funroll-loops" and speed up your PC

>wiki.gentoo.org/wiki/FAQ
>Things are really unstable when using '-O9 -ffast-math -fomit-frame-pointer' optimizations. What gives?
>Do not bother using anything higher than -O3 since it is not supported by current versions of GCC. Very aggressive optimizations sometimes cause the compiler to streamline the assembly code to the point where it does not quite do the same thing anymore.
>
>Please try to compile using -O2 -march= with CFLAGS/CXXFLAGS before reporting a bug.
Hmmmm.

notice the -av flag there ?

I have, and I'm even on hardened as well, though I had to make a couple of packages non-LTO to get them to compile. Not elfutils though.
Just make sure to recompile everything and be on the latest GCC and glibc (8.1.0 and 2.27)

I just use $RAM_in_gigs / 2 makejobs (fucking C++) and the amount of threads as the load average.
>indiscriminate --unmerge use
Use --depclean $package if you know what's good for you, --unmerge if you know exactly what you're doing and why --depclean doesn't work.
>nomultilib
Until you suddenly find out you do want something that's 32-bit and that nomultilib > multilib is not easy :^)
Besides, the only overhead multilib adds unless you specifically ask for 32-bit libs is on the toolchain to support it.
>ccache
And make sure to not have -march=native if you do that.
>tmpfs build dir
Snake oil. -pipe is all you need and you'll definitely have to disable that via package.env for larger packages anyway.

>Until you suddenly find out you do want something that's 32-bit
That's really just steam and some wine games, I use a multilib chroot for those
>make sure to not have -march=native if you do that.
ccache doesn't care. You must be confusing it with distcc that does.
>Snake oil. -pipe is all you need
a highly scientific test for you:
time emerge ffmpeg #tmpfs
696.96s user 52.18s system 773% cpu 1:36.91 total
time emerge ffmpeg #on disk
696.16s user 52.44s system 704% cpu 1:46.20 total
time emerge ffmpeg #tmpfs
697.72s user 52.09s system 750% cpu 1:39.90 total
time emerge ffmpeg #on disk
674.83s user 51.70s system 651% cpu 1:51.50 total

so around 10% faster
>you'll definitely have to disable that via package.env for larger packages anyway.
get more ram lol

>just steam and wine
And some proprietary 3rd-party shit I happen to run. Besides, the extra shit for the toolchain won't make much of a difference.
>ccache doesn't care. You must be confusing it with distcc that does.
Whoops, yeah, my bad.
>test
And was that compile job basically the only thing running, did you disable ccache and distcc etc.?
All things aside, I'd rather take the speed hit than hit swap hell, the OOM killer killing my processes and/or random transient errors tmpfs seems to cause. I wouldn't recommend tmpfs as a general upgrade when -pipe essentially does the same thing and won't eat up your RAM like crazy and also keep the occasional failed build job in memory ("Hey, why am I so low on RAM?")
>get more ram lol
Try compiling chromium on tmpfs.

>Try compiling chromium on tmpfs.
I can compile chromium with only 8GiB TMPFS on Crux without any problems.

>-Ofast
>-funroll-loops
Good luck trying to compile sqlite with this flags.

>2018
>wasting time compiling gentoo
>not getting the performance of Clear Linux

ISHYGDDT

install Ubuntu

it build and installed without an hitch, now what?

Attached: 1515021052820.png (633x900, 114K)

Who in their right mind uses Gentoo?

>clear linux
Why did Intel pick this name anyway? That's just asking to get their distro confused with Clear OS.

phoronix.com/scan.php?page=article&item=windows-freebsd112-8linux&num=1

>running software that will throttle itself on non-Intel CPUs

Attached: 1528343335385.jpg (626x657, 75K)

Sometimes the ebuild gets updated but not the package