Améliorer sa productivité grâce aux traitements parallèles : SAS Multi-Process CONNECT

Transcription

1 Améliorer sa productivité grâce aux traitements parallèles : SAS Multi-Process CONNECT 1

2 TABLE DES MATIERES I. INTRODUCTION...3 II. LES TRAITEMENTS PARALLELES...4 1) Qu est-ce qu un traitement parallèle avec MP CONNECT?...4 2) Qu est qu une architecure SMP?...4 III. LE DETAIL DE MP CONNECT...5 1) Quelques cas où MP CONNECT peut s appliquer...5 2) Comment identifier que MP CONNECT peut s utiliser?...7 3) La syntaxe pour MP CONNECT...7 4) Nouveautés spécifiques à la version III. TABLEAU COMPARATIF ENTRE UNE EXECUTION SEQUENTIELLE ET UNE EXECUTION MP CONNECT ) Spécificité de la machine de test ) Tableau de tests...14 IV. LE FUTUR DE MP CONNECT...14 V. EXEMPLE DE PROGRAMME S MP CONNECT...15 VI. CONCLUSION...18 VII. REFERENCES

3 I. INTRODUCTION La version 8 du Système SAS introduit une nouveauté très intéressante avec le module SAS/CONNECT : le Multi-Process CONNECT (MP CONNECT). Aujourd hui du fait de l augmentation du volume de données, les serveurs s équipent de plusieurs processeurs pour accélérer les traitements. MP CONNECT tire donc avantage des architectures parallèles, on entend par architecture parallèle les machines SMP (Symmetric Multi-Processing). Cette nouveauté exploite à fond les capacités d un serveur Multiprocesseur en permettant le traitement parallèle des tâches et la coordination de tous les résultats dans la session SAS initiale. Concrètement, l utilisateur peut désormais démarrer une session SAS distante sur chacun des processeurs de son serveur, exécuter son code sur chacune de ces sessions distantes, et récupérer son résultat dans sa session SAS originale. Session SAS distante Session SAS locale Connect et Signon Session SAS distante Session SAS distante Le premier objectif du traitement multiprocesseur est d exécuter un programme en moins de temps qu avec une exécution séquentielle. Avant la Version 8, SAS/CONNECT a toujours été un outil de «client/serveur» pour établir une connexion depuis une session SAS en locale vers une session SAS distante. MP CONNECT profite du «multiprocessing» en établissant une connexion vers une ou plusieurs sessions SAS distantes qui peuvent résider sur la machine locale ou sur différentes machines du réseau. MP CONNECT est la clé offerte aux utilisateurs SAS pour rentrer dans le monde des traitements parallèles. Avec MP CONNECT vos étapes DATA, vos proc SQL, vos proc SORT et bien d autres verront leur temps d accomplissement réduit. Ce papier a pour but de vous donner une idée, de vous présenter MP CONNECT, et d illustrer les bénéfices qu il peut vous apporter. 3

4 II. LES TRAITEMENTS PARALLELES 1) Qu est-ce qu un traitement parallèle avec MP CONNECT? Le terme de traitement parallèle dans notre contexte signifie le traitem ent concurrent en simultané ; des tâches individuelles sont exécutées au même moment. Sans MP CONNECT, le traitement se faisait de façon séquentielle c est à dire que l exécution de la tâche B était impossible tant que la tâche A n était pas finie. Imaginons par exemple qu un utilisateur SAS ait pour mission de traiter deux fichiers à plat le plus rapidement possible. Il doit intégrer ces deux fichiers dans SAS, transformer les variables, trier les tables puis enfin les combiner via un «merge» et exécuter une proc summary sur cette nouvelle table. Le MP CONNECT va permettre à notre utilisateur d exploiter ses processeurs pour exécuter tout ce qui concerne la préparation des données (jusqu au «merge») en parallèle. Nous pouvons imaginer le temps qui peut être gagné dans le cas de très grosse structure de données. En effet, en version 6 toutes ces opérations auraient dû être réalisées de façon séquentielle et toute la première partie de notre traitement aurait été beaucoup plus coûteuse en temps. Version 6 Version 8 ETAPE DATA A; PROC SORT A; ETAPE DATA B ; PROC SORT B; MERGE A B ; SUMMARY ; ETAPE DATA A ; PROC SORT A; Traitement parallèle MERGE A B ; SUMMARY ; ETAPE DATA B ; PROC SORT B; 2) Qu est qu une architecture SMP (Symmetric MultiProcessor ou Architecture multiprocesseur symétrique)? Dans cette architecture, plusieurs processeurs partagent une mémoire et un sous-système d E/S globaux. Le modèle logiciel SMP traditionnel, appelé modèle à mémoire partagée, exécute une seule copie du système d exploitation, et les processus d application s exécutent comme s ils se trouvaient sur un système monoprocesseur. Le système SMP offre un haut niveau d évolutivité à la condition que les applications exécutées ne fassent pas appel aux partages des données. 4

