[Libreoffice] Temps de compil libreoffice 4.4

[SwordArMor]

Je suis aussi de cette école. Ma machine la plus ancienne a quinze ans et elle commence tout juste à montrer quelques signes de fatigue.

[DuF]

moi je n'ai pas eu le choix, mon alimentation avait grillé (ça fait toujours bizarre une fumée qui s'échappe avec une odeur de plastique fondue) et avait en même temps grillé des composants de la carte mère. Du coup j'avais pris une configuration adaptée à mon usage (puissante brute mais carte vidéo de base).

Mais pareil les composants ont 3 ans et je ne pense pas changer dans les années à venir (si possible minimum une décennie ) et j'espère que libreoffice n'augmentera pas ses besoins

[xaviermiller]

Il y a des alternatives à libreoffice telles abiword et gnumeric, mais pour du "powerpoint", je ne vois pas trop. Et libreoffice est moins médiocre comparé aux sus-nommés concernant la compatibilité avec MS Office.

[Leander256]

Il faut dire que la puissance de calcul nécessaire pour la plupart des tâches courantes est largement suffisante depuis quelques années. Et quand une tâche prenait du temps, c'était assez souvent à cause du disque dur, je pense que tous les gens qui ont fait l'expérience d'une transition HDD -> SSD sur une même machine comprendront très bien de quoi je veux parler!

D'ailleurs pour en revenir au sujet quelqu'un l'a déjà mentionné mais maintenant ça me paraît évident, si le temps de compilation de libreoffice fait un bond très brusque, c'est très probablement lié à l'utilisation de la swap. Et là encore on peut mettre en cause GCC qui peut prendre des tonnes de mémoire pour compiler certains bouts de C++. Je n'ai rien contre GCC, soit dit en passant!

Il y a des alternatives à libreoffice telles abiword et gnumeric, mais pour du "powerpoint", je ne vois pas trop. Et libreoffice est moins médiocre comparé aux sus-nommés concernant la compatibilité avec MS Office.

Peut-être Calligra? Je n'ai pas vraiment eu l'occasion de m'en servir jusqu'à présent, mais cette suite me semble intéressante. Bon par contre c'est du KDE, ce n'est pas forcément plus léger à compiler

[341438]

@DuF: le temps de compilation a diminué lorsque tu as augmenté la ram. Tu es passé
à combien de ram ?

[sebB]

Effectivement je suis en train de me tater pour repasser sous calligra (qui de mémoire gère les powerpoint).


Je pense aussi que libreoffice est devenu gourmand en mémoire mais ca n'explique pas mon écart de compil (moi je me suis pris 6h en plus d'un coup).
Surtout quand je vois que kopp avec son Core 2 et ses 2G de ram compile plus vite.
Et cette différence je ne l'ai que sur libreoffice.

[kopp]

@DuF: le temps de compilation a diminué lorsque tu as augmenté la ram. Tu es passé
à combien de ram ?

Il est passé à 32, c'est écrit ... de 16 je suppose.

SInon la question c'est surtout : tu compiles en tmpfs Duf ?

Sinon, pour rappel :

Code: Select all

     Tue Dec  5 21:26:28 2006 >>> app-office/openoffice-2.0.4
       merge time: 2 hours, 21 minutes and 58 seconds.

sur la même machine...

En même temps à l'époque Firefox (2 !) prenait entre 8 et 30 minutes... sans tmpfs. Maintenant il lui faut 2h en tmps, mais je suppose que ça swap pas mal sur ma machine ...

[341438]

Il est passé à 32, c'est écrit ... de 16 je suppose.

Je suis un malin, je n'ai pas eu la curiosité de regarder ce qu'il y avait dans la deuxième partie du code.

Merci pour l'info!

[DuF]

@DuF: le temps de compilation a diminué lorsque tu as augmenté la ram. Tu es passé
à combien de ram ?

Il est passé à 32, c'est écrit ... de 16 je suppose.

SInon la question c'est surtout : tu compiles en tmpfs Duf ?
(...)

En fait je suis passé de 4 à 32 et je fais pointer PORTAGE_TMPDIR vers /tmp qui est un tmpfs.

Pour firefox sinon, depuis le début de l'année ça s'est drôlement amélioré chez moi :

Thu Jan 15 20:03:21 2015 >>> www-client/firefox-35.0
merge time: 26 minutes and 31 seconds.

Fri Feb 27 23:27:43 2015 >>> www-client/firefox-36.0
merge time: 18 minutes and 5 seconds.

Sun Mar 15 17:43:01 2015 >>> www-client/firefox-36.0.1
merge time: 17 minutes and 20 seconds.

