Bah on peut compter sur les gens qui ne s'y connaissent pas trop qui installeront quand même une version instable

Pour ne plus releaser du tout, +1
sauf que niveau marketing c'est moyen pour eux :/

Marketing de quoi ? Ils ne sont pas censés faire de profit à la base. Et puis à part faire couler de l'encre, c'est pas franchement positif le bilan des releases d'ubuntu.

"sauf que niveau marketing c'est moyen pour eux :/ "

Surtout si il faut modifier le sources.list tous les mois...

En dehors de cela, ça ne va pas changer grand chose pour beaucoup d'Ubuntu-istes qui ne font pas les mises à jour et qui tournent encore sous Ubuntu 9.04.

Les chiffres qui montent vite ça montre que le projet est bien vivant et que ça amène constamment de la nouveauté, ça a un effet rassurant

Gabriel ils seront sans doute assez intelligents pour que ça soit transparent
du coup je viens de penser au fait qu'on doivent le faire, des gens ont vraiment besoin de rester sur "d'anciennes" versions ?

Sauf que nous on veut un truc qui marche, pas un truc qui est vivant.

Quand aux gens qui restent sur d'anciennes versions, on ne peut vraiment rien pour eux si ce n'est arrêter de releaser justement.

| gabriel_knight
| 12 septembre 2011 à 15:30:57
| Regarde la page précédente de ce topic.

Ah j'avais pô vu désolé

Non mais c'est clair qu'autant ne plus releaser du tout, au lieu de faire un cycle court de 6 mois il pourrait faire des cycles d'un ans pour laisser le temps aux devs de faire un boulot décent.

En suivant le même raisonnement que dans un de mes postes précédents, on arrive à la même conclusion : ça ne servirait à rien.

Le problème n'est pas dans le processus de release de toute façon.

S'pas faux.

Il y a des gens qui vendent du rêve

http://www.pebkac.fr/pebkac-4084.html

Amusant, OpenBSD fait des releases tous les six mois depuis 1996 avec un succès toujours présent.

J'ai une question générale pour ceux qui savent ce qu'apporte l'hyperthreading. Par exemple, quand je lance des simulations sur mon ordinateur, c'est mieux avec ou sans?

J'ai trouvé ce benchmark : http://heuristically.wordpress.com/2011/06/27/benchmarking-r-revolution-r-and-hyperthreading-for-data-mining/

Ce comparatif a réduit mes pensées en bouillie; il est dit qu'avec ou sans hyperthreading, le temps d'exécution est le même. Alors que moi j'ai tendance à penser le contraire. Comment comprenez-vous ça?

this is often faster for multi-threaded apps, but the data mining algorithms I run are single threaded

Ça suffit à expliquer pourquoi, l'HT ne permet que des gains _théoriques_ sur des applications multi thread/processus. En général je le désactive : les gains ne sont pas toujours au rendez vous, ça pollue les caches et génère du scheduling pour rien (et je ne parle même pas des attaques permettant de chopper le contenu du cache d'autres applis). Mieux vaut un vrai CPU.

OK on est d'accord.

4223161584: une simulation de quoi ? (tout est dans cette question)

Dargor: je ne sais pas sous OpenBSD, mais avec linux en 2004/2005 l'HT m'évitait de gros ralentissement du système quand un flot d'exécution se mettait à réclamer toutes les ressources de ma machine. Après, c'était sur une machine qui n'avait qu'un coeur... le couplage multicore + hyperthreading est sans doute plus discutable.

J'ai pas dit qu'il était totalement inutile, hein Mais à l'ère du multicoeur physique, il est devenu obsolète.

Plusieurs types de simulations : c'est essentiellement du calcul matriciel avec BLAS, traitement de 500 Go de donnés avec R, des transformées de Fourier dans tous les sens (FFTW), etc, etc,... C'est du calcul assez lourd malheureusement.

Le tout est parallélisé correctement avec OpenMP, et MPI. Sur mon ordinateur personnel, j'ai désactivé l'hyperthreading en pensant que c'était une bonne chose. Je pense faire des tests plus approfondies pour voir la différence.

Oui, le seul moyen de voir si tu y gagnes ou non, c'est de bencher (sur une étoile ou sur un oreiller...).

4223161584: comme l'a souligné plus explicitement dargor, il faut garder à l'esprit que l'HT est une technologie qui a été introduite (sur les machines grand public) avant le multicoeur. Maintenant qu'on dispose de vraies machines parallèles (avec plusieurs vrais CPU), l'intérêt premier de l'HT est fortement diminué.

Oula, j'ai fait plein de test d'hyper threading et avec des machines a 4 voies. Et la question est complique; mais globalement ca depend de ce que tu fais. Globalement:
-si tu utilises des processus -> n'utilises pas l'hyperthread
-si tu utilises des threads. Si ton application est gourmand en calcul (lire, le nombre d'instructions qui passe par l'ALU ou par le FPU est proche du pic theorique), n'utilise pas d'hyperthreads. Si ton application est limite par la bande passante memoire <-> core, essaye l'hyperthreading.

Si tu n'as aucune idee, n'utilises pas l'hyperthreading.

Si pour des raisons obscure, tu as besoin de threads auxiliare a ton application (pour gerer des communications avec un disque dur ou des machines exterieur), l'hyperthreading peut aider egalement.

Dans les choses qui aident beaucoup, il y a le thread pinning et le memory pinning. Si tu fais des calculs, avoir un vrai compilateur (genre pas gcc), ca aide pas mal souvent...

Merci pour ces détails, j'avais un doute sur les processus