Concours national de modélisation mathématique pour diplômés 2022, Coupe Huawei
Question D : problème de disposition des ressources des puces de l'architecture PISA
Titre original reproduit :
1. Introduction générale
Les puces constituent le fondement de l'industrie électronique. Dans la situation internationale actuelle de plus en plus complexe, les puces sont devenues une technologie de haute technologie pour laquelle tous les grands pays doivent rivaliser. Ce sujet se concentre sur les puces de commutation dans le domaine des communications réseau. Les puces de commutation traditionnelles ont des fonctions fixes. Lorsque de nouveaux protocoles réseau apparaissent, les puces doivent être repensées. Il faut souvent plusieurs années entre la conception des puces et leur utilisation. Par conséquent, les puces de commutation à fonction fixe Cela réduit considérablement l'efficacité de la recherche et du développement. Afin de résoudre ce problème, des puces de commutation programmables sont nées. PISA (Protocol Independent Switch Architecture) est l'une des architectures de puces de commutation programmables actuelles. Elle a un taux de traitement comparable à celui des puces de commutation à fonction fixe, tout en étant également programmable. Elle a de larges scénarios d'application dans les futurs réseaux [1 -2 ].
Avant d'expliquer plus en détail l'architecture PISA, nous clarifions d'abord quelques concepts de base :
1. Message : Un message est un paquet de données transmis dans une communication réseau. Dans une communication réseau, les données transmises par l'utilisateur sont encapsulées dans des paquets de données de transmission.
2. Bloc de base : Un bloc de base est un fragment de programme du programme source. La division du programme source en blocs de base divisera le programme source en blocs de base. La manière de diviser les blocs de base est également une question qui mérite d’être discutée, mais elle dépasse la portée de cette question et ne sera pas développée ici.
3. Pipeline : Le pipeline est composé d'une série d'unités de traitement connectées en série. Le message passe successivement par chaque unité de traitement dans le pipeline et est finalement traité. Chaque étape du pipeline fait référence à chaque unité de traitement du pipeline.
L'architecture PISA est illustrée dans la figure 1, qui comprend trois composants : l'analyse des messages (analyseur), le pipeline de traitement des messages multi-niveaux (Pipeline Pocket Process) et le réassemblage des messages (Deparser). L'analyse des messages est utilisée pour identifier les types de messages ; des pipelines de traitement de messages à plusieurs niveaux sont utilisés pour modifier les données des messages. Dans les puces d'architecture PISA réelles, différents niveaux de pipeline de puces peuvent être différents ; le réassemblage des messages est utilisé pour réassembler. Cette rubrique se concentre uniquement sur la partie pipeline de traitement des messages à plusieurs étapes. Dans le modèle de programmation de l'architecture PISA, l'utilisateur utilise le langage P4 pour décrire le comportement de traitement des messages afin d'obtenir le programme P4, puis le compilateur compile le programme P4 pour générer du code machine pouvant être exécuté sur la puce. Lorsque le compilateur compile un programme P4, il divise d'abord le programme P4 en une série de blocs de base, puis organise chaque bloc de base en différents niveaux du pipeline. Puisque chaque bloc de base occupe une certaine quantité de ressources de puce, disposer les blocs de base à tous les niveaux du pipeline signifie disposer les ressources de chaque bloc de base à chaque niveau du pipeline (c'est-à-dire qu'il est nécessaire de déterminer quelle partie du pipeline chaque bloc de base est disposé à un niveau), nous appelons donc le problème de disposition des blocs de base le problème de disposition des ressources des puces de l'architecture PISA. Dans la conception même des puces de l'architecture PISA, afin de réduire la complexité du câblage, il existe souvent diverses contraintes sur les ressources à chaque niveau du pipeline et sur les ressources entre les niveaux du pipeline. Cette série de contraintes de ressources complexes rend le problème d’allocation des ressources particulièrement difficile. Cependant, tous les types de ressources de la puce sont limités. Une utilisation plus élevée des ressources signifie que la puce peut mieux utiliser les capacités de la puce et prendre en charge davantage de services. Par conséquent, les algorithmes d'arrangement des ressources avec une utilisation élevée des ressources sont importants pour la conception du compilateur.
3. Description des données d'entrée
Les données d'entrée contiennent trois pièces jointes, qui fournissent respectivement l'utilisation des ressources de chaque bloc de base, les informations variables lues et écrites par chaque bloc de base et les blocs de base adjacents de chaque bloc de base dans le graphe de flux. de chaque pièce jointe est la suivante : (1) attachment1.csv : la première colonne du
tableau d'informations sur les ressources utilisée par chaque bloc de base est le numéro du bloc de base, et la deuxième à la cinquième colonne sont les numéros des quatre types de ressources utilisés par
chaque bloc de base. Les ressources sont divisées en quatre types au total (TCAM, HASH, ALU, QUALIFY). Par exemple, comme le montre le tableau ci-dessus, le bloc de base n ° 0 doit occuper 2 ressources ALU, et le bloc de base Le n°4 doit occuper 10 ressources ALU et 3 ressources Qualifiées.
(2) attachment2.csv : la première colonne du tableau d'informations variables pour la lecture et l'écriture de chaque bloc de base
indique le numéro du bloc de base, "W" dans la deuxième colonne indique l'écriture, "R" indique la lecture et les colonnes suivantes indiquent l'écriture. ou lecture de ce bloc de base.variables, lorsqu'une ligne ne contient aucun élément de la troisième colonne et des colonnes suivantes, cela signifie que le bloc de base avec ce numéro n'écrit (ni ne lit) aucune variable (à ce moment, le bloc de base (le bloc est simplement utilisé comme bloc de base intermédiaire reliant d'autres blocs de base, sans effectuer de calculs). Par exemple : Le bloc de base n°0 écrit les variables X0 et X1, mais ne lit aucune variable. Le bloc de base n°1 n'écrit ni ne lit aucune variable.
(3) attachment3.csv : la première colonne de chaque bloc de base dans le tableau d'informations sur les blocs de base adjacents dans l'organigramme
est le numéro du bloc de base, et les colonnes suivantes sont les numéros de bloc de base adjacents au bloc de base actuel dans l'organigramme. , c'est-à-dire que dans l'organigramme (comme le montre l'image de gauche de la figure 2), il existe une connexion de bord dirigée entre ce bloc de base et les blocs de base des colonnes suivantes. Par exemple, à partir de la première ligne du tableau ci-dessus, nous pouvons voir qu'il existe des connexions de bord dirigées entre le bloc de base n° 0, le bloc de base n° 1 et le bloc de base n° 2 (c'est-à-dire après l'exécution du bloc de base N° 0, vous pouvez passer au bloc de base n° 1 ou au bloc de base n° 2. Le bloc de base n° 2 est exécuté.) À partir de la troisième ligne, nous pouvons voir qu'il n'y a pas d'arête à partir du bloc de base n° 2 ( c'est-à-dire que le programme se termine après l'exécution du bloc de base 2 et ne passera pas à d'autres blocs de base pour l'exécution). Grâce à ce fichier, vous pouvez déterminer l'ordre d'exécution des blocs de base dans le programme source, déterminer le bloc de base de destination vers lequel accéder après l'exécution de chaque bloc de base, puis créer un organigramme des blocs de base.
4. Problèmes
Ce sujet nécessite d'établir un modèle mathématique pour les problèmes d'agencement des ressources et, sur cette base, de traiter les deux problèmes suivants.
Question 1 : Les contraintes de ressources données sont les suivantes :
(1) Le nombre maximum de ressources TCAM à chaque niveau du pipeline est de 1 ;
(2) Le nombre maximum de ressources HASH à chaque niveau du pipeline est de 2 ;
(3) Le nombre maximum de ressources ALU à chaque niveau du pipeline est de 56 ;
( 4) Le nombre maximum de ressources QUALIFY pour chaque niveau du pipeline est de 64 ;
(5) Il est convenu que les niveaux 0 et 16, les niveaux 1 et 17, ..., les niveaux 15 et 31 du pipeline sont des niveaux pliés, et les deux pliés Le nombre total maximum de ressources TCAM de niveau est de 1 et le nombre total maximum de ressources HASH est de 3. Remarque : Si le nombre requis d'étapes du pipeline dépasse 32, les étapes à partir de la 32e ne prendront pas en compte la limite de ressources de repli ; (6
) Le nombre d'étapes paires avec des ressources TCAM ne dépasse pas 5 ;
(7) Chaque Le bloc de base ne peut être classé que distribué au niveau un.
Les ressources sont organisées selon les contraintes de ressources ci-dessus, et l'objectif d'optimisation est de réduire autant que possible le nombre d'étages de pipeline occupés. Veuillez donner l'algorithme de disposition des ressources et afficher le résultat de la disposition des blocs de base. Le format du résultat de sortie est le suivant :
Question 2 : Considérez le graphique de flux comme le montre la figure 3. Le bloc de base 2 et le bloc de base 3 ne sont pas sur le même flux d'exécution (car après l'exécution du bloc de base 1, soit le bloc de base 2, soit le bloc de base 3 est exécuté, et le bloc de base 2 et le bloc de base 3 sont exécutés. Les blocs 3 ne peuvent pas tous être exécutés). Pour être précis, dans l'organigramme du programme P4, si un bloc de base peut atteindre un autre bloc de base, alors les deux blocs de base sont sur le même flux d'exécution, et vice versa ne sont pas sur le même flux d'exécution. Pour ce type de bloc de base qui n'est pas sur le même processus d'exécution, les ressources HASH et les ressources ALU peuvent être partagées. Les ressources HASH et les ressources ALU de l'un quelconque des blocs de base 2 et 3 ne dépassent pas la limite de ressources de chaque niveau. les blocs 2 et 3 peuvent être disposés au même niveau. Sur cette base, les modifications suivantes sont apportées aux contraintes (2), (3) et (5) de la question 1 :
(2) La somme des ressources HASH des blocs de base sur le même processus d'exécution à chaque étape de le pipeline est au maximum de 2 ;
(3) La somme maximale des ressources ALU des blocs de base sur le même processus d'exécution dans chaque niveau du pipeline est de 56 ; (
5) Pour les deux niveaux repliés, les contraintes de ressources TCAM restent inchangées, et pour les ressources HASH, chaque niveau calcule séparément le même processus d'exécution. Les ressources HASH occupées par les blocs de base ci-dessus sont ensuite additionnées aux résultats de calcul des deux niveaux, et le résultat ne dépasse pas 3.
Les autres contraintes sont les mêmes que celles de la question 1. Après avoir modifié les contraintes de ressources, reconsidérez la question 1, donnez l'algorithme d'arrangement et affichez les résultats de base de l'arrangement des blocs. Le format de sortie est le même que celui de la question 1.
Aperçu du processus global de résolution (résumé)
Alors que la pénurie mondiale « de base » continue de fermenter, la technologie des puces en tant que « nourriture industrielle » est devenue l'une des industries de mon pays qui doit de toute urgence percer. En tant qu'architecture de puce de commutation dotée d'une bonne vitesse de traitement et d'une bonne programmabilité, PISA atténue efficacement le problème de la faible efficacité de R&D des puces de commutation traditionnelles à fonction fixe. Afin de tirer pleinement parti des capacités des puces, la sélection d'algorithmes d'agencement des ressources des puces avec une utilisation élevée des ressources est particulièrement importante. Compte tenu de cela, cet article décompose le problème complexe d'arrangement de base des ressources en blocs en plusieurs sous-problèmes, combine diverses contraintes et le résout progressivement en établissant un modèle de programmation d'objectifs et un modèle d'arrangement de base en blocs, puis conçoit des règles heuristiques pour évaluer le résultats de la solution. Optimiser et enfin utiliser les étapes de pipeline les plus courtes possibles comme solution au problème.
Concernant le premier problème, cet article le divise en deux sous-problèmes : l'analyse des dépendances et la disposition des ressources des blocs de base. Pour le sous-problème 1, les données attachment3.csv sont analysées et traitées pour obtenir le graphe de flux de contrôle CFG et l'arbre dominant avant FDT du graphe de flux de contrôle. La différence entre CFG et FDT est la dépendance de contrôle du bloc de base. Deuxièmement, lisez la relation lecture-écriture des blocs de base dans attachment2.csv et utilisez l'algorithme de recherche en largeur BFS pour déterminer la connectivité entre les blocs de base afin de déterminer la dépendance des données. La relation de dépendance complète est obtenue par l'union de la relation de dépendance de contrôle et de la relation de dépendance de données. Pour le sous-problème 2, la relation de dépendance complétée est résumée dans un graphe acyclique dirigé pondéré, et la relation hiérarchique des blocs de base disposés dans le pipeline est initialement déterminée. Ensuite, dans le but principal d'occuper le nombre le plus court possible d'étapes du pipeline, un modèle de planification d'objectifs a été établi sur la base des exigences de base en ressources de bloc dans attachment1.csv et des contraintes de ressources données. Pour résoudre le modèle, un modèle d'agencement de blocs de base est conçu. Basé sur le principe de l'agencement en série, les blocs de base sont sélectionnés parmi les blocs de base sans dépendances préalables selon des règles aléatoires et placés dans la première étape du pipeline qui peut être placée jusqu'à ce que tous les éléments soient placés. les blocs de base sont terminés. La question 1 montre que le nombre d’étages occupés du pipeline est de 40.
Concernant la deuxième question, puisque les blocs de base qui ne sont pas sur un seul processus d'exécution peuvent partager des ressources HASH et des ressources ALU, nous introduisons le concept de blocs de base qui ne sont pas sur un seul processus d'exécution basé sur la première question, ce qui atténue le problème du HASH et de l'ALU dans Question 1. Problèmes d’occupation. Cet article décompose le problème 2 en deux sous-problèmes : déterminer si deux blocs de base sont dans le même processus d'exécution et organiser les ressources des blocs de base. Pour le sous-problème 1, selon l'organigramme du programme, l'algorithme de recherche en largeur d'abord est utilisé pour déterminer si deux blocs de base sont sur le même processus d'exécution, c'est-à-dire si partir d'un bloc de base peut atteindre un autre bloc de base, et obtenir la matrice de symétrie des relations du processus d'exécution des blocs de base. Pour la deuxième question, l'objectif principal est d'occuper le plus petit nombre possible d'étapes du pipeline. Combiné à la condition que les blocs de base qui ne sont pas sur le même processus d'exécution puissent partager les ressources HASH et ALU et les trois contraintes modifiées, un objectif similaire à la question un modèle de planification est établi. Lors de la résolution, pour les pipelines avec de nouveaux arrangements de blocs de base, les besoins en ressources pour HASH et ALU des blocs de base dans différents flux de contrôle dans ce niveau de pipeline sont combinés. La question 2 montre que le nombre d'étages occupés par le pipeline est de 34.
L'optimisation de la solution prend en compte l'instabilité de la sélection aléatoire des règles et optimise les règles de base de sélection des blocs. Cet article construit 6 heuristiques, dont l'heure de début la plus précoce EST, le bloc de ressources le plus suivant MST, l'heure de démarrage la plus précoce et le bloc de ressources le plus suivant EST_MST. Règles de formule et sélectionnez les blocs de base à ajouter au pipeline en fonction de règles heuristiques. Cet article combine les résultats optimaux de la résolution de 10 règles aléatoires et de 6 règles heuristiques comme plan final de disposition du pipeline. Après optimisation, le nombre d'étages occupés du pipeline en question 1 est de 40. La question 2 montre que le nombre d'étages occupés par le pipeline est de 34. Enfin, cet article a révélé que le goulot d'étranglement des performances du problème 1 réside dans les ressources HASH et que le goulot d'étranglement des performances du problème 2 réside dans les ressources TCAM. En considérant de manière exhaustive les dépendances de contrôle, les dépendances de données et les contraintes de ressources de tous les niveaux de pipelines, l'efficacité et l'universalité de la solution proposée sont prouvées. Les avantages et les inconvénients de l'algorithme et du modèle proposés sont résumés et des travaux de recherche futurs sont prospectés.
Hypothèses du modèle :
[1] On suppose que les scénarios expérimentaux sont tous dans un état idéal et ne sont pas affectés par des facteurs tels que la température et l'électromagnétisme.
[2] On suppose qu'il n'y a pas d'erreurs causées par des pannes de puces au cours de l'expérience.
[3] Supposons que nous nous concentrions uniquement sur la partie pipeline de traitement des messages à plusieurs étapes de la puce de l'architecture PISA.
[4] Supposons que les conditions pour chaque niveau du pipeline soient les mêmes, à l'exception des contraintes de ressources indiquées dans la question.
[5] Supposons qu’il n’y ait pas de limite supérieure au nombre d’étages de pipeline pouvant être aménagés.
[6] On suppose que le processus d’ensemencement de nombres aléatoires dans un modèle aléatoire est complètement aléatoire.
analyse du problème:
Analyse du premier problème :
La question 1 nécessite de considérer les dépendances de données et de contrôle entre les blocs de base, et de combiner les contraintes de ressources données pour réaliser l'agencement et l'optimisation des ressources des blocs de base afin de rendre le nombre d'étages de pipeline occupés aussi court que possible afin de maximiser les ressources de la puce. .
La question donne attachment1.csv, attachment2.csv et attachment3.csv. Les trois pièces jointes sont les informations sur les ressources utilisées par chaque bloc de base, les informations variables lues et écrites par chaque bloc de base et les informations de bloc de base adjacentes de chaque bloc de base. dans l'organigramme.
Grâce à l'analyse de la question, nous avons conclu que cette question peut être décomposée en trois sous-problèmes suivants :
Sous-problème 1 : En concevant des algorithmes et des modèles, traiter et analyser les données de l'Annexe 2 et de l'Annexe 3 pour déterminer les dépendances de contrôle. entre les blocs de base et les dépendances de données pour déterminer initialement la relation hiérarchique entre les blocs de base disposés dans le pipeline.
Sous-question 2 : Combiner les contraintes de ressources données dans la question et les données d'utilisation des ressources de l'annexe 1 pour établir un modèle et déterminer la disposition en série des blocs de base dans le pipeline.
Troisième sous-problème : optimiser la disposition des blocs de base afin que le nombre d'étages de pipeline occupés par les blocs de base soit aussi court que possible.
Analyse de la deuxième question :
La question 2 introduit le concept de blocs de base qui ne sont pas sur un processus d'exécution basé sur la question 1. Pour les blocs de base qui ne sont pas sur un processus d'exécution, les ressources HASH et les ressources ALU peuvent être partagées. Par conséquent, le deuxième problème atténue l’occupation de HASH et ALU pour le premier problème. La question nécessite également de donner l’algorithme et les résultats de la disposition des blocs de base dans le pipeline, mais les contraintes sont modifiées.
Combiné avec l'analyse, le problème deux peut être décomposé en deux sous-problèmes suivants :
Sous-problème un : Sur la base de l'organigramme du programme, établir un modèle pour déterminer si un bloc de base peut atteindre un autre bloc de base, c'est-à-dire si les deux blocs de base sont sur le même flux d'exécution.
Sous-problème 2 : combiner la condition selon laquelle les blocs de base qui ne sont pas sur le même processus d'exécution peuvent partager les ressources HASH et ALU et les contraintes modifiées, établir un modèle pour déterminer la disposition des étapes des blocs de base dans le pipeline et créer le pipeline occupé étapes Gardez le nombre aussi court que possible.
Vignette papier globale de l'établissement du modèle et de la solution
Pour tous les documents, veuillez consulter "Modélisation uniquement des cartes de visite QQ" ci-dessous. Cliquez simplement sur la carte de visite QQ.
code:
Certains programmes Python sont les suivants :
import networkx as nx
import matplotlib.pyplot as plt
import numpy as np
import csv
import scipy as sp
# 入度
inGF = []
# 第一步：dfs
dfn = []
rak = []
fa = []
search_path = []
# 第二步：sdom
val = []
bel = []
sdom = []
# 第三步：idom
idom = []
# 比较获取 CDG
cdg = []
idomGF = nx.DiGraph()
def read_csv3(file_name):
f = open(file_name, encoding='UTF8')
csv_reader = csv.reader(f)
control_edges = []
for line in csv_reader:
adj_num = len(line)
if adj_num > 1:
for i in range(1, adj_num):
control_edges.append((int(line[0]), int(line[i])))
f.close()
# print(control_edges)
return control_edges
def subgraph(pointList, linkList):
G = nx.DiGraph()
GF = nx.DiGraph()
# 转化为图结构
for node in pointList:
G.add_node(node)
GF.add_node(node)
for link in linkList:
G.add_edge(link[0], link[1])
GF.add_edge(link[1], link[0])
return G, GF
def dfs(GF):
# GF 的 root 为人为添加的序号最大的根
root = len(GF.nodes) - 1
T = nx.dfs_tree(GF, root)
for n in GF.nodes():
fa.append(0)
dfn.append(n)
global rak
rak = list(T) # 所有节点
for i in range(0, len(fa)):
dfn[rak[i]] = i
for i in list(T.edges): # 所有边
fa[i[1]] = i[0]
# print(dfn)
# print(rak)
# print(fa)
def find(v):
# 还未被遍历
if v == bel[v]:
return v
tmp = find(bel[v])
if (dfn[sdom[val[bel[v]]]] < dfn[sdom[val[v]]]):
val[v] = val[bel[v]]
bel[v] = tmp
return bel[v]
def tarjanFDT():
# 初始化 val 和 sdom
for i in range(0, len(dfn)):
val.append(i)
sdom.append(i)
bel.append(i)
idom.append(i)
# 从大到小遍历 dfs 树
for i in range(len(dfn) - 1, 0, -1):
# dfs 序最大的点 u
u = rak[i]
# 获取 GF 原图中所有 u 的前驱
neighbors = G.neighbors(u)
for v in neighbors:
find(v)
if (dfn[sdom[val[v]]] < dfn[sdom[u]]):
sdom[u] = sdom[val[v]]
# print(sdom)
sdomGF = nx.DiGraph()
for i in range(0, len(sdom)):
sdomGF.add_node(i)
sdomGF.add_edge(sdom[i], i)
bel[u] = fa[u]
u = fa[u]
neighbors = sdomGF.neighbors(u)
for v in neighbors:
find(v)
if sdom[val[v]] == u:
idom[v] = u
else:
idom[v] = val[v]
for i in range(0, len(dfn)):
u = rak[i]
if idom[u] != sdom[u]:
idom[u] = idom[idom[u]]
global idomGF
for i in range(0, len(idom)):
idomGF.add_node(i)
idomGF.add_edge(idom[i], i)
# nx.draw_networkx(sdomGF, with_labels=True)
# plt.show()
# nx.draw_networkx(idomGF, with_labels=True)
# plt.show()
def getInGF():
# 遍历 GF 所有点
for i in range(0, len(GF.nodes)):
# 初始化：0 标识入度为 0
inGF.append(0)
for edge in GF.edges:
inGF[edge[1]] = 1
def addGFRoot():
# print(len(GF.nodes))
GF.add_node(len(GF.nodes))
for i in range(0, len(inGF)):
if inGF[i] == 0:
GF.add_edge(len(GF.nodes) - 1, i
# nx.draw_networkx(GF, with_labels=True)
# plt.show()
if __name__ == '__main__':
# 读 attachment3.cvs
linkList = read_csv3("./data/attachment3.csv")
pointList = []
for i in range(0, 607):
pointList.append(i)
# 原始有向无环图 G，反向图 GF
G, GF = subgraph(pointList, linkList)
# 获取 GF 入度为 0 的所有点
getInGF()
# 为 GF 添加根节点
addGFRoot()
# 获取 G 的前向支配树，也就是 GF 的支配树，存储在 idomGF 中（即
FDT）
dfs(GF)
tarjanFDT()
# 对比 G 原图和 FDT 图，寻找在 G 但不在 FDT 中的边，得到 CDG
for edgeG in G.edges:
edgeGf = (edgeG[1], edgeG[0])
# 标识是都存在相同，初始化为 0
flag = 0
for edgefdt in idomGF.edges:
if edgeGf == edgefdt:
flag = 1
break
else:
continue
if flag == 0:
cdg.append(edgeG)
f = open("./data/control_dependance_less_equal.txt", "w")
f.writelines(str(cdg))
f.close()
print(len(cdg))
print(cdg)