5 III. LE DETAIL DE MP CONNECT Le terme de multiprocessing au sens MP Connect est de diviser un traitement en plusieurs sous tâches indépendantes qui peuvent être exécutées simultanément. Le but du MP CONNECT est donc de traiter un programme en moins de temps que si on l exécute séquentiellement. Pour cela on a la possibilité d utiliser MP CONNECT sur un poste qui bénéficie d une architecture SMP ou bien sur différents postes à travers votre réseau (Voir «V. Exemple de programme MP CONNECT). 1) Quelques cas où MP CONNECT peut s appliquer : Votre projet implique l extraction ou le traitement de données provenant de sources indépendantes avant de combiner le tout. Vous travaillez avec une table très volumineuse qui peut être divisée en plusieurs sous ensembles pour des traitements indépendants avant une recombinaison pour l analyse. Votre devez construire plusieurs MDDB, afin de mettre en place une structure HOLAP sur ces derniers. Vous pouvez donc créer vos MDDB, en parallèle. Voici quelques scénarii illustrés d un schéma dans lesquels MP CONNECT peut avoir un impact conséquent sur les bénéfices en temps : Figure 1 illustre un possible scénario de Data Warehouse qui requiert l extraction de données provenant de trois sources différentes et qui seront combinées ensuite pour un traitement commun. En procédant à l extraction des trois sources de façon parallèle votre temps de traitement va diminuer considérablement. Sans MP CONNECT il aurait fallu procéder aux extractions une à une de façon séquentielle avant de pouvoir les combiner. Extraction Orac le Extraction sur une table SAS merge data Lecture d un fichier à plat temps Figure 1. Scénario Data Warehouse 5

6 Figure 2 illustre un exemple d analyse SAS qui requiert l exécution de plusieurs procédures SAS indépendantes sur une ou plusieurs sources de données. Ici, avec MP CONNECT beaucoup de temps sera gagner. Maintenant, le temps pour exécuter ces 3 traitements, sera égal au temps d exécution de la procédure la plus consommatrice en temps. PROC FREQ PROC TABULATE Traitements additionnels. PROC UNIVARIATE temps Figure 2. Analyses multiples sur une table unique. Figure 3 illustre un scénario HOLAP qui requiert la création de plusieurs MDDBs. L exécution parallèle de création de MDDBs s applique parfaitement à MP CONNECT. En fonction du nombre et de la taille de vos cubes, les bénéfices en temps pourront être très conséquents. Création MDDB 1 Création MDDB 2 Création MDDB n temps Figure 3. Créations parallèles de MDDBs. 6

