Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers PC de bureau
Agrandir
PC de bureau
Micro-ordinateurs
PC de bureau
Produits 79 79
Actu 21 21
Articles 2 2
Médias 750 750
Tutoriels Tutos 2 2
Avis 52 52
Petites annonces Annonces 2 2
Forums 430 430

Un PC de qualité professionnelle pour la MAO... mais sans se ruiner

  • 411 réponses
  • 28 participants
  • 41 840 vues
  • 33 followers
Sujet de la discussion Un PC de qualité professionnelle pour la MAO... mais sans se ruiner
Bonjour à tous,

Voilà, je me lance, j’ai décidé de créer mon premier thread en réaction à deux autres publiés sur AF :

Le premier : celui de notre Los Teignos national, bien qu’il commence à dater (le thread, hein...) concernant un sondage sur nos machines de MAO [lien]

Et le second, en réaction au test de Nantho du TH3 d’Overloud, et plus particulièrement à la discussion qui a suivi le post d’un AFien :

Citation :
Citation :
Niveau consommation en ressources, une instance oscille entre 0,30 et 0,50 % sur ma machine (Mac Pro fin 2013 Hexacœur Xeon 3,5 GHz - 32 Go DDR3), cette variation dépendant de la complexité du patch utilisé. TH3 est donc relativement peu gourmand.


heu... pardon monsieur, mais moi j'ai pas ce genre de machine chez moi (sûrement comme une large majorité d'utilisateurs ici d'ailleurs).
Vous pourriez tester sur des configs plus raisonnables à l'avenir ? :)
C'est sûr qu'avec une telle config matérielle, il y a bien peu de logiciels qui doivent être à la traine ^^'


Pour faire vite, mis à part la musique, mon autre violon d'Ingres est la création d'images de synthèse, ce qui demande pas mal de ressources en termes de (1) CPU, (2) RAM et (3) carte graphique.

Or pour la MAO, on est peu ou prou dans ce cas de figure, excepté pour les graphismes, puisqu’on ne travaille qu’en 2D.

M’ayant construit une station de travail calquant les spécifications de ce qui se vend sur le marché professionnel - mais à moindre coût - je souhaite ici partager mon expérience avec ceux qui souhaiteraient avoir la puissance d’un croiseur pour leurs 10 millions de plug-ins, sans pour autant se ruiner et pouvoir s’en servir pourquoi pas pour autre chose.
Afficher le sujet de la discussion
101
Citation :
Encore un thread intéressant, merci dr Bad :bravo:


Merci !
102
Juste un addendum à ce que j’ai déjà dit : ne pas confondre « multiprocesseurs » et « multicœur ».

Notamment concernant la saturation du cœur « 0 » due à certains plugins (vérité vraie, sans contestation).

En cas de biprocesseur, on a à disposition deux cœurs « 0 » : celui du CPU 0 et celui du CPU 1 (désolé, on compte à partir de 0, pas à partir de 1).
Là où ça devient intéressant, vu que chaque processeur dispose d’un accès mémoire propre, c’est que chacun se comporte un peu comme un ordi à part entière (gros raccourci j’en conviens).

Du coup, au final, sans renter dans les détails, en plus de l’équilibrage sur tous les cœurs disponibles par la DAW et les plugin (s’ils ont été codés en ce sens) on a, pour les plugins qui ne sont capables de se focaliser que sur un seul cœur (le premier : cœur « 0 »), deux fois plus de « place » pour les faire fonctionner : le cœur « 0 » du CPU « 0 » et le cœur « 0 » du CPU "1".

[ Dernière édition du message le 12/07/2017 à 17:32:58 ]

103
Pourquoi un plugin mono-threadé ne pourrai pas être exécuté sur n'importe quel cœur ? C'est l'OS qui gère ce genre de chose, si l'OS sait le faire ya pas de raison.
Quels plug-in sont multi-threadé ?
De ce que j'ai vu beaucoup de plugin sont mono-threadé, c'est a dire que le plug-in en soit ne sait utiliser qu'un seul thread. La parallélisation ce fait en exécutant les différents plug-in sur différents cœurs.
104
Exactement !

