Follow

hum, pour avoir un internet qui soit efficient, ça veut dire plusieurs choses, et pitié, me ressortez pas les stats de Bortz qui dit qui faut juste tout écrire en C (comme ses CSS)

il va falloir des serveurs qui se comportent comme des laptops, avec fréquence variables, mises en veille profonde, possibilité de couper le DD. Ca va juste exploser la notion de benchmark.

Ca veut dire un ensemble de serveurs, sur un pattern "la tête et les jambes", genre un ARM en front, qui fout rien, genre, il sert du cache, réponds au DNS, empile des mails sans les lire, il est up tout le temps, mais n'a aucune puissance, et consomme peu

Ensuite, il y a les jambes, un serveur qui va mouliner, qui va dépiler des taches, compiler des réponses et les écrire ailleurs. A priori, il va tourner pendant les heures ouvrées, faire sa pause médiane

donc, on oublie le PHP et compagnie, qui pourra servir pour faire le CMS, mais il n'interagirera pas avec les utilisateurs.

Pour les dbs, si le disque consomme moins que le CPU, les données seront dénormalisés.
On écrit dans un gros tas (du rockdb?, du S3?), un batch profite que le serveur puissant est allumé pour consolider les informations et écrire des index qui prennent plein de place.

ça sera rentable de profiter de la densité des monstres de maintenant, des 28 coeurs avec genre 1To de RAM, et donc arriver à le mutualiser sans trop de risque de sécu. Ca veut dire des batchs avec des fils d'attente, voir des enchères, avec du kernel less, des micro vm, voir du wasm. Un peu comme une laverie pour un étudiant, ça coute moins cher que posséder sa propre machine à laver.

Pour le serveur frontale, on oublie les merdes synchrones, avec la fête à la RAM et le stockage hyper véloce, personne ne doit bloquer le CPU, de toutes façon, la réponse est soit dans un index, soit dans un fichier.

Pour le serveur qui bosse, on peut imaginer des enchères, soit on allume le serveur quand le courant est moins cher (disponible, pour une énergie intermittente), soit moins utilisé (façon heure creuse), si on n'a pas trop besoin d'interaction.

@athoune Et des serveurs qui soit pas des IBM PC plus ou moins compatibles aussi…

@lanodan pour la partie "grosse patate", ça me semble difficilement évitable, quand on voit les difficulté d'AMD à ajouter des instructions, ou même trouver des applis qui utilisent des MMX récents (hors lecteur vidéo). Scaleway est allé s'humilier avec des PowerPC IBM.

Le seul critère qui vaut, c'est le nombre de watt pour un service rendu, et là, ARM peut occuper des niches. Des grosses niches.

@athoune Et ARM n'est pas du x86 donc on est d'accord, par contre je me demande si ça va vraiment fonctionner pour du serveur à la longue.
Mais Power9 et RISC-V je me demande ce que ça va devenir, surtout que je pense que sparc est mort pour le futur/présent alors que ça à occupé pas mal de place.

@lanodan tu vas avoir un peu de spécialisation, genre des serveurs qui vont être devant, des routeurs qui font trop de truc, quoi (TLS, LB, firewall). Des filers avec plein de core pour gérer plein de disques.

Mais sinon, déjà qu'avec LLVM c'est dur d'avoir toutes les optimisations des procs, avec des golang, java, V8 qui font les fous en assembleurs, je ne le sens pas du tout.

@athoune LLVM au moins permet de potentiellement utiliser ses optimisations de manière assez flexible, mais c'est sur que si ça fait son truc dans son coin ça va être dur d'être optimisé.

@lanodan une partie des instructions MMX ne sont pas implicite, il n'est pas possible d'analyser du C et dire, paf, là, je colle du MMX ça boostera, il faut coder des bouts de libs en assembleurs. Ca se fait dans le monde de numpy et du calcul scientifique, ou par des employés d'Intel, genre leur lib pour faire des regex. Et souvent, ces libs n'ont pas de fallback pour le reste du monde, ou alors avec des perfs de merde.

On est encore dans le dilemme RISC vs CISC.

@lanodan Des produits comme HouseClick ont des perfs de folie par ce qu'ils utilisent des instructions spécifiques pour vectoriser des calculs, ce n'est clairement pas portable.

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!