7 2) Comment identifier que MP CONNECT peut s utiliser? Il est important de noter que MP CONNECT ne peut pas s appliquer à tous les types de traitements. Il faut donc apprendre à les identifier : Il faut déterminer si vos sources de données peuvent être traitées séparément et indépendamment les unes des autres. Repérer les possibilités pour segmenter le code en plusieurs sous parties et s assurer qu elles n accèderont pas à des ressources partagées. S assurer que votre système peut supporter la syntaxe additionnelle apportée par le traitement parallèle. Un traitement MP CONNECT sur une seule machine mono processeur n a aucun intérêt. Ces vérifications peuvent paraître futiles mais s avère importante dans l optique de gagner du temps avec MP CONNECT. Il faut être sûr d avoir bien identifié que l utilisation de MP CONNECT va nous apporter des bénéfices. 3) La syntaxe pour MPCONNECT : Normalement, avec SAS/CONNECT, la commande SIGNON est utilisée pour établir une connexion entre deux sessions SAS. Cette commande a été simplifiée pour faciliter la création de connections sur la machine locale. Ce nouveau SIGNON élimine le besoin d utilisation d un script sur le poste local, le besoin de spécifier un userid et un password, le besoin d un spawner à l écoute, et le besoin de spécifier la méthode d accès Le seul paramètre nécessaire pour que le SIGNON fonctionne est la commande utilisée pour lancer une session SAS et un nom associé à ce nouveau process SAS. Une nouvelle option SASCMD est utilisée pour spécifier la commande SAS qui est utilisé pour lancer une session SAS. Cette commande peut être spécifiée en option globale ou en option du SIGNON. Une fois qu un SIGNON a été exécuté et qu une connexion est établie vers une ou plusieurs sessions SAS, la commande RSUBMIT peut être exploitée pour exécuter des traitements. Désormais, on dispose d une option AUTOSIGNON qui permet de diminuer la syntaxe pour exécuter une nouvelle session SAS, elle permet d éviter l utilisation de SIGNON, on peut utiliser juste un bloc RSUBMIT/ENDRSUBMIT pour réaliser la connexion et le traitement. La commande RSUBMIT utilisée avec l option WAIT=NO identifie que le traitement peut être exécuté par une nouvelle connexion SAS, c est le mode asynchrone. En fait, au lieu d attendre qu un premier bloc RSUBMIT/ENDRSUBMIT soit achevée, cette option permet de démarrer une nouvelle tâche dans une autre session SAS. Par défaut, pour chaque traitement asynchrone, SAS/CONNECT encapsule toutes les informations de log et d output dans un fichier jusqu à ce que vous les requêtiez avec la commande RGET ou un SIGNOFF. Vous pouvez donc visualiser la log avec cette commande sans arrêter la connexion. La commande RDISPLAY permet elle aussi de visualiser les informations de la log et de l output accumulées par SAS/CONNECT mais dans des fenêtres indépendantes, on évite ainsi le mélange entre les informations de la session locale et les informations de la session remote. De plus il existe des nouvelles options en version 8.2 pour la gestion de la log et de l output. 7

