réactions à la news Commentaires sur le test : Logic implacable

Citation de Hakim+K :

Quand le problème de la surcharge d'un seul cœur lorsqu'on joue une piste live avec un gros IV sera résolu ?
Ex : Je mets un Kontakt avec une grosse librairie sur une piste, je joue et bing j'ai un cœur qui monte au taquet (avec les grésillements et tout qui vont bien) alors que les 23 autres cœurs restent peinards à moins de 1%. P**ain, j'ai acheté un Mac pro "poubelle" 12 cœurs pour ça! Mon ancien Hackintosh faisait beaucoup mieux, forcement je n'avais que 4 cœurs mais chacun allait à 3.5GHz. Sur le mac pro, un cœur va 2.7GHz.

Ce n'est pas forcément anormal Hakim+K

Juste souligner un truc que j’ai déjà partagé à quelques reprises sur AF concernant le nombre de cœurs/threads dans un contexte MAO :

1- Cela concerne tous les DAW/STAN, tous les OS/plateforme (Win/Mac/Linux) et tous les plugins!

2- Oui, certains sont plus ou moins bien optimisés pour exploiter plus d’un cœur/thread, mais...

Dans un DAW/STAN certaines opérations ne peuvent tous simplement pas être calculé en parallèle par plusieurs cœurs/threads. C’est tout simplement impossible techniquement~physiquement à cause de l'implication du/de la notion de temps réel. C’est ce qui explique, dépendamment de la façon dont on travaille, qu’il est parfois plus efficace d’acquérir un CPU avec moins de cœurs, mais avec une plus haute cadence GHz.

Les divers traitements ne peuvent pas toujours s’effectuer en parallèle (tous les cœurs qui travaillent en même temps) dans les DAW. Autrement dit, l’ensemble des calculs que requièrent nos VSTI/VST n’est pas systématiquement dispatché de façon égale entre tous les cœurs de processeur. Parce que certaines chaines d’effets ne peuvent être traitées qu’en série (donc par un seul et unique cœur).

Par exemple, si vous avez dans une piste/tranche plusieurs effets (disons un EQ, suivit d’un comp, suivit d’un enhancer, etc.), le DAW ne peut pas utiliser n cœurs afin de traité simultanément ces 3 effets parce que c’est virtuellement impossible! Parce qu’avant de pouvoir calculer et appliquer le résultat du dernier effet, il doit nécessairement calculer le résultat du premier, du deuxième et du troisième. Du coup, quand un cœur/thread calcule le résultat du premier effet, il est impossible qu’un autre cœur/thread puisse effectuer le calcul de l’effet qui suit (dans une même chaine d’effet/tranche) au même instant t puisqu’il ne connaît pas encore le résultat de l’effet précédent! Pour résumer, toute piste audio ou VSTi qui est lié à une même chaine d’effets (piste/tranche/BUS/AUX) ne peut être traité que par un seul et unique cœur. Et c’est d’ailleurs aussi ce qui explique, même lorsqu’on a seulement une seule piste dans un DAW, que sa gauge d’utilisation CPU puisse parfois indiquer 99% (parce qu’un seul cœur est sollicité, disons, par des effets très gourmands sur la tranche correspondante) alors que le gestionnaire de l’OS, lui, indiquera bcp moins (disons 25%) puisque, lui, tient compte du fait qu’un seul des n cœurs (pour l’ensemble du système) est sollicité par un logiciel.

Par corollaire, nous pouvons donc en déduire que plus nous utilisons de BUS/AUX dans un DAW, plus nous lions ensemble des pistes/tranches qui se partagent alors une même « grande chaine d’effet ». Du coup, le DAW peut moins efficacement dispatcher et traiter de façon simultanée, au même instant t, les divers effets de cette « grande chaine » entre tous les cœurs/thread du CPU parce qu’il doit attendre que les premiers, dans l’ordre du temps, soient calculés avant de passer aux suivants!

Donc, dans certains projets, il vaut parfois mieux travailler en utilisant des pistes indépendantes plutôt que de router toutes les tranches dans un BUS commun. De cette façon, le DAW peut dispatcher et donc traiter (par plus d’un cœur/thread) simultanément, au même instant t, les chaines d’effets qui ne sont pas liés entres elles, ce qui fait que, parfois, même si l’on a bcp plus de VST d’ouverts dans le DAW, la charge sera répartie en plusieurs cœurs/thread et la gauge d’utilisation CPU indiquera un moindre pourcentage, même si cela semble paradoxal ou contre-intuitif à priori, qu’un autre projet utilisant moins de plugins, mais où ils sont tous lié dans un processus en série (de par un BUS commun).

La gauge CPU dans un DAW, contrairement à la gauge du gestionnaire de l’OS, n’indique pas forcément le total de tous les cœurs, mais le plus haut peak de n’importe quel des cœurs/thread utilisés à un instant t précis. Et cela est logique, parce que si un cœur/thread est sollicité à 99% du fait qu’un traitement qui ne peut se faire en parallèle le sollicite presque en entier, car ne pouvant pas utiliser les autres cœurs/thread simultanément, ben à quoi bon diviser le pourcentage par n cœur/thread et nous indiquer /n % puisque, de toute façon, à cet instant t précis, le seul cœur/thread utilisable~exploitable est à 99%! Le DAW est donc bel et bien à 99% de ses capacités de traitement à cet instant t précis puisqu’il ne peut pas exploiter les autres cœurs/thread