Ce qui fait que la multiplication des cœurs (et donc threads) engendre une augmentation des possibilités en termes de plugin.

Reste que certains plugins (de par leur codage) ne voient que le premier cœur et rien d’autre, donc ils brident cette possibilité.
Mais comme tu dis, l’OS peut s’en charger : on peut les forcer à s’exécuter sur le premier cœur (cœur 0), mais du second CPU (CPU 1).

Vu comme ça, on pourrait croire que c’est de la tambouille ultra-technique d’informaticien, mais ce n’est pas plus compliqué que d’affilier une piste à un bus : ça se fait en cochant/décochant les « affinités ».
105
Citation de DrMAB :
Ce qui fait que la multiplication des cœurs (et donc threads) engendre une augmentation des possibilités en termes de plugin.

Pas tout a fait, il faut aussi que les tâches soient indépendantes.
Si on prend l'exemple de plusieurs plug-in insérés sur une même piste, ils doivent s'exécuter dans l'ordre dans lequel ils sont insérés. Ce qui veut dire que même si le séquenceur crée un thread pour chaque plug-in et que chaque thread est lancé sur un cœur différents, l’exécution sera séquentielle.
C'est à dire que les cœurs s'attendrons les uns les autres pour faire leurs travail, et ça c'est pas bon du tout.
En fin de compte on a les même performances qu'avec un seul cœur... A vrai dire des moins bonnes performances, car gérer plusieurs thread c'est pas gratuit.
Il se passe le même genre de chose pour les plug-in inséré sur une piste auxiliaire qui reçois son signal en post-fader (ou une piste groupe, master), les plug-in doivent attendre que la piste qui envois son signal ait fini ses traitements.

En fin de compte il y a bien un gain à avoir plusieurs cœurs, plusieurs processeurs, par contre deux fois plus de cœurs ne veut pas dire deux fois plus de plug-in possible, loin de la.

Citation de DrMAB :
Reste que certains plugins (de par leur codage) ne voient que le premier cœur et rien d’autre, donc ils brident cette possibilité.
Mais comme tu dis, l’OS peut s’en charger : on peut les forcer à s’exécuter sur le premier cœur (cœur 0), mais du second CPU (CPU 1).

En général les codes qui font ce genre de chose (imposer les cœurs ou ils sont exécuté) sont justement des codes parallélisé qui veulent imposer une certaine partie du code à n'être exécuté que sur un cœur particulier.
A coté de ça les codes qui n'ont pas été pensé pour utiliser plusieurs cœurs peuvent au contraire être exécuté sur n'importe quel cœurs, le 0, le 1 ou le 73.

[ Dernière édition du message le 12/07/2017 à 20:04:16 ]

106
Citation :
A coté de ça les codes qui n'ont pas été pensé pour utiliser plusieurs cœurs peuvent au contraire être exécuté sur n'importe quel cœurs, le 0, le 1 ou le 73.


J'ai bien compris que t'exagères le propos en parlant de 73 :-D , j'ai lu chez soundonsound que pour les testes avec xeon les gars étaient limité à 32 threads, apparemment c'est le maxi que leur daw permet.


Sinon quelqu'un ici peut expliquer pourquoi en chargeant ma daw à fond sur une piste la jauge de la daw explose alors que je vois que la répartition du taf se fait sur plusieurs cœur et que je suis seulement à 20% cpu max pour chacun.
Pourtant je peux utiliser 50 fois plus de plugin en utilisant plusieurs pistes, être à 80% de la jauge de la daw et cpu en temps normal.
C'est comme cela que réagit ableton chez moi, comme si je suis limité pour une piste, à côté j'ai un éditeur audio qui apparemment ne fait pas ça.



