emerge долгая сборка

хотя процессор не загружен на 100%

На все 100% он бывает загружен далеко не всегда.

если бы он загружал проц на полную катушку, то и компиляция шла бы на порядок быстрее

Попробуй выставить большее число потоков.

На i3 процессора с 4гб оперативы,wine компилится порядка 20 минут

По-моему, для i3 это нормальная цифра.

Попробуй поместить /var/tmp/portage в tmpfs. ( http://ru.gentoo-wiki.com/wiki/Ускорение_portage_через_tmpfs ) Поставь MAKEOPTS="-j4" (в make.conf, попробуй -j5 ) Установи ccache ( http://www.gentoo.org/doc/ru/handbook/hb-working-features.xml ), только при смене компилятора кеш нужно очищать.

На i3 процессора с 4гб оперативы,wine компилится порядка 20 минут ,

Не измерял точно, но на corei5 430m, (без ccache, /var/tmp/portage - tmpfs) где-то 15 минут.

time emerge wine -vB1
[ebuild   R    ] app-emulation/wine-1.5.3  USE="X alsa gecko jpeg mp3 nls opengl png threads truetype win32 -capi -cups -custom-cflags -fontconfig -gnutls -gphoto2 -gsm (-gstreamer) -hardened -lcms -ldap -ncurses -odbc -openal -opencl -oss -perl -samba -scanner (-selinux) -ssl -test -udisks -v4l -win64 -xcomposite -xinerama -xml" 0 kB
....
real	11m2.388s
user	30m34.992s
sys	2m53.109s

В фоне играл mocp, использовал оперу. gcc 4.6.3

# genlop -t wine

 * app-emulation/wine

     Wed Apr  4 12:32:57 2012 >>> app-emulation/wine-1.4
       merge time: 11 minutes and 54 seconds.

     Wed Apr  4 14:47:41 2012 >>> app-emulation/wine-1.4
       merge time: 13 minutes and 11 seconds.

     Wed Apr  4 15:00:16 2012 >>> app-emulation/wine-1.4
       merge time: 4 minutes and 19 seconds.

     Wed Apr  4 15:36:34 2012 >>> app-emulation/wine-1.4
       merge time: 4 minutes and 36 seconds.

     Wed Apr  4 16:26:15 2012 >>> app-emulation/wine-1.4
       merge time: 7 minutes and 21 seconds.

Core i3, сборка при помощи gcc-4.6.2 в пять потоков с ccache.

Процессор - не единственное узкое место. Всё может упираться в скорость работы жёсткого диска. Ну и собирать нужно в несколько потоков, чтобы побольше процессор загрузить.

спасибо , помогло , теперь в разы быстрее

Не за что. Но что именно помогло? Попробуй обновить компилятор, в 4.6.* есть оптимизация под core i3/5/7, в make.conf

CFLAGS="-march=corei7 -mtune=corei7 -O2 -pipe -mmmx -msse4.2 -ftracer -mfpmath=sse,387"
#CFLAGS="-march=corei7-avx -mtune=corei7-avx -O2 -pipe -mmmx -msse4.2 -ftracer -mfpmath=sse,387" - если проц sandy bridge

у меня 2 потока было всего , + врубил ccache

-mfpmath=sse,387

invoke megabaks

-march=corei7 -mtune=corei7

оверхед
первого хватит
-mmmx при -msse4.2 тоже не нать

ок, скастовал я мимо. mfpmath=sse,387 советовать нубу плохая затея; тк результат её непредсказуем и пилят её полтора анонимуса; сам для начала погрепай мэйллисты gcc насчёт этой штуки

-mmmx -msse4.2

Это точно нужно для Sandy bridge? Там же вроде AVX который есть замена SSE инструкциям и все плюшки SSE реализованы в AVX, но по другому? Извиняюсь если не так. sudo cast megabaks

ксатит, да

при -mavx по-дефолту включается -msse2avx

Specify that the assembler should encode SSE instructions with VEX
           prefix.  The option -mavx turns this on by default.

Хорошая идея, но для крупных проектов типа офиса - смерть. Я тут собирал pypy...
Хорошо додумался заранее вырубить tmpfs. Сутки собирал...

Хорошая идея, но для крупных проектов типа офиса - смерть.

Тогда можно использовать distrc (не знаю работает ли с ним ccache) и компилить только на одном компьютере с опцией ( emerge -b pack) (можно EMERGE_DEFAULT_OPTS="-b" в make.conf), и расшарить директорию по nfs., а на других использовать параметр (emerge -k pack), тогда просто скачается готовый бинарный архив.

А если память не будет хватать? Оно упадет или просто вытеснит часть в своп?

некоторые портажи из главного репозитория собираются только в 1 поток. не помню что конкретно но что-то из лагеря qt

Если занимает больше чем есть в tmpfs, то упадет сборка. В противном случае полезет в своп.

То есть если выделить tmpfs 100 ГиБ при ОЗУ в 4, то он просто будет лезть в своп при превышении, что равносильно нахождению портежа на диске?

У меня /var/tmp/portage 9 гб, если что-то очень большое компилится то влазит в своп.

что равносильно нахождению портежа на диске?

Не знаю, по скорости не измерял, то по моему (могу ошибатся), часть размещена в tmpfs, часть в swap, поэтому скорость будет все-таки немного больше.

Ну и чудненько, спасибо.