8 Une autre commande très importante concerne le fait de pouvoir contrôler l exécution locale qui va suivre vos traitements asynchrones en multiprocessing. Ce contrôle est géré par la commande WAITFOR qui met en attente l exécution de votre traitement en local temps que une, plusieurs ou toutes les tâches démarrées auparavant ne sont achevées. Par exemple si vous souhaitez utiliser deux sessions qui chacune triera une table puis ensuite faire un merge sur ces deux tables dans votre session parente, vous devrez être sûr que les deux traitements de tri sont bien terminés avant de procéder au merge. WAITFOR vous permet de contrôler ce phénomène. La commande LISTASK vous permet d observer dans la log l état actuel de une ou toutes vos connexions actives. C est utile pour observer l état de nos traitements asynchrones à un instant T. Voyons maintenant les détails de ces options et commandes qui permettent le multiprocessing avec SAS. La commande SIGNON : La commande SIGNON est utilisé pour démarrer, depuis SAS, une autre session SAS et donc d établir une connexion entre deux sessions SAS. La nouvelle session SAS peut être démarré sur la même machine ou sur machine distante. Si vous voulez établir cette connexion sur une autre machine un spawner et/ou un fichier script est nécessaire. Si la session SAS est démarrée sur la même machine que la machine parente alors la nouvelle option SASCMD peut être utilisée pour spécifier la commande à utiliser pour démarrer SAS. Cette option peut être déclarée avec les options générales, avec le SIGNON ou, si l option AUTOSIGNON est utilisée, dans le RSUBMIT. SASCMD= SAScmd Où SAScmd positionne la commande à utiliser pour lancer une nouvelle session SAS. Vous pouvez rajouter entre les quotes des options relatives à votre démarrage de SAS, par exemple : sascmd=" 'C:\Program Files\SAS Institute\SAS\V8\SAS.EXE' -config 'C:\Program Files\SAS Institute\SAS\V8\SASV8.CFG' " La commande RSUBMIT : La commande RSUBMIT permet d exécuter du code SAS saisi dans la session locale au sein d une session SAS démarrée en REMOTE. Toutes les informations provenant de la log et de l output sont renvoyées dans votre log et output locales comme si elles étaient exécutées dans la session locale. RSUBMIT peut être exécuté en mode synchrone et asynchrone. Le mode synchrone signifie que le traitement REMOTE doit être terminé avant qu on puisse continuer le traitement LOCAL. C est à dire que le RSUBMIT est exécuté entièrement avant qu on reprenne le contrôle de notre session locale. C est le mode par défaut. Le mode asynchrone permet de lancer un traitement en RSUBMIT en tâche de fond et de reprendre tout de suite le contrôle de la session locale, ou de lancer un autre traitement en REMOTE sur une autre machine. Les options RSUBMIT suivantes permettent le mode asynchrone : CONNECTWAIT CWAIT WAIT=value Où value spécifie si ce RSUBMIT spécifique va être exécuté en mode synchrone où asynchrone. CWAIT permet de déclarer le mode d exécution du RSUBMIT en option globale : OPTIONS CWAIT=NO; 8

9 Les valeurs qui peuvent être prises en compte par WAIT= sont : YES Y NO N Indique une exécution en mode synchrone du RSUBMIT. Indique une exécution en mode asynchrone du RSUBMIT Si vous avez positionné WAIT=NO, il peut être intéressant de spécifier l option MACVAR. Cela vous permettra alors de tester à tout moment le statut d un traitement RSUBMIT asynchrone (Terminé ou en cours). CMACVAR MACVAR=value Où value spécifie le nom de la macro variable à associer à ce traitement en REMOTE. La macro variable pourra alors prendre les valeurs suivantes : Indique que le traitement RSUBMIT est terminé Indique que le traitement RSUBMIT n a pas pu se terminer. Indique que le traitement RSUBMIT est en cours. La commande WAITFOR : La commande WAITFOR est utilisée pour permettre à la session SAS locale d attendre la fin des traitements asynchrones pour exécuter du code. Si plus d une tâche est spécifiée, alors la commande peut accepter les options suivantes _ANY_ et _ALL_. L option _ANY_ suspend l exécution du code de la session SAS en locale jusqu au terme d une des tâches spécifiées dans le WAITFOR. L option _ALL_ suspend l exécution du code de la session SAS en locale jusqu au terme de toute les tâches spécifiées dans le WAITFOR. Vous pouvez spécifier une option TIMEOUT. Si les tâches spécifiées dans le WAITFOR ne sont pas terminées lorsque la valeur du TIMEOUT est atteinte, le contrôle de la session locale est repris et le traitement asynchrone se poursuit. Si toutes les tâches spécifiées se terminent avant le TIMEOUT le contrôle est rendu à la session locale sans attendre que le TIMEOUT arrive à son terme. La commande RGET : La commande RGET permet de récupérer les informations de la log et de l output accumulées par SAS/CONNECT afin d être insérées dans la log de la session locale. Quand un traitement asynchrone est lancé, par défaut, les fenêtres log et output ne sont pas redirigées vers la session locale, ces informations sont stockées dans le «backing store». Un backing store est un fichier SAS qui est dans le répertoire de la SASWORK. Si la com mande RGET est exécutée pendant qu un traitement asynchrone est en cours, les informations de LOG et d output sont redirigées vers la session locale et le traitement continue mais en mode synchrone. C est à dire que vous ne pourrez reprendre le contrôle de la session locale que lorsque le traitement sera achevé. La meilleure chose à faire, pour exécuter cette opération, est de contrôler via la macro MACVAR l état de votre traitement, lorsqu il est complet, vous pouvez lancer la commande RGET. Si vous travaillez en interactif, vous pouvez utilisé la commande LISTTASK. 9

