Sujet Top config PC MAO 2021 (test, bench, discussion, débat...)
- 1 405 réponses
- 55 participants
- 89 631 vues
- 74 followers
Afficher le sujet de la discussion
En effet, tu as parlé de « OC simple » et du « coefficient multiplicateur à 42 », My bad!
...mais tu t’es focalisé et n’a partagé que concernant les différentes déclinaisons du FLK pour la fréquence de la RAM. Et selon les chiffres que tu partages, puisque qu’il est question de DDR (double data), tu as laissé le FLK de façon à ce que tes fréquences qui concernent le FLK soient toujours de moitié moindre que tes valeurs de RAM MT/s (qui n’est que l’équivalent du double de la fréquence, puisqu’il s’agit de DDR), pour éviter la latence induite par des valeurs « asynchrones » j’imagine.
Bref, je ne m’y connais pas suffisamment avec AMD, mais ce que je veux dire, c’est que lorsque tu parles d’ « OC simple » ou de « coefficient multiplicateur à 42 », tu ne nous as partagé aucune information sur le processeur!
À combien était sa fréquence en OC? Et est-ce que c’était en « sync all core » ou pas?
Pour ce que j’ai déjà lu sur les BIOS de CM pour AMD (mais je peux me tromper, je n’ai aucune expérience avec les Ryzen), le FLK est étroitement lié à la RAM et agirait aussi pour le BUS PCI, mais je n’ai aucune idée si ça affecte aussi le CPU (le BCLK et son coeff X et donc sa fréquence). Et puisque tu ne nous a partagé aucune info sur les « OC » de ton CPU, ben l'on ne sait rien!
Ton 5800X fonctionne originellement à 3.8 GHz/4.7 GHz turbo. Donc lorsque t’as mis le coeff à 42, ton BCLK était à combien? 100mhz MHz? Si oui, donc ton processeur tournait à 4.2 GHz ?? Tous les cœurs en « sync », simultanément?
Et quand tu parles « d’OC simple » (pour les points c à d), ben l’on ne sait rien concernant les résultats sur le CPU puisque tu n’as rien partagé à ce sujet, sauf les valeurs qui concernent la RAM. ...d'où pourquoi je pensais que tu focalisais essentiellement sur l'incidence des différents OC de ta RAM!
Comment peut-on conclure que l’OC de ton CPU (et de ta RAM, mais ça, nous l’avons observé) ne produit pas de gain significatif si nous ne connaissons pas les valeurs de l’OC de ton CPU? T’es passé de quelle valeur à quelle valeur, concernant les GHz de ton CPU, ses différents cœurs?
Tu veux bien développer, détailler et/ou m’expliquer ce que je ne saisis pas très bien concernant l’OC AMD steplait! Thx!
Wow! Excellent!
Ca me donne envie de refaire le bench, maintenant que je suis repassé sur W7 et que j'ai une nouvelle interface (Studio 1810c) qui performe un peu mieux que mon ancien Quad-Capture en 64smp.
Vais tenter de faire ça ce soir!
Ouais, mais faudrait savoir de combien t'as « overclockdimanché »
ton CPU avant de tirer des conclusions.
Ben même chose que ce que je dis à Danbei : il y a « overclock » et « overclock »! C'est sur qu'ajouter 100MHz sur chaque cœur, ça doit pas faire une différence de ouf, surtout si, dépendamment du projet (en situation réelle), l'on bosse sur un petit projet qui sollicite surtout une chaîne en série sur un seul cœur. Par contre, ajouter 400MHz~500MHz sur chacun des cœurs (en les obligeant tous à bosser à la même fréquence), quand on dispose de 8 cœurs, P. Ex., ça doit forcément impacter de façon non négligeable les gros projets qui sollicitent tous les cœurs. Ça fait quand même entre 3,2GHz~4,0GHz de plus au total de dispo!
Bref, c'est pour ça que j'aimerais bien connaître les valeurs d'OC du CPU de Danbei
Pour ce qui est de la RAM, j'ai toujours su (je le disais il y a déjà plusieurs années sur AF) que ça n'impactait pratiquement pas les perfs. Déjà, même sans tester, c'est surtout une question d'implication logique puisqu'un coup chargé, un VSTi gourmand comme Diva, P. Ex., ben c'est le processeur qui fait tout (calculs)! Bien sûr que les échanges de donnée entre l'OS, le DAW, les différents ports de com, etc. doivent être en adéquation avec les restes des composants de la machine, et donc la RAM (qui doit fournir le CPU et tout et tout), mais pour des tâches essentiellement de « calculs » (VST/VSTi), c'est le processeur qui fait toute la différence! Quand bien même nous avions de la RAM « DDR8 » qui fonctionnerait à une freq de « 9999 Mhz », ça ne changerait pas grand-chose concernant ce que le (actuel, en 2021) CPU doit calculer pour Diva et/ou n'importe quel VST/VSTi!
Idem, P. Ex., avec un port de transfert (USB, TB) à la latence complètement nulle (même si c'est impossible physiquement~scientifiquement)! Ok, plus de latence USB/TB, mais puisque c'est surtout celles de l'interface audio et des temps de buffer que nécessite le processeur pour faire ses calculs qui sont les plus importantes, l'on gagnerait que l'absence de latence induite par l'USB et le TB (latence déjà négligeable comparée à tout le reste). Bref, il y a des trucs qui ne nécessitent pas d'être testé pour être « évalués~anticipés ».
En effet, c’est ce que certains éditeurs de DAW et codeurs recommandent et/ou précisent. Que el fait de partager des chaînes de traitement via Bus, Aux, send commun force le traitement en série par un seul cœur. Mais comme j’ai dit, c’est plutôt difficile à tester. À l’époque de mes bench, j’avais tenté, pendant une soirée, d’en faire un spécifiquement sur cet aspect, mais j’avais finalement abandonné (les autres bench m’intéressaient bcp plus).
Ce qu’il est possible de faire, dans le but d’observer si l’affirmation est exacte dans un premier temps, c’est :
- ouvrir par exemple plusieurs dizaines de pistes/tranches (avec chacun un fichier audio déjà enregistrée, qui ne consomme donc pratiquement aucun calcul par le CPU) et de toute leur foutre une reverb qui consomme bcp de ressource. L’on fait jouer toutes ces pistes et l’on observe ensuite la charge processeur sur tous les cœurs,
- ensuite (nouveau projet vide et/ou reboot le PC!!!), l’on ouvre qu’une seule piste du même fichier audio, mais nous créons autant de BUS/AUX que nécessaire pour foutre autant de reverb, mais cette fois en série (ça ce fait tout seul via les BUS/AUX commun). L’on fait jouer toutes ces pistes et l’on observe ensuite la charge processeur sur tous les cœurs.
Et, en effet, l’on va remarquer que, dans le premier cas, tous les cœurs sont bcp plus sollicités que dans le 2e cas et obtenons des glitch bcp moins rapidement que dans le 2e cas où l’on arrivera à saturation~glicth bcp plus rapidement avec une utilisation CPU bcp plus forte sur un cœur en particulier.
Mais j’avais remarqué que ce n’est pas systématique à 100%, même si la tendance est évidente, que ça variait selon les pugins utilisés et qu’il faut vraiment utiliser bcp de plugins pour constater des différences. En utilisant par exemple 30 pistes/30 VST, la différence n’est parfois pratiquement pas observable (étant donné la puissance actuelle de nos processeurs). Enfin, peut-être n’avais-je pas suffisamment investiguer et/ou commis des erreurs. Faudrait retenter le coup!
Je vais peut-être retenter l’expérience en même temps que je referai le bench!
Darkmoon
4068
Squatteur·euse d’AF
Membre depuis 20 ans
Citation de Danbei :
PS : tu avais bien compris, j'ai testé un OC du CPU et de la RAM
En effet, tu as parlé de « OC simple » et du « coefficient multiplicateur à 42 », My bad!
...mais tu t’es focalisé et n’a partagé que concernant les différentes déclinaisons du FLK pour la fréquence de la RAM. Et selon les chiffres que tu partages, puisque qu’il est question de DDR (double data), tu as laissé le FLK de façon à ce que tes fréquences qui concernent le FLK soient toujours de moitié moindre que tes valeurs de RAM MT/s (qui n’est que l’équivalent du double de la fréquence, puisqu’il s’agit de DDR), pour éviter la latence induite par des valeurs « asynchrones » j’imagine.Bref, je ne m’y connais pas suffisamment avec AMD, mais ce que je veux dire, c’est que lorsque tu parles d’ « OC simple » ou de « coefficient multiplicateur à 42 », tu ne nous as partagé aucune information sur le processeur!
À combien était sa fréquence en OC? Et est-ce que c’était en « sync all core » ou pas? Pour ce que j’ai déjà lu sur les BIOS de CM pour AMD (mais je peux me tromper, je n’ai aucune expérience avec les Ryzen
), le FLK est étroitement lié à la RAM et agirait aussi pour le BUS PCI, mais je n’ai aucune idée si ça affecte aussi le CPU (le BCLK et son coeff X et donc sa fréquence). Et puisque tu ne nous a partagé aucune info sur les « OC » de ton CPU, ben l'on ne sait rien! Ton 5800X fonctionne originellement à 3.8 GHz/4.7 GHz turbo. Donc lorsque t’as mis le coeff à 42, ton BCLK était à combien? 100mhz MHz? Si oui, donc ton processeur tournait à 4.2 GHz ?? Tous les cœurs en « sync », simultanément?
Et quand tu parles « d’OC simple » (pour les points c à d), ben l’on ne sait rien concernant les résultats sur le CPU puisque tu n’as rien partagé à ce sujet, sauf les valeurs qui concernent la RAM. ...d'où pourquoi je pensais que tu focalisais essentiellement sur l'incidence des différents OC de ta RAM!
Comment peut-on conclure que l’OC de ton CPU (et de ta RAM, mais ça, nous l’avons observé) ne produit pas de gain significatif si nous ne connaissons pas les valeurs de l’OC de ton CPU? T’es passé de quelle valeur à quelle valeur, concernant les GHz de ton CPU, ses différents cœurs?
Tu veux bien développer, détailler et/ou m’expliquer ce que je ne saisis pas très bien concernant l’OC AMD steplait! Thx!
"Si t'enregistres à Poudlard, avec l'ingé son Dumbledore, les lois physiques tu peux t'en foutre. Mais dans l'monde réel, les lois physiques, les mesures, le dBFS, tout ça existe bel et bien." youtou
[ Dernière édition du message le 15/11/2021 à 03:45:48 ]
Darkmoon
4068
Squatteur·euse d’AF
Membre depuis 20 ans
Citation de ardier :
salut mon résultat de test,
avec ryzen 7 5950x horloge fixe 4.4Ghz ddr4-3200 cl14 noctua dh 15 s (mais avec un ventilo supplémentaire) rme hdspe raydat/adi 8 qs
buffer 64, latence 1.4/2.2ms
j'ai pu mettre 54 pistes sans glitch audible à 55 j'ai eu des glitch aléatoire et 56 ça glitsch tout le temps
j'etais a 67 degrés et 140w tdp
Wow! Excellent!
Ca me donne envie de refaire le bench, maintenant que je suis repassé sur W7 et que j'ai une nouvelle interface (Studio 1810c) qui performe un peu mieux que mon ancien Quad-Capture en 64smp.
Vais tenter de faire ça ce soir!
"Si t'enregistres à Poudlard, avec l'ingé son Dumbledore, les lois physiques tu peux t'en foutre. Mais dans l'monde réel, les lois physiques, les mesures, le dBFS, tout ça existe bel et bien." youtou
Darkmoon
4068
Squatteur·euse d’AF
Membre depuis 20 ans
Citation de Danbei :
Effectivement pas super intéressant. Même si j'ai fais un OC d'overclocker du dimanche
Ouais, mais faudrait savoir de combien t'as « overclockdimanché »
ton CPU avant de tirer des conclusions. Citation de Eric :
de toute façon quand tu vois que les gamer font des oc pour 5 ou 10 fps... perso je préfère du matériel qui dure plutôt que des résultats e hausse mais pas très longtemps. donc un oc léger ok mais pour gagner combien.???
Ben même chose que ce que je dis à Danbei : il y a « overclock » et « overclock »! C'est sur qu'ajouter 100MHz sur chaque cœur, ça doit pas faire une différence de ouf, surtout si, dépendamment du projet (en situation réelle), l'on bosse sur un petit projet qui sollicite surtout une chaîne en série sur un seul cœur. Par contre, ajouter 400MHz~500MHz sur chacun des cœurs (en les obligeant tous à bosser à la même fréquence), quand on dispose de 8 cœurs, P. Ex., ça doit forcément impacter de façon non négligeable les gros projets qui sollicitent tous les cœurs. Ça fait quand même entre 3,2GHz~4,0GHz de plus au total de dispo!
Bref, c'est pour ça que j'aimerais bien connaître les valeurs d'OC du CPU de Danbei
Pour ce qui est de la RAM, j'ai toujours su (je le disais il y a déjà plusieurs années sur AF) que ça n'impactait pratiquement pas les perfs. Déjà, même sans tester, c'est surtout une question d'implication logique puisqu'un coup chargé, un VSTi gourmand comme Diva, P. Ex., ben c'est le processeur qui fait tout (calculs)! Bien sûr que les échanges de donnée entre l'OS, le DAW, les différents ports de com, etc. doivent être en adéquation avec les restes des composants de la machine, et donc la RAM (qui doit fournir le CPU et tout et tout), mais pour des tâches essentiellement de « calculs » (VST/VSTi), c'est le processeur qui fait toute la différence!
Quand bien même nous avions de la RAM « DDR8 » qui fonctionnerait à une freq de « 9999 Mhz », ça ne changerait pas grand-chose concernant ce que le (actuel, en 2021) CPU doit calculer pour Diva et/ou n'importe quel VST/VSTi!Idem, P. Ex., avec un port de transfert (USB, TB) à la latence complètement nulle (même si c'est impossible physiquement~scientifiquement)! Ok, plus de latence USB/TB, mais puisque c'est surtout celles de l'interface audio et des temps de buffer que nécessite le processeur pour faire ses calculs qui sont les plus importantes, l'on gagnerait que l'absence de latence induite par l'USB et le TB (latence déjà négligeable comparée à tout le reste). Bref, il y a des trucs qui ne nécessitent pas d'être testé pour être « évalués~anticipés ».
"Si t'enregistres à Poudlard, avec l'ingé son Dumbledore, les lois physiques tu peux t'en foutre. Mais dans l'monde réel, les lois physiques, les mesures, le dBFS, tout ça existe bel et bien." youtou
Darkmoon
4068
Squatteur·euse d’AF
Membre depuis 20 ans
Citation de ardier :
En fait quand tu cumules vst instruments/sound design/mix/group bus/effet sur master(plugins en série) il me semble que tu peux vite saturer sur un coeur unique
En effet, c’est ce que certains éditeurs de DAW et codeurs recommandent et/ou précisent. Que el fait de partager des chaînes de traitement via Bus, Aux, send commun force le traitement en série par un seul cœur. Mais comme j’ai dit, c’est plutôt difficile à tester. À l’époque de mes bench, j’avais tenté, pendant une soirée, d’en faire un spécifiquement sur cet aspect, mais j’avais finalement abandonné (les autres bench m’intéressaient bcp plus).
Ce qu’il est possible de faire, dans le but d’observer si l’affirmation est exacte dans un premier temps, c’est :
- ouvrir par exemple plusieurs dizaines de pistes/tranches (avec chacun un fichier audio déjà enregistrée, qui ne consomme donc pratiquement aucun calcul par le CPU) et de toute leur foutre une reverb qui consomme bcp de ressource. L’on fait jouer toutes ces pistes et l’on observe ensuite la charge processeur sur tous les cœurs,
- ensuite (nouveau projet vide et/ou reboot le PC!!!), l’on ouvre qu’une seule piste du même fichier audio, mais nous créons autant de BUS/AUX que nécessaire pour foutre autant de reverb, mais cette fois en série (ça ce fait tout seul via les BUS/AUX commun). L’on fait jouer toutes ces pistes et l’on observe ensuite la charge processeur sur tous les cœurs.
Et, en effet, l’on va remarquer que, dans le premier cas, tous les cœurs sont bcp plus sollicités que dans le 2e cas et obtenons des glitch bcp moins rapidement que dans le 2e cas où l’on arrivera à saturation~glicth bcp plus rapidement avec une utilisation CPU bcp plus forte sur un cœur en particulier.
Mais j’avais remarqué que ce n’est pas systématique à 100%, même si la tendance est évidente, que ça variait selon les pugins utilisés et qu’il faut vraiment utiliser bcp de plugins pour constater des différences. En utilisant par exemple 30 pistes/30 VST, la différence n’est parfois pratiquement pas observable (étant donné la puissance actuelle de nos processeurs). Enfin, peut-être n’avais-je pas suffisamment investiguer et/ou commis des erreurs. Faudrait retenter le coup!
Je vais peut-être retenter l’expérience en même temps que je referai le bench!
"Si t'enregistres à Poudlard, avec l'ingé son Dumbledore, les lois physiques tu peux t'en foutre. Mais dans l'monde réel, les lois physiques, les mesures, le dBFS, tout ça existe bel et bien." youtou
Eric Music Strasbourg
4596
Squatteur·euse d’AF
Membre depuis 17 ans
ardier
422
Posteur·euse AFfamé·e
Membre depuis 18 ans
dogfacedgremelin
2000
AFicionado·a
Membre depuis 21 ans
ardier
422
Posteur·euse AFfamé·e
Membre depuis 18 ans
Eric Music Strasbourg
4596
Squatteur·euse d’AF
Membre depuis 17 ans
Darkmoon
4068
Squatteur·euse d’AF
Membre depuis 20 ans
Bon, voilà, j'ai refait le bench SGA!
Darkmoon PC (version novembre 2021) :
- Intel Core i7-8700K Coffee Lake 6-Core 3.7 GHz (4.7 GHz Turbo) LGA 1151
(OC à 4.8GHz. C'est un OC léger de 100MHz/core, « sync all core » à 4.8, rien d'extrême)
- ASUS Tuf Pro Gaming Z370 (BIOS version Version 2503 - 2020/11/05)
- DDR4 Kingston HyperX FURY 4x16Go, 2400MHz CL15 (profil XMP dans le BIOS)
- NVidia GeForce GTX 1060 6Go
- Presonus studio 1810c USB3
- NVMe 960 EVO 250Go (pour l'OS)
- NVMe 960 EVO 1000Go (pour banque Kontakt & samples)
- SSD SanDisk 1000Go (pour dossiers de travail MAO & montage vidéo)
- SSD SanDisk 1000Go (pour dossiers temp/cache/proxy)
- HDD Western Digital Blue (pour archives)
- Cooler Master Hyper 212 LED
- Thermaltake Smart Series 600W 80 PLUS
- Ventirad supplémentaire 120mm à l'arrière
- Case : Fractal Design Focus G Gunmetal
- Windows 7 Intégrale 6.1. SP1 Build 7601 (installé de peine et de misère avec wufuc pour contourner l'incompatibilité de Win update ainsi qu'avec des pilotes de chipset en version bêta, etc.). Optimisation MAO de base (option d'alimentation, USB, etc) + désactivation de l'indexation, du SuperFetch, de WDefender, désactivation de la mémoire virtuelle (aucun fichier d'échange) et du fichier « hiberfil.sys » (hibernation). C'est tout!
Je partagerai mes réglages du BIOS dans un autre message pour Eric Music Strasbourg
__________
J’ai téléchargé le fichier fourni par Danbei ici. À l’ouverture, j’ai eu un message d’erreur. J’ai dû décocher « lecture seule » pour le dossier de Reaper que j’ai mis dans C:\Program Files. J’ai ajouté mon fichier de licence Reaper et j’ai dû modifier les chemins des dossiers pour mes plugins (par défaut, il manquait C:\Program Files\Common Files\VST2) et choisir les pilotes ASIO de ma nouvelle interface. C’est tout! Après fermeture/réouverture, le projet (que j’avais créé il y a quelques années) s’est ouvert correctement!
Notez, comme vous pouvez le constater dans mes vidéos, que sont en action, en plus du DAW, HWMonitor, CPU-Z, ainsi qu'OBS qui effectue simultanément une capture vidéo en 1080p/2500kbps (ces 3 logiciels, surtout OBS, consomment naturellement des ressources processeur).
Voici mes résultats :
Avec le buffer à 64smp, je peux faire jouer 19 pistes/instance de SGA en parallèle sans aucun glitch. La température des cœurs avoisinant ±68°C et tous les cœurs étant à ±98% d'utilisation. On remarquera qu'ils opèrent tous à 4.8GHz (4786MHz, tout en bas de la fenêtre) :
À 20 pistes/instances, ça ne glitch pas, ça sature carrément!
L'utilisation est à 100% pour presque tous les cœurs, mais les températures demeurent sensiblement les mêmes :
Par contre, lorsque je ferme OBS, CPU-Z et HWMonitor, je peux faire jouer, avec quelques petits glitchs par-ci par-là 20 instances!
Sinon, avec un buffer à 1024, je peux juste faire jouer une instance de plus. Mais bon, pour moi, c’est le buffer à 64smp qui m’importe et qui demeure ma référence. L’on notera tout de même (et c’était pareil à l’époque de mes anciens bench), que ce soit chez moi ou chez vous tous, que le fait d’augmenter le buffer, même jusqu’à 1024smp, n’a manifestement pas bcp d’impact lorsque nous atteignons la limite en 64smp. La limite semble presque la même en 1024. J’avoue que ça, je ne me l’explique pas. Tous les cœurs ont 16 fois plus d’échantillons (et pour mon interface je passe de 5.3ms à 51ms, donc près de 10 fois plus de temps~buffer) pour effectuer leurs calculs, mais arrivent à peine à faire jouer une instance de plus.
Conclusion : c’est quelque peu mieux que ce que j’arrivais à faire à l’époque, où je plafonnais à 17 instances. Je peux maintenant en faire jouer 19 sans problème, tout en effectuant une capture vidéo avec OBS. Pas mal pour un « maintenant vieux » 8700K!
Est-ce dû à W7?, Bah, je sais pas trop puisque j’utilise maintenant une autre interface audio. Quoique la différence entre mon ancienne, qui générait 7.6ms à 64smp VS 5.3ms maintenant avec la Presonus, ça ne doit pas être si impactant étant donné ce que l’on observe concernant la différence entre 64smp VS 1024smp, toutes interfaces confondues. Peut-être que W7 (moins de processus en activité) + mes tweak + mes réglages de BIOS (qui ont été affiné depuis mes premiers bench) font, cumulativement, la différence!
Sinon, j’ai tenté (en vitesse, mais je vais approfondir un autre jour) d’observer la différence en effectuant un test « en série » au lieu d’en parallèle et le résultat est plus que surprenant! J’explique...
...j’ai supprimé toutes les pistes, sauf la première. Je me retrouve donc avec une seule piste/tranche et une seule instance de SGA. Je tente d’en ajouter d’autres instances sur la même tranche, mais dès la 3e instance, ça sature au max!
Bref, je ne peux exploiter que 2 instances de SGA, même dans un projet n’ayant qu’une seule piste audio!
Bon, sur le principe, ce n’est pas surprenant du tout puisque , justement, ça confirme la théorie. À savoir qu’une chaîne de traitement en série ne peut exploiter tous les cœurs. Et dans la fenêtre de HWMonitor, l’on observe en effet que 7 des 12 « CPU » (12 thread, pour les 6 cœurs de mon 8700K) sont à 0% d’utilisation. Ne reste donc que 5 thread en activité, mais si l’on considère que j’ai OBS qui doit en monopoliser 2 (pour un cœur) sans oublier CPU-Z et HWMonitor qui sont aussi en activité, alors ça fait du sens! Il doit, en effet, n’avoir qu’un seul cœur/2 thread de dispo pour calculer cette tranche dans le DAW. Ça tend donc à confirmer que les plugins d'effet sur une même tranche (ou même « chaîne de traitement » via BUS/AUX) ne peuvent être dispatché, réparti, c’est-à-dire traité sur plus d'un cœur/2 thread!
(Mais ce qui est surprenant, c'est de constater à quel point le SGA, en mode stéréo + high CPU + 4x oversampling, consomme énormément de ressource!
Chez moi, 2 instances maxi pour un cœur @4,8GHz!! )
En plus, ça fait relativement du sens avec mes autres résultats « en parallèle » puisque possédant 6 cœurs/12 thread, si l’on considère que seules 2 instances par cœur/2 thread peuvent être exploitées « en série », il serait étonnant que je puisse exploiter plus de 24 instances, même sur des pistes/tranches différentes (non liée en série). Je trouve que ça a donc du sens avec mes 20 instances maximum, quand je ferme les autres logiciels.
Si vous effectuez vous aussi le test, sur une seule piste/tranche, nous pourrons constater si le rapport semble se maintenir aussi chez vous, en rapport avec le total que vous pouvez faire jouer en parallèle! Je suis très curieux de voir, sur une seule et unique tranche, combien d'instances de SGA un Ryzen 5800X/5900X pourra faire jouer. Étant donné que le nombre de cœurs ne sera plus un avantage (et que la fréquence d'un cœur est similaire à la mienne), j'anticipe que ce ne sera pas bcp plus que moi. Genre 3 tout au plus!?
C'est cool! J'adore quand nous sommes plusieurs à faire ces genres de tests... ...qui permettent de vérifier concrètement ce qui en est!
Darkmoon PC (version novembre 2021) :
- Intel Core i7-8700K Coffee Lake 6-Core 3.7 GHz (4.7 GHz Turbo) LGA 1151
(OC à 4.8GHz. C'est un OC léger de 100MHz/core, « sync all core » à 4.8, rien d'extrême)
- ASUS Tuf Pro Gaming Z370 (BIOS version Version 2503 - 2020/11/05)
- DDR4 Kingston HyperX FURY 4x16Go, 2400MHz CL15 (profil XMP dans le BIOS)
- NVidia GeForce GTX 1060 6Go
- Presonus studio 1810c USB3
- NVMe 960 EVO 250Go (pour l'OS)
- NVMe 960 EVO 1000Go (pour banque Kontakt & samples)
- SSD SanDisk 1000Go (pour dossiers de travail MAO & montage vidéo)
- SSD SanDisk 1000Go (pour dossiers temp/cache/proxy)
- HDD Western Digital Blue (pour archives)
- Cooler Master Hyper 212 LED
- Thermaltake Smart Series 600W 80 PLUS
- Ventirad supplémentaire 120mm à l'arrière
- Case : Fractal Design Focus G Gunmetal
- Windows 7 Intégrale 6.1. SP1 Build 7601 (installé de peine et de misère avec wufuc pour contourner l'incompatibilité de Win update ainsi qu'avec des pilotes de chipset en version bêta, etc.). Optimisation MAO de base (option d'alimentation, USB, etc) + désactivation de l'indexation, du SuperFetch, de WDefender, désactivation de la mémoire virtuelle (aucun fichier d'échange) et du fichier « hiberfil.sys » (hibernation). C'est tout!
Je partagerai mes réglages du BIOS dans un autre message pour Eric Music Strasbourg
__________
J’ai téléchargé le fichier fourni par Danbei ici. À l’ouverture, j’ai eu un message d’erreur. J’ai dû décocher « lecture seule » pour le dossier de Reaper que j’ai mis dans C:\Program Files. J’ai ajouté mon fichier de licence Reaper et j’ai dû modifier les chemins des dossiers pour mes plugins (par défaut, il manquait C:\Program Files\Common Files\VST2) et choisir les pilotes ASIO de ma nouvelle interface. C’est tout! Après fermeture/réouverture, le projet (que j’avais créé il y a quelques années) s’est ouvert correctement!
Notez, comme vous pouvez le constater dans mes vidéos, que sont en action, en plus du DAW, HWMonitor, CPU-Z, ainsi qu'OBS qui effectue simultanément une capture vidéo en 1080p/2500kbps (ces 3 logiciels, surtout OBS, consomment naturellement des ressources processeur).
Voici mes résultats :
Avec le buffer à 64smp, je peux faire jouer 19 pistes/instance de SGA en parallèle sans aucun glitch. La température des cœurs avoisinant ±68°C et tous les cœurs étant à ±98% d'utilisation. On remarquera qu'ils opèrent tous à 4.8GHz (4786MHz, tout en bas de la fenêtre) :
À 20 pistes/instances, ça ne glitch pas, ça sature carrément!
L'utilisation est à 100% pour presque tous les cœurs, mais les températures demeurent sensiblement les mêmes :Par contre, lorsque je ferme OBS, CPU-Z et HWMonitor, je peux faire jouer, avec quelques petits glitchs par-ci par-là 20 instances!
Sinon, avec un buffer à 1024, je peux juste faire jouer une instance de plus. Mais bon, pour moi, c’est le buffer à 64smp qui m’importe et qui demeure ma référence. L’on notera tout de même (et c’était pareil à l’époque de mes anciens bench), que ce soit chez moi ou chez vous tous, que le fait d’augmenter le buffer, même jusqu’à 1024smp, n’a manifestement pas bcp d’impact lorsque nous atteignons la limite en 64smp. La limite semble presque la même en 1024. J’avoue que ça, je ne me l’explique pas. Tous les cœurs ont 16 fois plus d’échantillons (et pour mon interface je passe de 5.3ms à 51ms, donc près de 10 fois plus de temps~buffer) pour effectuer leurs calculs, mais arrivent à peine à faire jouer une instance de plus.
Conclusion : c’est quelque peu mieux que ce que j’arrivais à faire à l’époque, où je plafonnais à 17 instances. Je peux maintenant en faire jouer 19 sans problème, tout en effectuant une capture vidéo avec OBS. Pas mal pour un « maintenant vieux » 8700K!
Est-ce dû à W7?, Bah, je sais pas trop puisque j’utilise maintenant une autre interface audio. Quoique la différence entre mon ancienne, qui générait 7.6ms à 64smp VS 5.3ms maintenant avec la Presonus, ça ne doit pas être si impactant étant donné ce que l’on observe concernant la différence entre 64smp VS 1024smp, toutes interfaces confondues. Peut-être que W7 (moins de processus en activité) + mes tweak + mes réglages de BIOS (qui ont été affiné depuis mes premiers bench) font, cumulativement, la différence!
Sinon, j’ai tenté (en vitesse, mais je vais approfondir un autre jour) d’observer la différence en effectuant un test « en série » au lieu d’en parallèle et le résultat est plus que surprenant! J’explique...
...j’ai supprimé toutes les pistes, sauf la première. Je me retrouve donc avec une seule piste/tranche et une seule instance de SGA. Je tente d’en ajouter d’autres instances sur la même tranche, mais dès la 3e instance, ça sature au max!
Bref, je ne peux exploiter que 2 instances de SGA, même dans un projet n’ayant qu’une seule piste audio!
Bon, sur le principe, ce n’est pas surprenant du tout puisque , justement, ça confirme la théorie. À savoir qu’une chaîne de traitement en série ne peut exploiter tous les cœurs. Et dans la fenêtre de HWMonitor, l’on observe en effet que 7 des 12 « CPU » (12 thread, pour les 6 cœurs de mon 8700K) sont à 0% d’utilisation. Ne reste donc que 5 thread en activité, mais si l’on considère que j’ai OBS qui doit en monopoliser 2 (pour un cœur) sans oublier CPU-Z et HWMonitor qui sont aussi en activité, alors ça fait du sens! Il doit, en effet, n’avoir qu’un seul cœur/2 thread de dispo pour calculer cette tranche dans le DAW. Ça tend donc à confirmer que les plugins d'effet sur une même tranche (ou même « chaîne de traitement » via BUS/AUX) ne peuvent être dispatché, réparti, c’est-à-dire traité sur plus d'un cœur/2 thread!
(Mais ce qui est surprenant, c'est de constater à quel point le SGA, en mode stéréo + high CPU + 4x oversampling, consomme énormément de ressource!
Chez moi, 2 instances maxi pour un cœur @4,8GHz!! )En plus, ça fait relativement du sens avec mes autres résultats « en parallèle » puisque possédant 6 cœurs/12 thread, si l’on considère que seules 2 instances par cœur/2 thread peuvent être exploitées « en série », il serait étonnant que je puisse exploiter plus de 24 instances, même sur des pistes/tranches différentes (non liée en série). Je trouve que ça a donc du sens avec mes 20 instances maximum, quand je ferme les autres logiciels.
Si vous effectuez vous aussi le test, sur une seule piste/tranche, nous pourrons constater si le rapport semble se maintenir aussi chez vous, en rapport avec le total que vous pouvez faire jouer en parallèle! Je suis très curieux de voir, sur une seule et unique tranche, combien d'instances de SGA un Ryzen 5800X/5900X pourra faire jouer. Étant donné que le nombre de cœurs ne sera plus un avantage (et que la fréquence d'un cœur est similaire à la mienne), j'anticipe que ce ne sera pas bcp plus que moi. Genre 3 tout au plus!?
C'est cool! J'adore quand nous sommes plusieurs à faire ces genres de tests... ...qui permettent de vérifier concrètement ce qui en est!
"Si t'enregistres à Poudlard, avec l'ingé son Dumbledore, les lois physiques tu peux t'en foutre. Mais dans l'monde réel, les lois physiques, les mesures, le dBFS, tout ça existe bel et bien." youtou
- < Liste des sujets
- Charte