Posté par Anthony Jaguenaud .
En réponse à la dépêche OpenBSD 5.6.
Évalué à 5.
Dernière modification le 06 novembre 2014 à 11:41.
On ne parle pas de la même chose. D’un côté vous parlez de calcul scientifique, recherche modification d’algo pour gagner du temps. Quand l’algo est prêt, après plusieurs années de recherche, il est publié, intégré dans une bibliothèque et utilisable.
De l’autre, je parle rationalisation, coût.
Le problème à la base est de savoir si openBSD a raison de refuser les optimisations qui nuise à la lisibilité du code. Je réponds : « oui ». Car openBSD est la comme serveur, ce n’est pas un super calculateur numérique.
Quand à ta remarque :
Tu n’as vraiment pas l’air de bosser dans le domaine.
Tu as raison, je ne suis pas mathématicien, je suis spécialisé dans le temps réel aéronautique. Ce qui nous intéresse par exemple, c’est de garantir que l’information du capteur vts, alt soit afficher au pilote en moins de x ms. On s’en fout complètement de rendre l’algo obscure pour donner l’information en x÷5, car le coût induit en test, certification etc. explosera d’un facteur ×ばつ 10 ou plus.
Mon expérience, d’optimisation est là. Quand ça passe pas, il faut trouver une solution. Le plus contraint que j’ai eu à optimiser, c’est sur un calculateur relier à d’autre par 3 bus différents. Où il fallait caler les échanges bus + les calculs en dessous de 1ms. Avec un proc PowerPC en dessous de 1GHz. On a fait des analyses de ce qui passait sur les bus (vive les analyseurs PCI). Quand on a atteint les 987μs, on a fait validé le produit.
[^] # Re: suppressions ?!
Posté par Anthony Jaguenaud . En réponse à la dépêche OpenBSD 5.6. Évalué à 5. Dernière modification le 06 novembre 2014 à 11:41.
On ne parle pas de la même chose. D’un côté vous parlez de calcul scientifique, recherche modification d’algo pour gagner du temps. Quand l’algo est prêt, après plusieurs années de recherche, il est publié, intégré dans une bibliothèque et utilisable.
De l’autre, je parle rationalisation, coût.
Le problème à la base est de savoir si openBSD a raison de refuser les optimisations qui nuise à la lisibilité du code. Je réponds : « oui ». Car openBSD est la comme serveur, ce n’est pas un super calculateur numérique.
Quand à ta remarque :
Tu as raison, je ne suis pas mathématicien, je suis spécialisé dans le temps réel aéronautique. Ce qui nous intéresse par exemple, c’est de garantir que l’information du capteur vts, alt soit afficher au pilote en moins de x ms. On s’en fout complètement de rendre l’algo obscure pour donner l’information en x÷5, car le coût induit en test, certification etc. explosera d’un facteur ×ばつ 10 ou plus.
Mon expérience, d’optimisation est là. Quand ça passe pas, il faut trouver une solution. Le plus contraint que j’ai eu à optimiser, c’est sur un calculateur relier à d’autre par 3 bus différents. Où il fallait caler les échanges bus + les calculs en dessous de 1ms. Avec un proc PowerPC en dessous de 1GHz. On a fait des analyses de ce qui passait sur les bus (vive les analyseurs PCI). Quand on a atteint les 987μs, on a fait validé le produit.