10 Cependant, si des options du type LOG= ou OUTPUT= (voir nouveautés 8.2) sont spécifiées, les commandes RGET ou RDISPLAY n auront aucun effet. La commande RDISPLAY : La commande RDISPLAY crée deux fenêtres pour chaque traitement asynchrone qui ont pour but d afficher la log et l output qui ont été générées. Une fenêtre affiche les lignes de la log et l autre les lignes de l output. Quand un traitement asynchrone est lancé, par défaut, la log et l output ne sont pas redirigées vers la session locale, ces informations sont stockées. RDISPLAY vous permet de disposer de cette information sans «polluer» la log SAS de la session locale. Cependant si des options du type LOG= ou OUTPUT= (voir nouveautés 8.2) sont spécifiées, les commandes RGET ou RDISPLAY n auront aucun effet. La commande LISTASK : LISTTASK vous donne des informations à propos de toutes les connexions actives. L affichage de LISTTASK est le suivant : nom de la tâche et statut de la tâche. Une tâche peut obtenir les statuts suivants : READY RUNNING SYNCHRONOUSLY RUNNING ASYNCHRONOUSLY COMPLETE Exemple : Options AUTOSIGNON=YES; Rsubmit PROCESS=task1 WAIT=NO MACVAR=tt SASCMD='/sas/sasv8/sas'; /* Programme exécuté sur la session REMOTE*/ endrsubmit; WAITFOR task1; /* attente de la fin de task1*/ /*Programme exécuté sur la session LOCALE*/ DM 'RGET'; /*récupéation log et Output*/ 10

11 4) Nouveautés spécifiques à la 8.2 : Nouvelles options pour LOG= et OUTPUT= : Il existe des nouvelles options pour LOG= et OUPUT= qui peuvent être utilisées en RSUBMIT mais seulement en mode asynchrone. Cela permet de diriger la log ou l output SAS qui sont générées par la session distante en cours, soit dans le Backing store, soit dans un fichier. Vous avez trois possibilités : LOG= / OUTPUP= KEEP, PURGE et <filename fileref> : KEEP : c est le défaut. Il va diriger la log et l output dans le «Backing store». Pour les récupérer, il faut utiliser les commandes rget, rdisplay ou signoff ; PURGE : comme son nom le laisse présager, cette instruction efface toutes les lignes générées par la log ou l output. Cela peut être utilisé lorsqu on veut limiter l utilisation d espace disque par le traitement. <Filename fileref > : les résultats seront stockés dans le fichier spécifié. Nouvelle instruction KILLTASK : KILLTASK peut être utilisé pour mettre fin à une ou plusieurs tâches asynchrones. Vous pouvez spécifier la liste des tâches à terminer séparées par des espaces ou par le mot clé _ALL_ si vous voulez terminer toutes les tâches asynchrones en cours. L utilisation de cette commande entraîne l affichage des LOG et des OUTPUT accumulées dans le «backing store» dans la session locale parente. La syntaxe est : KILLTASK ALL <task1 task2...>; La fenêtre NOTIFY : Vous pouvez désormais spécifier si vous voulez recevoir une notification visuelle lorsqu un traitement asynchrone est terminé. Une fenêtre apparaît avec le texte suivant : Asynchronous task xxxx has completed. L apparition de cette fenêtre n empêche pas la poursuite du traitement. 11

