Un asic de compression d'image sera toujours plus rapide qu'une version soft ou qu'une version FPGA.
Oky, on est d'accord.
Mais il ne te viendrais jamais à l'idée d'essayer de faire rentrer GNU chess dans un asic.
Effectivement : non, à moins d'avoir quelques années devant moi ;-).
Or des téchniques comme celle montrer pourait le faire.
Mais je me pose la question de l'intérêt : je ne suis pas un spécialiste des échecs (loin de là), mais je me doute que les algorithmes qui régissent les stratégies envisageables pour ces derniers sont "réductibles" et "ciblables" par un humain qui analyse son code, et il est éventuellement ensuite possible de les implémenter en les optimisant (toujours avec l'intervention humaine) sur un processeur de calcul dédié, pas forcément "reprogrammable" comme l'est le FPGA.
Certes, l'intérêt du FPGA réside dans le fait qu'on peut, pour GnuChess, y implémenter une fonction de calcul dédiée, et ensuite en implémenter une autre pour, par exemple, le calcul 3D pour un autre jeu, ou ... (encore que je me pose la question de la limite sur un ordinateur à vocation généraliste, et qui plus est : multitâche), mais dans ce cas pourquoi avoir besoin du C ou d'un autre traducteur d'assembleur vers "portes logiques" : on peut très bien imaginer fournir directement le .sof/.pof (je ne connais que les FPGA Altera) en complément du programme en langage machine pour le processeur RISC/CISC central.
Pour moi, l'intérêt du C/ASM->portes logiques réside dans le fait de permettre d'économiser l'apprentissage d'un langage de description matériel du type VHDL/Verilog et des outils associés à ceux/celles qui auraient déjà une maîtrise d'un langage de haut niveau du genre C ("haut niveau" : tout est relatif, mais au niveau matériel, c'est du haut niveau...).
[^] # Re: Benchmarks?
Posté par Sylvain Briole . En réponse au journal Compiler pour un FPGA. Évalué à 2.
Oky, on est d'accord.
Mais il ne te viendrais jamais à l'idée d'essayer de faire rentrer GNU chess dans un asic.
Effectivement : non, à moins d'avoir quelques années devant moi ;-).
Or des téchniques comme celle montrer pourait le faire.
Mais je me pose la question de l'intérêt : je ne suis pas un spécialiste des échecs (loin de là), mais je me doute que les algorithmes qui régissent les stratégies envisageables pour ces derniers sont "réductibles" et "ciblables" par un humain qui analyse son code, et il est éventuellement ensuite possible de les implémenter en les optimisant (toujours avec l'intervention humaine) sur un processeur de calcul dédié, pas forcément "reprogrammable" comme l'est le FPGA.
Certes, l'intérêt du FPGA réside dans le fait qu'on peut, pour GnuChess, y implémenter une fonction de calcul dédiée, et ensuite en implémenter une autre pour, par exemple, le calcul 3D pour un autre jeu, ou ... (encore que je me pose la question de la limite sur un ordinateur à vocation généraliste, et qui plus est : multitâche), mais dans ce cas pourquoi avoir besoin du C ou d'un autre traducteur d'assembleur vers "portes logiques" : on peut très bien imaginer fournir directement le .sof/.pof (je ne connais que les FPGA Altera) en complément du programme en langage machine pour le processeur RISC/CISC central.
Pour moi, l'intérêt du C/ASM->portes logiques réside dans le fait de permettre d'économiser l'apprentissage d'un langage de description matériel du type VHDL/Verilog et des outils associés à ceux/celles qui auraient déjà une maîtrise d'un langage de haut niveau du genre C ("haut niveau" : tout est relatif, mais au niveau matériel, c'est du haut niveau...).