Si vous cherchez une solution à la "chinoise" avec un gros copro qui sait faire du calcul matriciel, c'est puissant, mais cela nécessite du code réécrit. Et un serveur est loin de faire beaucoup de calcul pure.
En cherchant une autre balance cpu/perf, cela pourrait fonctionner, comme avoir beaucoup de bandes passantes par cpu (remplacer qq Mo de cache par un port DDR 256 bits comme la PS4 au lieu de 128). Et pourquoi pas pouvoir mettre plusieurs ordinateurs sur le même PCB, relié entre eux par un bridge qui pourrait être vu comme une carte réseau par linux. Ce genre de config pourrait être bien quand il y a des dizaines de GO de mémoire (un cache de 16 Mo devenant moins intéressant avec l'augmentation de la taille mémoire).
Je crois aussi beaucoup à des instructions spécifiques pour ce qui prend du temps : compression gzip, crypto, hash,... Je parle bien d'instructions et non de coprocesseurs qui ne sont jamais assez flexible et qui sont "long à lancer" (écriture sur les registres, etc...). Pour supporter ce gens d'instruction, il "suffit" de porter la lib openSSL qui gère la crypto et la libgzip.
Concernant les mémoires rapides spécifiques, les problèmes sont souvent les mêmes : latence identique à la DDR, taille réduite, et prix élevé.
[^] # Re: Open Hardware
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Et si on achetait de l'Open Hardware (v2) ?. Évalué à 2.
Si vous cherchez une solution à la "chinoise" avec un gros copro qui sait faire du calcul matriciel, c'est puissant, mais cela nécessite du code réécrit. Et un serveur est loin de faire beaucoup de calcul pure.
En cherchant une autre balance cpu/perf, cela pourrait fonctionner, comme avoir beaucoup de bandes passantes par cpu (remplacer qq Mo de cache par un port DDR 256 bits comme la PS4 au lieu de 128). Et pourquoi pas pouvoir mettre plusieurs ordinateurs sur le même PCB, relié entre eux par un bridge qui pourrait être vu comme une carte réseau par linux. Ce genre de config pourrait être bien quand il y a des dizaines de GO de mémoire (un cache de 16 Mo devenant moins intéressant avec l'augmentation de la taille mémoire).
Je crois aussi beaucoup à des instructions spécifiques pour ce qui prend du temps : compression gzip, crypto, hash,... Je parle bien d'instructions et non de coprocesseurs qui ne sont jamais assez flexible et qui sont "long à lancer" (écriture sur les registres, etc...). Pour supporter ce gens d'instruction, il "suffit" de porter la lib openSSL qui gère la crypto et la libgzip.
Concernant les mémoires rapides spécifiques, les problèmes sont souvent les mêmes : latence identique à la DDR, taille réduite, et prix élevé.
"La première sécurité est la liberté"