Il faut surtout savoir si une programmation multi-coeur peut potentiellement être intéressante pour la problématique. Utiliser plusieurs cœurs c'est entre autre mettre des lock pour garder l'intégrité de certaines données partagées et ces derniers ont un coût.
Dans le cas de la compression sans perte par exemple, il s'agit de calculer la fréquence des caractères et, dans le cas d'une compression LZ77 (ou dérivé), il s'agit de maintenir un dictionnaire de pattern pour obtenir les distances. L'accès à ces éléments (en écriture principalement) se fait presque à chaque caractère, il s'agirait donc de mettre un lock à chaque fois qu'on lit un caractère. Dans ce contexte, on peut facilement inférer qu'utiliser plusieurs cœurs pour un seul document n'est pas la bonne stratégie - l'idée ensuite qu'on puisse considérer qu'un processus puisse s'occuper de N caractère (et donc locker tout les N caractères) n'est pas envisageable puisque cela invaliderait les distances pour la compression LZ77. On peut toujours trouver des solutions mais qui ne ferait que ralentir l'algorithme en général avec des partages de contexte fastidieux.
Là où l'on peut par contre utiliser le multi-coeur, c'est dès qu'il s'agit de compresser plusieurs documents indépendamment (et de merger ensuite les fréquences obtenues pour générer un arbre de huffman commun) - les distances seront alors limitées au document mais si on se place dans un ratio vitesse/taille, cela reste négligeable.
Se placer dans une problématique multi-coeur de facto n'est pas toujours la bonne solution, il s'agit surtout de cibler le niveau d'atomicité de notre algorithme. Je sais pas si c'est vraiment le bon terme mais dans l'exemple, on peut considérer que chaque document peut être compressé séparément alors qu'on peut difficilement atomiser l'algorithme compressant un document en plusieurs petits algorithmes indépendants. On considère donc l'algorithme comme atomique mais pas ce qu'il compose.
Il est donc normal de voir encore des logiciels mono-coeur car ils seront plus efficaces que si ont se forcé à ce qu'ils utilisent plusieurs cœurs. La problématique reste difficile est elle est au centre de certaines langages hauts niveaux qui souhaiterait abstraire la programmation parallèle. C'est à mettre en opposition au global lock présent dans le garbage collector (comme en Python, JavaScript ou encore OCaml).
Malheureusement, avoir un garbage collector multi-coeur peut amener un coût non négligeable qui pourrait ralentir des programmes mono-coeur (pour assurer la validité des pointeurs entre garbage collector partagé et garbage collector spécifique au cœur utilisé) d'où la réticence de certains développeurs à vouloir absolument intégrer le multi-coeur dans certains langages (comme OCaml). Bien entendu, des efforts sont fait dans le bon sens pour éviter l'overhead imposé.
Tout ça pour dire qu'on aura toujours des programmes mono-coeur :) !
[^] # Re: 2016, la majorité des programmes tournent toujours sur un coeur
Posté par Dinosaure (site web personnel) . En réponse au journal Linux: une décennie de coeurs gaspillés. Évalué à 10.
Il faut surtout savoir si une programmation multi-coeur peut potentiellement être intéressante pour la problématique. Utiliser plusieurs cœurs c'est entre autre mettre des lock pour garder l'intégrité de certaines données partagées et ces derniers ont un coût.
Dans le cas de la compression sans perte par exemple, il s'agit de calculer la fréquence des caractères et, dans le cas d'une compression LZ77 (ou dérivé), il s'agit de maintenir un dictionnaire de pattern pour obtenir les distances. L'accès à ces éléments (en écriture principalement) se fait presque à chaque caractère, il s'agirait donc de mettre un lock à chaque fois qu'on lit un caractère. Dans ce contexte, on peut facilement inférer qu'utiliser plusieurs cœurs pour un seul document n'est pas la bonne stratégie - l'idée ensuite qu'on puisse considérer qu'un processus puisse s'occuper de N caractère (et donc locker tout les N caractères) n'est pas envisageable puisque cela invaliderait les distances pour la compression LZ77. On peut toujours trouver des solutions mais qui ne ferait que ralentir l'algorithme en général avec des partages de contexte fastidieux.
Là où l'on peut par contre utiliser le multi-coeur, c'est dès qu'il s'agit de compresser plusieurs documents indépendamment (et de merger ensuite les fréquences obtenues pour générer un arbre de huffman commun) - les distances seront alors limitées au document mais si on se place dans un ratio vitesse/taille, cela reste négligeable.
Se placer dans une problématique multi-coeur de facto n'est pas toujours la bonne solution, il s'agit surtout de cibler le niveau d'atomicité de notre algorithme. Je sais pas si c'est vraiment le bon terme mais dans l'exemple, on peut considérer que chaque document peut être compressé séparément alors qu'on peut difficilement atomiser l'algorithme compressant un document en plusieurs petits algorithmes indépendants. On considère donc l'algorithme comme atomique mais pas ce qu'il compose.
Il est donc normal de voir encore des logiciels mono-coeur car ils seront plus efficaces que si ont se forcé à ce qu'ils utilisent plusieurs cœurs. La problématique reste difficile est elle est au centre de certaines langages hauts niveaux qui souhaiterait abstraire la programmation parallèle. C'est à mettre en opposition au global lock présent dans le garbage collector (comme en Python, JavaScript ou encore OCaml).
Malheureusement, avoir un garbage collector multi-coeur peut amener un coût non négligeable qui pourrait ralentir des programmes mono-coeur (pour assurer la validité des pointeurs entre garbage collector partagé et garbage collector spécifique au cœur utilisé) d'où la réticence de certains développeurs à vouloir absolument intégrer le multi-coeur dans certains langages (comme OCaml). Bien entendu, des efforts sont fait dans le bon sens pour éviter l'overhead imposé.
Tout ça pour dire qu'on aura toujours des programmes mono-coeur :) !