Se connecter
Se connecter

ou
Créer un compte

ou

Tordre le cou au moteur audio:

  • 212 réponses
  • 40 participants
  • 29 200 vues
  • 56 followers
Sujet de la discussion Tordre le cou au moteur audio:
Ok, je vais essayer de mettre dans ce thread un petit recapitulatif d'avis t d'infos récupérés a droite a gauche sur le net, afin de ruiner le vieux mythe du moteur audio. merci de ne pas poster de commentaires et de ne pas entamer de fumeux debats sans arguments ici.
pour ça, un autre thread:
Tordre le coup au moteur audio: polemiques et crtiques
Afficher le sujet de la discussion
71
Citation :
Mais je ne suis pas assez calé pour vous expliquer la programmation orienté objet

Ben ça par exemple je le maîtrise. Par contre non ça n’est pas à la base de l’AI, ça n’a rien à voir.

À mon avis tu as trop de « certitudes » sur des sujets que tu ne connais que très peu.


Citation :
Surtout avec des effets lourds, je n'imagine pas le process attendre bêtement la fin du traitement d'une grosse reverb à convolution avant de passer à la suite, même si c'est le même signal qui les traverse.

Pour une convolution, de même que pour un filtre FIR (qui est une convolution), il me semble bien qu’on peut calculer en parallèle les y1 y2 y3 y4 que j’évoquais plus haut.

Mais est-ce que c’est fait comme ça ? Ça me semble bien acrobatique ; mais pas impossible...
72
73
@Dr Pouet
Citation :
À mon avis tu as trop de « certitudes » sur des sujets que tu ne connais que très peu.

J'ai plusieurs fois reconnu ne pas savoir vraiment, donc le dirais plutôt des intuitions que des certitudes ;)
Franchement le coup de 2+2 ou Y=f(g(x)), comme seule justification ça me semble dépassé. J'ai peut être complètement tord, (qu'importe, j'ai l'habitudes de dire des conneries) mais si on en est encore à ce que vous dites ce n'est pas la peine de fabriquer des machines 36 cores.
Citation :
Ben ça par exemple je le maîtrise. Par contre non ça n’est pas à la base de l’AI, ça n’a rien à voir.

Il me semble avoir lu un truc à ce sujet il y a 4 ou 5 ans ... ou bien c'était le roman de Crichton, la proie ;)
Du coup tu pourrais m'expliquer comment le principe de substitution de Liskov s'applique, pour mes petits neurones c'est de la science fiction.
x
Hors sujet :
Sinon je suis très impressionné par certaines de tes interventions dans ce sujet, du coup il vaudrait mieux que je ferme gueule maintenant :??:

[ Dernière édition du message le 23/04/2018 à 11:27:34 ]

74
Citation :
existe aujourd'hui des techniques qui permettent de mutualiser les cœurs pour fabriquer une sorte de gros cœur, du coup ta fonction g(x) est plus vite réalisé avant de devoir appliquer f.

Si on a :
y = f(x) + g(x) + h(x)
On peut calculer f, g et h sur trois cœurs différents, puis rassembler les résultats pour calculer y.

Par contre pour f(g(x)), difficile de commencer le calcul de f avant la fin de g.


Citation :
Par ailleurs en programmation orienté objet, selon le principe de substitution de Liskov il est possible (même si cela vous semble une aberration) d'effectuer le calcul final Y sans avoir le résultat de g(x) en le remplaçant par une forte probabilité puis en le substituant à la toute fin (en gros hein, c'est beaucoup plus bizarre que ça en réalité).

Non il n’y a pas de « forte probabilité » d’une certaine valeur, pour un sample qui passe à travers une EQ. Et le principe de Liskov qui correspond au principe de l’héritage en langage objet, ne va pas aider à ça.

Je soupçonne que pour cette histoire de probabilité, tu confondes avec « la probabilité de passer dans une branche de code plutôt qu’une autre », ce qui oriente le microprocesseur dans la préparation des instructions suivantes.


Sinon en termes d’échanges sur forum, on ne fait qu’essayer d’expliquer les choses clairement, simplement et rigoureusement. Pas la peine d’être agressif hein ! :boire:
75
Citation de Hakim+K :

J'ai plusieurs fois reconnu ne pas savoir vraiment, donc le dirais plutôt des intuitions que des certitudes ;)
Franchement le coup de 2+2 ou Y=f(g(x)), comme seule justification ça me semble dépassé.

Et pourtant, si, c'est le cas. L'essentiel du boulot en parallélisme, c'est de gérer les dépendances de données. Quand une opération a besoin du résultat d'une autre, tu es bien obligé d'attendre le résultat de la première avant de commencer la deuxième. Les trucs prédictifs et une exécution spéculative peuvent à la rigueur marcher si le résultat que tu attends est booléen, mais pas si c'est un flottant 32 bits (avec 2^32 combinaisons).