12 Le moniteur SAS/CONNECT : Aujourd hui l explorateur de SAS nous donne une possibilité de visualiser le moniteur de SAS/CONNECT ce qui permet en fait de suivre le déroulement des tâches ou des connexions lancées à travers SAS. La fenêtre liste donc le nom des tâches lancées avec leurs statuts associés. Une nouvelle tâche est ajoutée lorsqu un SIGNON est exécuté et le champ statut est mis à jour dynamiquement selon l état de la tâche. A tout moment, vous pouvez agir sur ces tâches avec le clic droit de la souris, deux choix vous sont alors proposer RDISPLAY ou KILL. Une tâche est automatiquement effacée du moniteur lorsque le signoff de celle ci est exécuté. Les différents statuts sont les suivants : READY RUNNING SYNCHRONOUSLY RUNNING ASYNCHRONOUSLY COMPLETE Pour atteindre le moniteur SAS/CONNECT : 12

13 La fenêtre du moniteur de SAS/CONNECT : III. TABLEAU COMPARATIF ENTRE UNE EXECUTION SEQUENTIELLE ET UNE EXECUTION MPCONNECT 1) Spécificité de la machine de test : Les tests ont été réalisés sur SAS Version 8.2. Système Composants Windows 2000 server 2 processeurs Intel Pentium III de 933 Mhz Bus mémoire à 133Mhz 3 disques RAID 5 de 18 Go chacun Mémoire 1 Go 13

14 2) Tableau de tests Programme Exécution séquentielle MP CONNECT Création de deux tables de 10 millions d observations chacune. Tris de ces deux tables, puis merge de ces deux tables. Création de quatre tables de 50 millions d observations chacune. Tris de ces quatre tables, puis merge de ces quatre tables. Création de deux tables de 75 millions d observations chacune. Tris de ces deux tables, puis merge de ces deux tables. 00 :02 :15 00 :01 :41 01 :10 :40 00 :48 :33 00 :55 :47 00 :34 :02 Des benchmarks ont été réalisés aux Etats-Unis sur une machine Unix Solaris 7 avec 12 processeurs Ultrasparc de 400 Mhz chacun, les résultats sont très probants quant aux bénéfices qu on peut tirer de MP CONNECT avec une machine puissante. Dans ce tableau, la première colonne représente le nombre de fois que le programme a été exécuté lorsque c était en séquentielle et le nombre de processeurs utilisé lorsque le test était avec MP CONNECT. La seconde colonne représente le nombre de bytes de la table qui est utilisé, ensuite les deux dernières colonnes sont le temps d exécution avec MP CONNECT et le temps d exécution en séquentielle. Boucles/processeurs Total Bytes MP CONNECT Exécution séquentielle 2 48MG 00 :01 :14 00 :02 : MG 00 :01 :17 00 :04 : MG 00 :05 :21 00 :09 : MG 00 :05 :31 00 :19 : MG 00 :13 :21 00 :26 : MG 00 :13 :32 00 :52 : MG 00 :14 :23 01 :20 : G 00 :27 :27 01 :48 : G 00 :28 :58 02 :40 :51 IV. LE FUTUR DE MP CONNECT 14

15 SAS travaille actuellement sur des améliorations pour faciliter l usage de MP CONNECT : Spécifier le nom d une tâche spécifique dans la macro %SYSLPUT pour permettre de diriger l exécution vers une tâche spécifique. Repérer les sessions asynchrones actives au moment d un arrêt du SAS en local pour demander via une fenêtre à l utilisateur si il est sûr de vouloir stopper tel ou tel traitement. Permettre à la session REMOTE d avoir un accès facile aux bibliothèques qui sont déclarées dans la session locale. De plus, un prototype de «pipeline parallelism» est en train d être implémenté. «Pipeline parallelism» permet lorsqu une tâche B requiert des résultats de la tâche A, mais ne requiert pas l ensemble des résultats, de démarrer avant la fin de tâche A. V. EXEMPLE DE PROGRAMMES MP CONNECT Ce programme illustre la fonctionnalité MP CONNECT. Dans ce programme je crée deux tables (de 75 millions observations chacune), puis je les trie en traitements parallèles. Ensuite, je fais un merge sur les deux tables dans ma session locale (architecture SMP). /* Déclaration des options*/ option autosignon=yes ; /*Déclaration du libname*/ libname ut 'f:\frafpo'; /*Exécution de la première tache*/ rsubmit process=task1 wait=no sascmd="sas"; libname ut 'f:\frafpo'; data ut.world(drop=i); length indnr omrnr redar redvarde 4.; do I=1 to ; indnr=int(uniform(0)*100); omrnr=int(uniform(0)*100); redar=int(uniform(0)*100); redvarde=int(uniform(0)*100); output; end; run; 15