Autre exemple concret :

Imaginons une seule piste/tranche de guitare, pour jouer/s’amuser live (au clic du DAW). Ben, même si nous avons un Xeon 12 coeurs/24 threads @2.6GHz, si ce dernier (le seul cœur/thread exploitable dans ce projet) arrive au taquet avec tous les effets que nous ouvrons sur cette seule et unique tranche (effets traités nécessairement en série), nous aurons des glitchs/drops/underruns plus rapidement que si nous achetons un « simple » I7 7700K 4 coeurs/8threads @4,5GHz parce que le seul cœur/thread exploitable (dans cet exemple précis) possède près de 2GHz de plus!

Par contre, si nous ouvrons 12 VSTi ayant chacun leur propre tranche/piste et n’utilisant pas de BUS/AUX communs, là, le 12 coeurs/24 threads @2,6GHz sera probablement plus efficient (ainsi que pour faire du « rendering offline » vidéo, P. Ex.).

Conclusion : pour de la MAO et surtout pour ceux que le temps réel (enregistrement d'instruments live, jeu/entrée de notes live avec clavier MIDI via VSTi) est très important et/ou qui doivent bosser avec des valeurs de buffer très basses, il est nettement préférable de prioriser l'achat d'une haute fréquence de CPU et non du nombre de cœurs/thread. Pour ceux qui composent à la souris dans le piano roll (ou par notation) et/ou qui écoutent/mixent sans jouer/enregistrer en temps réel (pouvant donc monter le buffer de leur carte son au max), un plus grand nombre de cœurs/thread est préférable.

Mais dans les deux cas, il y a nécessairement un compromis : dans le premier, le CPU sera plus efficient en temps réel avec des valeur de buffer basses, mais pour mixer et écouter, il pourra gérer, au total, moins de VST/VSTi (à valeur de buffer identique élevé). Dans le second, se sera le contraire : moins performant en temps réel avec des valeurs de buffer basses, mais pouvant faire jouer (à valeur de buffer identique élevé) plus de VST/VSTi que le premier.

Mais encore, tout ceci dépendamment de l'utilisation, ou non, du nombre de BUS/AUX qui créées des chaines de traitement en série.

Mais darkmoon, je suis d'accord avec ce que tu dis, en gros tu expliques de façon très détaillé (trop pour les impatients ) ce que je sais déjà et ce dont je me plains mais tu n'as pas compris mon propos final.
Je ne vois pas pourquoi c'est impossible de programmer ça autrement. Quand tu dis ça :

Citation :

le DAW ne peut pas utiliser n cœurs afin de traité simultanément ces 3 effets parce que c’est virtuellement impossible! Parce qu’avant de pouvoir calculer et appliquer le résultat du dernier effet, il doit nécessairement calculer le résultat du premier, du deuxième et du troisième. Du coup, quand un cœur/thread calcule le résultat du premier effet, il est impossible qu’un autre cœur/thread puisse effectuer le calcul de l’effet qui suit (dans une même chaine d’effet/tranche) au même instant t puisqu’il ne connaît pas encore le résultat de l’effet précédent! Pour résumer, toute piste audio ou VSTi qui est lié à une même chaine d’effets (piste/tranche/BUS/AUX) ne peut être traité que par un seul et unique cœur.

Je ne vois pas pourquoi il n'est pas possible de répartir dès le départ le 1er effet sur tous les coeurs puis le 2ème puis le 3ème. On doit respecter l'ordre OK mais on peut très bien répartir tout systématiquement en temps réel, il ya des logiciels dans d'autres domaines qui le font très bien. Cela revient à créer des taches cycliques déterministes qui mutualisent tous les coeurs plutôt que des taches interruptives qui sont exécutées à la volée. Pour protéger le fonctionnement de ces taches cyclique, un watchdog classique pourrait basculer en tâches interruptives traditionnelles en cas de dépassement du temps de cycle car il ne s'agit pas non plus de tout ralentir.
Après ce que tu décris en détail était le fonctionnement de Logic 9 à Logic 10.2 ou pour soulager le problème de surcharge single-core on ajoutait plus de bus. Or cela a changé. Quand je mets pleins d'effets (genre grosse reverb et tout) sur la même piste dans Logic 10.4.1, c'est aujourd'hui réparti sur plusieurs coeurs surtout si c'est des effets de Logic, pareil avec certains effets gourmands comme Amplitube.. etc. Ce que tu expliques, c'était avant. Il y a eu de gros progrès avec Logic 10.3.3, et je suis surpris vu ton long discours que tu n'en tiennes pas compte.. Par contre pour les IVs ce n'est pas encore bien réparti. Les développeurs de Logic ont su améliorer les choses et ils peuvent sûrement faire mieux. Voilà ce que je demande.
Et sinon bien sur Corbo-Billy que je privilégie plusieurs instances de Kontakt en mono-timbral, je n'ai pas demandé d'aide, j'arrive à contourner le problème depuis 8 ans, donc... Je n'accepte juste pas cet état de fait et vous, vous semblez l'accepter.
Je pense que c'est un problème de programmation et qu'une fois résolu on pourrait enfin profiter pleinement des machines multi-coeurs plutôt que devoir tourner à des fréquences infernales qui font surchauffer les machines. On voit bien que le multi-coeurs est l'avenir, donc il faut l'utiliser pleinement.

Non aucunement car après utilisation des versions 8 et 9 de LOGIC, je n'ai pas poursuivi avec l'actuelle version .