Mon Mar 30 13:29:58 2015 >>> www-client/firefox-36.0.4
merge time: 12 minutes and 46 seconds.

Wed Apr 8 22:28:37 2015 >>> www-client/firefox-37.0.1
merge time: 12 minutes and 45 seconds.

Fri May 1 11:25:11 2015 >>> www-client/firefox-37.0.2
merge time: 13 minutes and 51 seconds.

[xaviermiller]

La dernière mouture a pris 18h sur mon atom, contre 6-7 heures il y a quelques mois... via distcc à chaque fois

[sebB]

Code: Select all

Sun Feb 15 20:56:34 2015 >>> app-office/libreoffice-4.3.5.2
       merge time: 3 hours, 10 minutes and 44 seconds.

Sun Apr 19 18:47:34 2015 >>> app-office/libreoffice-4.4.1.2
       merge time: 8 hours, 41 minutes and 59 seconds.

Wen May 27 20:11:56 2015 >>> app-office/libreoffice-4.4.3.2
       merge time: 5 hours, 52 minutes and 38 seconds.

Bon ca s'améliore avec les versions.
Je retombe un peu dans la moyenne à la vue de vos stats.
A croire que la version 4.4.1.2 avait un soucis chez moi.

[SwordArMor]

Tu n’es pas le seul à avoir une temps de compilation plus long pour la 4.4.1.2 :

Code: Select all

     Tue Apr  7 13:56:27 2015 >>> app-office/libreoffice-4.3.5.2
       merge time: 1 hour, 35 minutes and 23 seconds.

     Mon Apr 13 15:52:35 2015 >>> app-office/libreoffice-4.4.1.2
       merge time: 2 hours, 4 minutes and 9 seconds.

[augustin]

Code: Select all

 
Victoria config # genlop -t libreoffice 
 * app-office/libreoffice
                                                                                                                                                                            
     Wed Mar  4 22:38:50 2015 >>> app-office/libreoffice-4.3.5.2                                                                                                            
       merge time: 2 hours, 10 minutes and 43 seconds.                                                                                                                      

     Thu Mar  5 04:34:54 2015 >>> app-office/libreoffice-4.3.5.2
       merge time: 3 hours, 22 minutes and 47 seconds.                                                                                                                      

     Fri Apr 17 19:23:28 2015 >>> app-office/libreoffice-4.4.1.2
       merge time: 2 hours, 23 minutes and 33 seconds.                                                                                                                      

     Thu May 28 10:38:32 2015 >>> app-office/libreoffice-4.4.3.2
       merge time: 2 hours, 56 minutes and 5 seconds.                                                                                                                       

AMD Phenom(tm) II X4 955 Processor

[DuF]

Code: Select all

     Wed Apr  8 23:38:19 2015 >>> app-office/libreoffice-4.3.5.2
       merge time: 1 hour, 9 minutes and 42 seconds.

     Sat Apr 18 16:28:25 2015 >>> app-office/libreoffice-4.4.1.2
       merge time: 1 hour, 22 minutes and 34 seconds.

     Sat May 30 16:58:33 2015 >>> app-office/libreoffice-4.4.3.2
       merge time: 1 hour, 26 minutes and 33 seconds.

On ne compile pas tous la même chose ni avec les mêmes éléments (gcc-4.8.4 chez moi)

[sebB]

Y'a t'il un moyen de gérer les accés disque lors de la compil de libreoffice?
Mon load average grimpe à 12/13 alors que dans mon make.conf je l'ai limité à 8.
On peut voir que ce n'est pas la charge de mes cpu qui coince.
Mon disque est en activité constante et mon ordi inutilisable pendant 8h car il rame.
Y'a-t-il mieux que ext4 pour compiler si le probleme vient de là?
Certe je peux lancer les compil la nuit mais j'aimerais bien comprendre.

Stats compil libreoffice.
top

Code: Select all

1 user,  load average: 7,93, 8,83, 8,81
Tasks: 237 total,   2 running, 235 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,1 us,  3,0 sy, 60,1 ni,  8,1 id, 28,6 wa,  0,0 hi,  0,1 si,  0,0 st
KiB Mem:   3967952 total,  3878408 used,    89544 free,      496 buffers
KiB Swap:  8388604 total,  1629216 used,  6759388 free.    24144 cached Mem

iostat

Code: Select all

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,13    0,75    0,25   22,43    0,00   76,44

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda              19,00     0,00  146,00    2,00  2608,00   888,00    47,24    21,16  969,47  890,53 6732,00   6,76 100,00
dm-0              0,00     0,00   42,00    0,00  2220,00     0,00   105,71     9,15 1565,69 1565,69    0,00  23,81 100,00
dm-1              0,00     0,00  122,00    0,00   488,00     0,00     8,00    76,33 12846,57  596,30    0,00   8,20 100,00
dm-2              0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00
dm-3              0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00
dm-4              0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00

