Rescale propose divers logiciels avec licences à la demande. Ce logiciel est populaire en raison de la nature du paiement au fur et à mesure. Non seulement ce logiciel offre un moyen simple d'accéder au logiciel, mais de nombreux logiciels sont tarifés de telle manière qu'ils encouragent l'exécution sur plus de cœurs et offrent donc un délai d'exécution plus rapide pour trouver une solution.
En ce qui concerne la tarification des logiciels à la demande, la plupart des logiciels se répartissent en 4 catégories générales de tarification horaire :

• Proportionnelle – vous payez proportionnellement au nombre de cœurs que vous utilisez
• Flat Rate – vous payez un forfait horaire, quel que soit le nombre de cœurs que vous utilisez
• Plafonné – vous payez proportionnellement jusqu’à un certain nombre de cœurs et payez ensuite un forfait
• Réductions activées – vous payez un tarif nominal pour le premier cœur et payez moins pour chaque cœur suivant

Il est clair qu'un tarif proportionnel ne profite pas au client lors d'une mise à l'échelle vers de nombreux cœurs. Cependant, les trois autres modèles de tarification peuvent bénéficier au client en exécutant davantage de cœurs. En réalité, l’avantage repose à la fois sur le modèle tarifaire ainsi que sur l’évolutivité du travail et du logiciel. L'évolutivité est l'hypothèse selon laquelle une tâche donnée s'exécutera plus rapidement sur davantage de cœurs.
Ce que j'ai l'intention de montrer dans cet article de blog, c'est que certains modèles de tarification des logiciels offrent la possibilité d'exécuter votre travail plus rapidement et sur plus de cœurs tout en payant moins.
Nomenclature
Il ne s'agit pas d'un article scientifique, cependant, je vais fournir quelques équations pour illustrer certains des concepts liés au prix et à la mise à l'échelle. Pour rendre les équations plus faciles à comprendre, voici quelques définitions

hw	Hardware
I	Nombre d'itérations
k	Une certaine constante par unité
K	Certaines constantes
N	Nombre de cœurs ou de processus
p	Prix ​​unitaire
P	Tarifs et Prix
sw	Logiciels
t	Temps par itération
T	Temps total

Le problème
Un ingénieur possède un modèle et souhaite connaître la manière la plus rentable d’exécuter son modèle sur Rescale. Étant donné que le coût du travail est la somme du coût du matériel et du logiciel, nous devons prendre en compte les modèles de tarification pour chacun. Le coût du matériel est facturé par Rescale sur une base proportionnelle. Le coût du logiciel est déterminé en fonction du modèle tarifaire de l'éditeur de logiciels (ISV). Le prix horaire total ressemblerait à ceci :

P_{la totalité de votre cycle de coaching doit être payée avant votre dernière session.} = P_hw + _sw

Le coût total du travail serait le produit du prix horaire et de la durée du travail. C'est la valeur que nous voulons minimiser.

Coût total = (P_hw + _sw) * Durée totale de simulation

Comme expliqué précédemment, on peut dire que le temps nécessaire à l'exécution du travail et les prix horaires sont fonction du nombre de cœurs utilisés.

P_hw = f(N) = p_hw *N

P_sw = f(N)

T = f(N)

Avec ces informations, nous pouvons désormais tenter d’optimiser le coût de l’ensemble du travail.
Prix ​​du matériel
Le matériel est facturé par Rescale sur une base proportionnelle. Le prix horaire est basé sur un taux horaire par cœur qui diffère selon les différents types de cœurs et plans tarifaires disponibles sur Rescale. En termes simples, l’équation du prix horaire du matériel est le produit du taux horaire par cœur et du nombre de cœurs :

P_hw =p_hw*N

Tarification des logiciels
Les tarifs des logiciels à la demande sont fixés par les éditeurs de logiciels indépendants. Comme indiqué précédemment, il existe plusieurs catégories de prix différentes. Les équations permettant d’obtenir le prix horaire d’un logiciel en fonction du nombre de cœurs sont assez simples :

Proportionnelle	Psw = k * N
Flat Rate	Psw =K
Plafonné	Psw = min(K,k*N)
Réductions activées	Psw = K * f(N) Par exemple : Psw = K * N.9

Temps de simulation et évolutivité du logiciel
Le temps nécessaire pour exécuter une simulation sur N processus/cœurs peut être approximé par l'équation suivante :

T_simulation = T_{en série} (1 / N + k₁ * (N-1)^k2)

Où T_{en série} est le temps nécessaire pour exécuter la simulation en série. La partie bleue décrit le temps de calcul brut tandis que la partie rouge décrit la surcharge de communication. Si la justification vous intéresse, lisez la suite. Sinon, passez à « Costimisation ».
Les détails:
Il existe de nombreuses façons de modéliser l’évolutivité. La loi d'Amdahl est souvent citée comme représentant l'évolutivité par rapport aux différentes parties de la simulation qui bénéficient d'une mise à l'échelle sur des ressources supplémentaires. Il n’aborde cependant pas la manière de définir ou de quantifier les avantages de ressources supplémentaires. Dans notre cas, nous avons un modèle de taille fixe et nous voulons savoir comment il fonctionnera lorsque nous le ferons évoluer sur un nombre croissant de cœurs matériels. Alors, à titre indicatif, faisons quelques hypothèses :