[ Dernière édition du message le 12/07/2017 à 21:46:25 ]

107
C'est tout a fait normal, c'est ce que je voulais dire juste en haut.
Les plug-in de ta piste doivent être exécuté dans l'ordre. Mettons qu'ils y a trois plug-in chacun est lancé sur un cœur : le plug-in 1 sur le cœur 1, le plug-in 2 sur le cœur 2, etc. On peu schématiser leur fonctionnement dans le temps comme ca :
Temps -->
cœur 1 : execute plug-in 1 --> attend --> attend
cœur 2 : attend --> execute plug-in 2 --> attend
cœur 3 : attend --> attend --> execute plug-in 3

En gros il n'y a pas de vrai parallélisme car les plug-in ne peuvent pas être exécuté simultanément.
Du coup le gestionnaire des tâches montre que les cœurs sont qu'a 20%, c'est parce que ils attendent pendant la plus grande partie du temps. De l'autre coté la jauge du DAW monte au maximum car le proc ne peut effectivement rien exécuter de plus.

Quand tu as plusieurs pistes, les cœurs peuvent exécuter les plug-in des différentes piste simultanément et la on a du vrai parallélisme.
Temps -->
cœur 1 : execute plug-in 1 piste 1 --> execute plug-in 2 piste 1 --> execute plug-in 3 piste 1
cœur 2 : execute plug-in 1 piste 2 --> execute plug-in 2 piste 2 --> execute plug-in 3 piste 2
cœur 3 : execute plug-in 1 piste 1 --> execute plug-in 2 piste 3 --> execute plug-in 3 piste 3

Il faut bien voir que cette méthode de parallélisation, crée un thread par plug-in, c'est du bricolage :
-Les threads ne sont pas forcement indépendants.
-On crée trop de threads. En effet pour être optimal, la plus par du temps, il faut créer autant de thread qu'il y a de cœur. Créer 30 threads, parce que 30 plug-in, alors qu'il y a 2, 4 ou 8 cœurs c'est contre productif.
En ceci les DAW utilisent plusieurs cœurs, mais ne sont pas optimiser à l'utilisation de plusieurs cœurs.
108
Donc ce que j'observe c'est ce que t'as expliqué.
Ok, ok merci :bravo:
Qui fais que je peux avoir un projet plus gourmand avec moins de plugins qu'un projet moins gourmand avec plus de plugins, et ceci en fonction de comment tout cela est organisé.
J'ai aussi l'impression qu'il y a des jauges qui montent plus vite dans certaine daw que d'autre en situation de test sans être vraiment en situation d'utilisation réel, ce qui donne en premier lieu l'impression qu'une daw consomme plus que l'autre alors qu'en fait sur l’ensemble d'un projet comparable, assez complexe et poussé le résultat en consommation peut être très similaire, je veux dire que constater qu'une jauge d'une daw pour un même plugin va par exemple mesurer 0.4% dans une daw et 2 % dans une autre n'a pas tellement de signification sur l'enssemble des perfs de la daw, non?
109
@Danbei

Exacte cette question de latence due à l'ordre d’exécution des plugins.
En fait, suivant que l'on considère le projet dans sa globalité ou une piste en particulier, les notions de performances sont différentes.

Ma phrase :
Citation :
Ce qui fait que la multiplication des cœurs (et donc threads) engendre une augmentation des possibilités en termes de plugin.

était un peu ambiguë, donc je reformule:

Ce qui fait que la multiplication des cœurs (et donc threads) engendre une augmentation des possibilités en termes de pistes chargées en plugins et donc ouvre le champ des possibles à des projets très lourds.





[ Dernière édition du message le 13/07/2017 à 11:07:10 ]

110
Citation :
En fait, suivant que l'on considère le projet dans sa globalité ou une piste en particulier, les notions de performances sont différentes.


Je pense que c'est là où le bât blesse et que finalement chacun dit des choses vraies mais qui, faute de contexte semblables, semblent s'opposer.