iostat -x 1

Code: Select all

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2,01   38,98    2,95   14,05    0,00   42,00

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              33,81       315,53       695,21   22248798   49020176
dm-0              6,71       126,08         8,05    8890125     567352
dm-1            177,07       134,22       574,06    9463756   40477876
dm-2             13,89        46,00        74,63    3243573    5262580
dm-3              0,90         8,78        12,77     618901     900328
dm-4              5,66         0,41        25,70      29257    1811868

make.conf

Code: Select all

CHOST="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=native -pipe"
CXXFLAGS="${CFLAGS}"

MAKEOPTS="-j9 -l8"

ACCEPT_KEYWORDS="amd64"

ACCEPT_LICENSE="*"

EMERGE_DEFAULT_OPTS="--jobs=4 --load-average=4.0 --keep-going --with-bdeps=y"
PORTAGE_ELOG_CLASSES="log warn error info"
PORTAGE_ELOG_SYSTEM="echo:log,warn save:log,warn,error,info syslog:error"

PORTAGE_NICENESS=19
PORTAGE_IONICE_COMMAND="ionice -c 3 -p \${PID}"

[El_Goretto]

Y'a t'il un moyen de gérer les accés disque lors de la compil de libreoffice?
Mon load average grimpe à 12/13 alors que dans mon make.conf je l'ai limité à 8.

[...]

Code: Select all

CHOST="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=native -pipe"
CXXFLAGS="${CFLAGS}"

MAKEOPTS="-j9 -l8"

ACCEPT_KEYWORDS="amd64"

ACCEPT_LICENSE="*"

EMERGE_DEFAULT_OPTS="--jobs=4 --load-average=4.0 --keep-going --with-bdeps=y"
PORTAGE_ELOG_CLASSES="log warn error info"
PORTAGE_ELOG_SYSTEM="echo:log,warn save:log,warn,error,info syslog:error"

PORTAGE_NICENESS=19
PORTAGE_IONICE_COMMAND="ionice -c 3 -p \${PID}"

Tel que je vois les choses, tu as un poil trop trituré ta configuration portage (classique et chronique pour un utilisateur gentoo) et tu as fini par faire du "ricing"
4 fois 9 threads n'est peut être pas ce que tu attendais, mais c'est ce que tu as configuré.

man emerge:

-j [JOBS], --jobs[=JOBS]
Specifies the number of packages to build simultaneously.

Donc 4 packages en parallèle, avec chacun 9 threads... Ca pourrait peut être venir de là. Le disque n'est pas le tueur, mais une victime