16 proc sort data=ut.world ; by indnr ; run ; endrsubmit task1; /*Exécution de la deuxième tache*/ rsubmit process=task2 wait=no sascmd="sas"; libname ut 'f:\frafpo'; data ut.world2(drop=i); length indnr omrnr redar redvarde 4.; do I=1 to ; indnr=int(uniform(0)*100); omrnr=int(uniform(0)*100); redar=int(uniform(0)*100); redvarde=int(uniform(0)*100); output; end; run; proc sort data=ut.world2 ; by indnr ; run ; endrsubmit task2; /*attente de l'exécution complète des deux taches*/ waitfor _all_ task1 task2 ; /*merge des deux tables*/ data ut.entworld ; merge ut.world ut.world2 by indnr ; run ; /* deconnexion des deux postes*/ signoff task1 ; signoff task2 ; Le programme suivant illustre le MPCONNECT avec une utilisation sur trois postes. La session parente est lancée depuis le poste A, les traitements parallèles sont exécutés sur deux postes distants sur le réseau. /* Code SAS pour la session locale */ %let host1=pcdel119.emea.sas.com; %let host2=pcdel008.emea.sas.com; Filename rlink 'C:\Program Files\SAS Institute\SAS\V8\connect\saslink\tcpwin.scr'; signon remote=host1 script=rlink; signon remote=host2 script=rlink ; 16

17 /*Code exécuté sur la machine B */ rsubmit remote=host1 wait=no; data _null_ ; rc=sleep(10) ; run ; endrsubmit; /* Code exécuté sur la machine C*/ rsubmit remote=host2 wait=no; data _null_ ; rc=sleep(10) ; run ; endrsubmit; /* statut des deux taches */ LISTTASK ; /* attente de la fin des deux traitements parallèles pour que */ /* le traitement local puisse être repris*/ waitfor _all_ host1 host2; /* récupération des informations LOG stockées par SAS/CONNECT */ RGET HOST1; RGET HOST2; /* le code suivant est exécuté en local */ options dlg=native; filename sortie "frafpo@fra.sas.com" subject='etat des traitements' ; DATA _NULL_; FILE SORTIE; PUT Traitements terminés'; RUN ; /* deconnexion des deux postes*/ signoff host1 ; signoff host2 ; 17

18 VI. CONCLUSION MP CONNECT version 8 permet d améliorer certains programmes avec un traitement en parallèles de certaines tâches indépendantes. Cette nouvelle fonctionnalité de la version 8 est simple d utilisation et les anciens programmes ne nécessitent pas énormément de modifications pour jouir des avantages de MPCONNECT. Il est bien sûr recommandé d évaluer si MPCONNECT sera utile à un programme pour voir apparaître des bénéfices conséquents. MPCONNECT est extrêmement «scalable» ce qui signifie que vous pourrez contracter d énormes gains de temps lorsque votre nombre de process SAS lancés se rapprochera du nombre de processeurs de votre machine. VII. REFERENCES : o "How Fast can your SAS Programs Run? Take Advantage of Parallel Processing with Version 8 Multiprocessing Capabilities", web page from the SAS Institute o "Multiprocessing with Version 8 of the SAS System", by Cheryl Doninger, SAS Institute, Inc. 18

19 19