1. La simulation est itérative
2. La simulation est répartie sur N processus sur N cœurs
3. Chaque processus nécessite des informations provenant d'autres processus pour calculer la prochaine itération et utilise MPI
4. Le nombre d'itérations, I, pour terminer la simulation est indépendant de N
5. Le nombre de cycles de calcul requis pour terminer une itération est indépendant de N

Compte tenu de ces hypothèses, le temps nécessaire pour terminer une itération est :

t_itération = t_calcul +t_communiquer

si calculer et communiquer sont des opérations synchrones. Sinon, en les considérant comme des opérations asynchrones (non bloquantes),

t_itération = max(t_calcul, cet _communiquer)

Enfin, le temps de calcul total est facilement calculé à partir du temps d'itération et du nombre d'itérations.

T = t_itération * je ∝t_itération

Ici, nous supposons que chaque itération est plus ou moins égale.
Temps de calcul
Pour temps de calcul, l'hypothèse (5) nous donne

t_calcul = t_{en série} / N

Cela nous indique qu'en l'absence de surcharge de communication, notre modèle aura une forte mise à l'échelle linéaire. Cela nous indique également que plus le modèle est grand (t_{en série}), plus t_calcul et l'effet moins préjudiciable de la surcharge de communication sur le temps de solution relatif en raison de la dominance de t_calcul. Le résultat est que les modèles plus grands évoluent mieux.
Temps de communication
Le le temps de communiquer est plus complexe et dépend, entre autres choses, de la rapidité de l'interconnexion, de la quantité de données à communiquer et du nombre de processus N.
Simplifions et décomposons.
Le temps de communication entre deux processus peut être défini en 2 parties : la surcharge de communication (latence) et le temps de transfert des données (transférer). Ainsi, pour envoyer un message d'un processus à un autre, nous pouvons pour l'instant simplement définir :

t_message = t_latence +t_transférer = t_latence + (taux de transfert * taille du message)

Le taux de transfert est plus faible pour les petits messages et augmente à mesure que les messages deviennent plus gros, atteignant un maximum à la bande passante de l'interconnexion. On peut supposer pour l’instant que la latence est constante pour une interconnexion donnée.
Pour voir l'effet dans la pratique, cet article (https://mvapich.cse.ohio-state.edu/static/media/publications/abstract/liuj-sc03.pdf) étudie les performances de MPI sur diverses interconnexions. Ce que montre l’article, c’est que pour les messages de petite taille, le temps de communication est plus ou moins constant.

t_message ≅k

Avec cette connaissance, nous pouvons déduire que le temps total de communication dépend du nombre de messages envoyés par chaque processus. Le nombre de messages envoyés dépend du nombre de processus car, vraisemblablement, chaque processus communique avec tous les autres processus. Une équation qui peut ensuite être utilisée pour modéliser le nombre de messages envoyés est :

Messages = k₁ * (N-1)^k2 ∝t_message

De plus, nous pouvons normaliser k₁ par le nombre d'itérations et donc t_{en série}

t_communiquer = t_{en série} *k₁ * (N-1)^k2 ∝t_message

Mettre ensemble
La durée totale de la simulation est

T_simulation ∝t_itération = t_calcul +t_communiquer

lorsque le calcul et la communication sont des opérations synchrones (bloquantes). Par substitution,

T_simulation = T_{en série} (1 / N + k₁ * (N-1)^k2)

Obtention des constantes
Les constantes peuvent être obtenues en ajustant l’équation à des données de référence empiriques. Le modèle de surcharge de communication présenté ici n’est en aucun cas une solution miracle. Il a été démontré à partir de nos tests de référence internes que cette équation s'adapte bien à presque tous les nombres d'échelle.
De plus, nous avons constaté que k₂ ≅0.5. Nous avons également constaté que k₁ est fonction de la taille du modèle, du type d'interconnexion et des performances du processeur.
Costimisation
Revenons à notre équation du coût total :

Coût total = (P_hw + _sw) *T_simulation

Le coût total dépend désormais du modèle de tarification du logiciel utilisé.

Coût total = f(N) = (p_hw *N+P_sw) *T_{en série} (1 / N + k₁ * (N-1)^k2)

Une calculatrice Excel peut être trouvée ici [lien]. Voici un exemple de sortie :

Comment pouvons-nous aider
L'équipe d'assistance de Rescale peut vous aider à estimer le nombre approprié de cœurs sur lesquels exécuter votre simulation. Il n'est pas toujours possible d'exécuter des tests de performance pour chaque cas d'utilisation, et d'après l'exemple ci-dessus, le fait de ne disposer que de quelques cœurs n'a pas un impact énorme sur les coûts que vous économisez.
Ce dont nous voulons que vous soyez conscient, c'est qu'avec un bon logiciel de mise à l'échelle et un forfait or plafonné modèle tarifaire il est souvent plus rentable de fonctionner sur plus de cœurs.