J'aime bien ton idée de jouer avec une limite de load, mais si jamais tu as une machine qui n'est pas un desktop et a une charge CPU non nulle en dehors de l'activité de portage, tu risques d'avoir des temps de compilation/emerge assez lamentables.
Ce que j'essaierais: si tu souhaites rester à jouer avec le load limit, ne garde que la config MAKEOPTS qui s'applique à chaque package. Et si tu as une machine ayant des traitements CPU constants (un serveur par exemple), garde uniquement le PORTAGE_NICENESS en retirant les load-limit (si tu considères qu'une MAJ doit être traitée en un temps raisonnable). Mais bon, c'est peut être un poil moins fun, je te l'accorde, libre à toi de rechercher une combinaison plus amusante.

[sebB]

Effectivement j'ai fais pas mal de test, et certains trucs ont été ajoutés car c'était la mode....
Je ne savais pas que que les threads se multipliaient avec les packages.

Je pensais:

MAKEOPTS, dans mon cas maxi 9 threads et limite load à 8
EMERGE_DEFAULT_OPTS, on dit au package suivant de démarer si 1 threads est libre et que le load est inférieur à 4.

D'ou paquet A utilise 6 threads et load < 4 donc paquet B demarre avec les 3 threads qui sont dispo.

Je viens de faire un tas de tests notamment avec gcc 4.9.3 et aucune issue avec libreoffice.
firefox + thunderbird sont passés sans probleme (aucun freeze).
J'ai juste laissé dans mon make.conf, MAKEOPTS=j(n)

Je viens de me rendre compte qu'un autre paquet à les mêmes "symptomes", sigil.
Avec un j>4 mon systeme ne répond plus et le load grimpe à 15 même si je tente de le limiter (d'ailleurs ca semble pas marcher ce -jn -ln). Celui là en plus est compilé en tmpfs.
Si je stoppe la compil, la diode de mon dd reste allumée et mon systeme est inutilisable (rien dans top) même après un rm du tmp. Ca revient à la normale au but de 5 minutes.

Code: Select all

Mon Nov 17 23:20:42 2014 >>> app-text/sigil-0.6.2 
       merge time: 7 minutes and 28 seconds.

Tue Dec 30 09:51:14 2014 >>> app-text/sigil-0.6.2
       merge time: 6 minutes and 53 seconds.

Mon Jul 20 00:58:19 2015 >>> app-text/sigil-0.6.2
       merge time: 33 minutes and 1 second.

top

Code: Select all

1 user,  load average: 14,67, 11,14, 8,07
Tasks: 234 total,  10 running, 224 sleeping,   0 stopped,   0 zombie
%Cpu(s): 98,8 us,  1,2 sy,  0,0 ni,  0,0 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem:   3967952 total,  3518376 used,   449576 free,   143488 buffers
KiB Swap:  8388604 total,     2664 used,  8385940 free.  1249752 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND     
10809 portage   20   0  412556 384896  17040 R  95,9  9,7   3:16.67 cc1plus     
11704 portage   20   0  111352  84740  17308 R  93,2  2,1   0:06.23 cc1plus     
11680 portage   20   0  127032 101408  17308 R  86,9  2,6   0:10.82 cc1plus     
11712 portage   20   0  111600  85304  17388 R  86,6  2,1   0:05.65 cc1plus     
11696 portage   20   0  111624  87020  17264 R  82,6  2,2   0:06.60 cc1plus     
11708 portage   20   0  113972  88940  17308 R  82,3  2,2   0:05.72 cc1plus     
11664 portage   20   0  138428 114044  17380 R  79,9  2,9   0:12.91 cc1plus     
11721 portage   20   0   96960  67676  14072 R  75,0  1,7   0:02.26 cc1plus     
11725 portage   20   0   85776  54336  12160 R  45,8  1,4   0:01.38 cc1plus    

Je suis en train de réinstaller gcc 4.7 pour voir. Après je seche.
Au pire je regarderais si y'a pas moyen de passer un -jn a certains paquets dans le package.env

EDIT: gcc 4.7 ne résoud rien. J'ai donc créé un fichier j4.conf en attendant mieux.

[El_Goretto]

J'ai juste laissé dans mon make.conf, MAKEOPTS=j(n)

Sage décision, mieux vaut repartir de 0 et rajouter petit à petit d'éventuels tunings.

Je viens de me rendre compte qu'un autre paquet à les mêmes "symptomes", sigil.
Avec un j>4 mon systeme ne répond plus et le load grimpe à 15 même si je tente de le limiter (d'ailleurs ca semble pas marcher ce -jn -ln). Celui là en plus est compilé en tmpfs.
Si je stoppe la compil, la diode de mon dd reste allumée et mon systeme est inutilisable (rien dans top) même après un rm du tmp. Ca revient à la normale au but de 5 minutes.

J'allais dire: cela ressemble fichtrement aus symptômes d'une machine qui swape comme une malheureuse. Et tes différents "screenshots" de top tendent à le prouver. Il va peut être falloir refaire le tour de tes différents montages tmpfs si tu en as, voire redevenir humble du côté de ce que tu demandes à ta machine

Pour rappel, on parle quand même de la compilation d'un paquet obèse de chez obèse, OpenOffice

[sebB]

Après plusieurs test, j'ai des paquets qui ne passe plus avec un j>4 alors qu'avant aucun soucis.
Si pour libreoffice je suis ok, pour sigil je comprends pas.

En même temps je vais rester en j4 car je ne perds que 10 min sur les grosses compil comparé à mon j9.

Par contre es tu sur de ca?

Tel que je vois les choses, tu as un poil trop trituré ta configuration portage (classique et chronique pour un utilisateur gentoo) et tu as fini par faire du "ricing"
4 fois 9 threads n'est peut être pas ce que tu attendais, mais c'est ce que tu as configuré.

Car moi je pensais
MAKEOPTS=-j9, dans mon cas maxi 9 threads
EMERGE_DEFAULT_OPTS=--jobs=4 --load-average=4, on dit au package suivant de démarer si 1 threads est libre et que le load est inférieur à 4.
J'en déduisait que si paquet A utilise 6 threads et load < 4 donc paquet B demarre avec les 3 threads qui sont dispo.

[kopp]

Pour moi, le MAKEOPTS ne concerne qu'un seul paquet à la fois, pas une option globale.
Tu n'auras peut-être pas 4 paquets en même temps à 9 threads, mais c'est possible qu'il y en ait plusieurs quand même.