Vous n'êtes pas identifié(e).
Pages : 1
Salut tout le monde,
J'ai eu pas mal de soucis de temps de calcul cet été, en travaillant sur l'indexation via PostgreSQL de 200.000 résumés d'articles scientifiques. J'ai pu réduire la tâche à quelques heures en découpant ma requête en plusieurs processus parallèles (je travaille avec un intel core i7) entre autres, mais je me demande s'il ne serait pas possible d'optimiser un peu le code de PostgreSQL pour les processeurs qui acceptent les instructions SSE4.2.
Notamment, le source du LIKE semble ignorer la bibliothèque glibc alors qu'elle contient une version SSE4.2 de strstr()...
http://doxygen.postgresql.org/like__mat … ource.html
Je me pencherais bien volontiers sur ce morceau de code, mais n'ayant pas une grande expérience du travail sur les sources de postgreSQL, j'ai un peu peur de passer à coté d'une objection majeure... Qu'en pensez-vous ?
Hors ligne
L'objection majeure est qu'on veut du code portable. Or la glib n'est pas utilisée sur toutes les plateformes. Donc ce serait une optimisation qui ne concernerait que la glibc sur des processeurs acceptant les instructions SSE4.1. Il faudrait vraiment que l'amélioration en performance soit très importante pour qu'un tel patch puisse passer.
De plus, pour de vrais articles (par exemple, ce que vous avez), on a plutôt tendance à utiliser maintenant la recherche plein texte que la recherche LIKE.
Je ne sais pas exactement quelle recherche vous essayez d'effectuer pour vos articles mais je vous conseille de vous renseigner, si ce n'est pas déjà fait, sur la recherche plein texte. http://docs.postgresql.fr/9.0/textsearch.html et http://www.dalibo.org/glmf111_recherche … postgresql seraient un bon début.
Guillaume.
Hors ligne
Le traitement des chaînes en parallèle par les instructions SSE4.2 peut permettre de réduire le temps CPU par 6 dans certains cas. Ceci dit je comprend très bien vos objections et je vais effectivement lire avec attention les pages que vous mentionnez.
Merci beaucoup pour cette réponse très utile.
Hors ligne
Il y a aussi des réflexions dans cette direction (SSE 4.2) pour le calcul de checksum (CRC32). Mais c'est vrai que la plupart du temps, les développeurs de PostgreSQL cherchent à limiter le code spécifique à chaque plateforme.
Pour un gain potentiel d'un facteur 6, néanmoins, celà pourrait être intéressant. Vous pouvez effectivement vous pencher sur ce bout de code, et avoir une maquette permettant d'évaluer le gain attendu. Si le gain est effectivement très grand, vous aurez davantage de chance d'être ensuite entendu sur la mailing list hackers. En tout cas beaucoup plus qu'en leur demandant de faire eux même le boulot 
Marc.
Hors ligne
Pages : 1
