[gull] [SPAM] Re: [SPAM] pour petit serveur économe

Sun Feb 5 16:58:12 CET 2023

Bonjour,
J'ai fait beaucoup de benchmark dans ma vie, depuis 1964, ça fait bientôt
60 ans...
Voici quelques observations générales plus amusantes qu'utiles :
- calcul d'orbites d'étoiles dans un modèle de galaxie. En 1964 il avait
fallu plus de 36 heures pour un calcul. Aujourd'hui je peux en faire 8 en
parallèle en moins de 0.01 seconde, et le prix de l'ordinateur a baissé
pendant ce temps d'un facteur 10^6
- Au début des années 90, j'ai fait quelques comparaisons entre les Vax et
les nouvelles Alpha de DEC, dans des configurations de prix semblables
(~100KFr). Les Alpha étaient environ deux fois plus rapides mais 100 fois
plus lentes pour la compilation de programmes fortran. L'optimisation était
très délicate et prenait un temps fou. Pas terrible dans un
environnement d'enseignement, mais appréciable pour les gros calculs
scientifiques.
- L'automne dernier, je suis tombé sur l'utilisation de l'App RealPi sur
Android pour comparer les téléphones. Pas sûr que ce soit le critère le
plus intelligent... C'est plutôt Pi qui m'intéressait (*). Impressionnant
de calculer 10^8 décimales de Pi en quelques minutes sur un téléphone.
L'App donne le choix entre deux optimisations au niveau de la méthode de
calcul (opérations par transformée de Fourier). J'ai choisi la plus rapide.
Au même moment j'ai découvert l'App termux, qui offre un bel
environnement Linux dans une fenêtre bash, et compilé le programme
chudnovsky.c + libgmp, la bibliothèque multiprécision. Surprise : Sur mon
FairPhone4, le calcul de  10^8 décimales est ~7-8 fois plus rapide qu'avec
RealPi.  Mon PC (i7-9700K CPU @ 3.60GHz), est encore 30 x plus rapide,
alors qu'un RPi400 (RPi4 à 1.8GHz) est lui à peine plus rapide, et mon
ancien PC (i7-3700K @ 3.20GHz) est 6 x plus rapide (mêmes compilateurs,
mêmes mémoires etc).
Finalement, le calcul des décimales de Pi est assez intéressant. Il combine
calcul sur entiers (surtout), flottants, manipule des quantités immenses de
données (plusieurs GO) etc, mais ne représente aucune situation réelle
spécifique.
Bonne fin de journée,     amitiés,     Paul

(*) Les décimales de Pi forment un excellent test pour les programmes de
compression. Si le fichier est compressible, c'est qu'il est faut, à moins
qu'il le réduise à quelque chose comme "Pi avec 10^8 décimales".

Le dim. 5 févr. 2023 à 01:30, Daniel Cordey via gull <
gull at forum.linux-gull.ch> a écrit :

> Ce message est envoyé depuis une adresse e-mail extérieure à l’UNIGE. Ne
> cliquez pas sur les liens/pièces jointes sauf si vous êtes sûr-e de son
> contenu/expéditeur // This message is sent from an e-mail address outside
> the UNIGE. Do not click on links/attachments unless you trust the
> content/sender.
>
>
> ------------------------------------------------------------------------------
>
>
> Le 04.02.23 à 20:23, Philippe Strauss via gull a écrit :
>
> > Dans la même veine mais au sujet des petits SBC ARM, un bon comparatif
> > de la radxa rock pi 5B et du raspberry pi 4:
>
> Intéressant, merci
>
> > Je jalouse un peu les GFLOPS/W des apple M1 et M2 à vrai dire même si je
> > ne vas pas acheter apple désormais après mes expériences avec le chip T2.
>
> Well... Les GFLOPS sont calculés en utilisant le benchmark Linpack, qui
> date quand même pas mal. Ce benchmark a été conçu dans les années 70 et
> ensuite modifier pour tourner en version parallèle. Sauf que... cela
> utilise BLAST qui est une librairie écrite en assembleur, destinées à
> améliorer les performances en utilisant les fonctionnalité de
> vectorisation des CPUs, ce qui fait que ces performances sont très
> spécifiques à un type de calcul et peuvent utiliser les fonctionnalités
> des nouveaux CPU/GPU. Donc, les résultat peuvent être un peu biaisés si
> l'on veut comparer des performances de calcul pour différentes
> situations. Déduire ensuite le GFLOPS/W risque de donner une fausse
> vision de la véritable performance/W du CPU. Sans compter que Linpack va
> principalement tourner dans la cache L1 ou L2 suivant les CPUs...
>
> Il me semble avoir vu d'autres benchmarks de mesure de perf/W pour les
> M1 et M2 et justement ceux-ci n'étaient pas vraiment devant... Raison de
> plus pour prendre les valeurs des GFLOPS/W avec des pincettes. De ce que
> j'ai vu, Apple a conçu ses CPUs pour de la performance avant tout, mais
> pas vraiment pour faire de la basse consommation. Perso, je ne tiens
> plus compte des benchmark utilisant Linpack... depuis 1987 !
>
> Il ne faut pas non plus oublier que les fabricants vont mettre en avant
> les benchmarks qui les mettent en valeur vis à vis de la concurrence.
> C'est une vielle bataille qui existe depuis plus de 40 ans...
>
> Il est souvent difficile de comparer les performances d'un CPU avec un
> autre car certaines familles ont des orientations différentes (serveur
> vs Desktop vs jeux). On peut trouver des suite de benchmarks réalisés
> par différentes personne et elles sont très instructives. En les
> regardant en détails on s'aperçoit peut-être qu'un CPU A va 5 fois plus
> vite que le CPU B sur un benchmark, mais que dans un autre cas il est 5%
> plus lent. Toutefois, ça permet de savoir quel genre d'optimisation a
> été privilégiée par un CPU ou un autre. De plus, les CPUs pour serveurs
> ont des performances qui peuvent fortement dépendre des chipset
> associés, alors qu'une partie des fonctionnalités des chipset se
> trouvent intégrées aux CPU des desktops, mais avec des performances
> moindre et des fonctionnalités en moins (ce qui ne se voit pas forcément
> facilement).
>
> En conclusion, il est très difficile de séparer le bon grain de l'ivraie
> dans le discours des fabricants et le seul benchmark valable est celui
> de votre application ou la mesure de votre usage, associé à une appareil
> de mesure des Watts !
>
> dc
> _______________________________________________
> gull mailing list
> gull at forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://forum.linux-gull.ch/pipermail/gull/attachments/20230205/be3d0b9c/attachment.html>