Après, il y a le grain de parallélisation. Effectivement, on peut imaginer aller plus loin que simplement répartir les pistes et bus sur les cores, et paralléliser le calcul du plugin directement. Et c'est vrai que, par exemple, une FFT peut se paralléliser. Le problème, c'est que la synchronisation entre les cores a un coût très loin d'être négligeable, et ce coût sera amorti pour des tableaux de 100.000 flottants, mais pas du tout pour un buffer de 32, 64, 128.

Vu que tu as l'air d'aimer les arguments d'autorité, ce que je raconte ne vient pas de mon "intuition". Le parallélisme, c'est mon métier.

Citation de Hakim+K :
J'ai peut être complètement tord, (qu'importe, j'ai l'habitudes de dire des conneries) mais si on en est encore à ce que vous dites ce n'est pas la peine de fabriquer des machines 36 cores.


Tu as dû te rendre compte que le Skylake-X à 36 cores ne fait pas partie de la gamme "grand public" d'Intel. C'est utile pour des applications très gourmandes en calcul (rendu 3D, vidéo, simulations, etc.), pas pour du simple traitement audio qui est très léger en comparaison.
76
Citation :
Je soupçonne que pour cette histoire de probabilité, tu confondes avec « la probabilité de passer dans une branche de code plutôt qu’une autre », ce qui oriente le microprocesseur dans la préparation des instructions suivantes.

Ben oui c'était un peu ça l'idée...
Citation :
Sinon en termes d’échanges sur forum, on ne fait qu’essayer d’expliquer les choses clairement, simplement et rigoureusement. Pas la peine d’être agressif hein ! :boire:

Ok, mais comprends quand même que j'ai eu l'impression d'être agressé en premier quand on me dit à 4 reprises que je ne comprend pas 2+2 ou Y=f(g(x)), au bout d'un moment ça énerve non? Un peu d'ouverture d'esprit pour ne serait-ce qu'envisager un autre point de vue aurait évité cela.
Citation :
Quand une opération a besoin du résultat d'une autre, tu es bien obligé d'attendre le résultat de la première avant de commencer la deuxième.
Et de 5, je crois qu'on bien compris ça, vous pouvez juste arrêter de le répéter.

[ Dernière édition du message le 23/04/2018 à 11:56:59 ]

77
Citation :
mais si on en est encore à ce que vous dites ce n'est pas la peine de fabriquer des machines 36 cores.

Ah ben si, car il y a plein d’autres logiciels qui en bénéficient bien. Et surtout : en général on fait tourner plein de logiciels en même temps sur nos ordinateurs. Et généralement chaque logiciel, à commencer par le système d’exploitation, utilise plusieurs threads (= fil d’execution = des programmes indépendants mais qui se synchronisent de temps à autres). Or chacun de ces threads peut tourner sur un cœur différent, d’où « une certaine augmentation de puissance ».

Mais s’il y a un thread qui fait des calculs hyper lourds, alors ça pourra se passera mieux avec moins de cœurs mais une fréquence d’horloge plus élevée (en supposant que ce soit les mêmes cœurs ; situation un peu théorique).
78
Citation :
Du coup tu pourrais m'expliquer comment le principe de substitution de Liskov s'applique, pour mes petits neurones c'est de la science fiction.

Ben c’est peu long à expliquer, bien que pas hyper compliqué dans le fond des choses.

J’ai un peu de mal à trouver un exemple bien clair, mais celui-ci n’est pas trop mal :
https://fr.wikipedia.org/wiki/Polymorphisme_(informatique)#Intérêt_du_polymorphisme


Citation :
Ok, mais comprends quand même que j'ai eu l'impression d'être agressé en premier quand on me dit à 4 reprises que je ne comprend pas 2+2 ou Y=f(g(x)), au bout d'un moment ça énerve non?

Ben ce n’était pas méprisant ; juste pour essayer d’être clair et précis. Je vois ce que tu veux dire, et je suis donc désolé que tu te sois senti agressé. :boire:

Citation :
Sinon je suis très impressionné par certaines de tes interventions dans ce sujet,

Bah on a tous nos petites passions et domaines de compétences ! L’informatique est hypervaste et je suis loin de tout connaître, mais ça me passionne depuis longtemps (et assez au centre de mes études et mon boulot).
79
Ces débats sont intéressants car ils montrent certaines des vraies difficultés qui caractérisent le « moteur audio » d’une STAN.

L’amélioration dans Logic 10.3.3 de la gestion du multicœur en est un exemple bien représentatif.

C’est pour ça qu’il ne faut absolument pas essayer de transposer dans le domaine numérique, les difficultés typiques qu’on rencontrait dans l’électronique analogique (comme par exemple « le son » d’une table de mixage).
80
Question complètement innocente puisque je n'y connais rien:
N'est-il pas possible d'imaginer:

Temps t: CORE A calcule r1=g(buffer B1).

Temps t+1 cycle: CORE A calcul r2 = g(buffer B2) | CORE B calcule Y1=f(r1) (obtenu par Core A au temps t)

Temps t+2 cycles: CORE A calcul r3 = g(buffer B3) | CORE B calcule Y2=f(r2) (obtenu par Core A au temps t+1)

etc. ?

Ainsi la relation entre les traitements est respectée mais distribuée sur plusieurs coeur.