Spelling suggestions: "subject:"domainspecific anguage (DSL)"" "subject:"domainspecific 1anguage (DSL)""
1 |
Falcon : A Graph Manipulation Language for Distributed Heterogeneous SystemsCheramangalath, Unnikrishnan January 2017 (has links) (PDF)
Graphs model relationships across real-world entities in web graphs, social network graphs, and road network graphs. Graph algorithms analyze and transform a graph to discover graph properties or to apply a computation. For instance, a pagerank algorithm computes a rank for each page in a webgraph, and a community detection algorithm discovers likely communities in a social network, while a shortest path algorithm computes the quickest way to reach a place from another, in a road network. In Domains such as social information systems, the number of edges can be in billions or trillions. Such large graphs are processed on distributed computer systems or clusters.
Graph algorithms can be executed on multi-core CPUs, GPUs with thousands of cores, multi-GPU devices, and CPU+GPU clusters, depending on the size of the graph object. While programming such algorithms on heterogeneous targets, a programmer is required to deal with parallelism and and also manage explicit data communication between distributed devices. This implies that a programmer is required to learn CUDA, OpenMP, MPI, etc., and also the details of the hardware architecture. Such codes are error prone and di cult to debug. A Domain Speci c Language (DSL) which hides all the hardware details and lets the programmer concentrate only the algorithmic logic will be very useful.
With this as the research goal, Falcon, graph DSL and its compiler have been developed. Falcon programs are explicitly parallel and Falcon hides all the hardware details from the programmer. Large graphs that do not t into the memory of a single device are automatically partitioned by the Falcon compiler. Another feature of Falcon is that it supports mutation of graph objects and thus enables programming dynamic graph algorithms. The Falcon compiler converts a single DSL code to heterogeneous targets such as multi-core CPUs, GPUs, multi-GPU devices, and CPU+GPU clusters. Compiled codes of Falcon match or outperform state-of-the-art graph frameworks for di erent target platforms and benchmarks.
|
2 |
Prototyping a formal system modeling workbench in the java ecosystem : A Domain Specific Language in GroovySavegren, Joakim, Edling, Joar January 2022 (has links)
Modeling is a fundamental property in today’s development of embedded systems. Models of computation enable us to describe the functionality and characteristics of a system on a higher abstraction level which gives the designer great insight in the behavior of the final implemented system at a very early stage in the design process. The ForSyDe modeling framework is based on the Model-of-computation (MoC) theory. Synchronous data-flow (SDF) is one MoC that uses actors and tokens to describe the communication and behavior of a system. Currently, the ForSyDe input modeling language exists only as a Haskell implementation and a System C implementation. The main problem is that the ForSyDe tool ecosystem is implemented across different languages without proper connections between tools. However, a framework to make such connections exists, namely the ForSyDe IO Java supporting library. In addition, any language running on the JVM can already be connected to ForSyDe IO. Hence, the thesis explores how a modeling workbench can be designed as a domain specific language (DSL) in the JVM language Groovy using the Gradle environment. Since there are many modules in the ForSyDe modeling framework, one for each MoC, this thesis targets one module: SDF. This choice is enough to explore whether it is possible to achieve the same modeling that Haskell provides in a JVM language, without sacrificing the user experience while modeling. The resulting Groovy DSL can describe the Synchronous Data-Flow MoC with the purpose of modeling SDF graphs, often used in image processing applications. By using the produced DSL workbench, a designer can model SDF applications in an efficient way. There were some differences when comparing the Groovy DSL to the Haskell implementation, such as the methods for defining actors and connecting them. However, the core modeling concepts are the same. Combining Groovy and Gradle offered an easy way of designing a DSL using the concept of closures. The created Groovy DSL is the first member of a family of textual DSL’s for describing MoC’s and therefore acts as a foundation for future work within the ForSyDe modeling framework. It can be extended to support more modules and functions or to inspire others to develop new DSL’s. / Modellering av system är en grundsten i dagens utveckling av inbyggda system. Beräkningsmodeller möjliggör att beskriva systems egenskaper och funktioner på en hög abstraktionsnivå vilket underlättar den första tiden vid utvecklingen av ett nytt inbyggt system. ForSyDe är ett modelleringsspråk baserat på beräkbarhetsteori. Det synkrona dataflödet (SDF) är en beräkningsmodell som använder sig av aktörer och tokens för att beskriva ett systems kommunikation och bettend. ForSyDe är implementerat i programmeringsspråket Haskell och System C, men är i fortsatt utveckling och grenar ut till andra språk och miljöer. Det huvudsakliga Problemet med ForSyDe är att ramverket saknar bra kopplingar mellan verktygen som erbjuds. Ett ramverk som möjliggör kopplingen mellan verktygen är stöd biblioteket ForSyDe IO och dessutom kan ett språk som kör i Javas virtuella miljö redan kopplas med ForSyDe IO. Därför undersöker uppsatsen hur ett domänspecifikt språk kan skrivas i Groovy i utvecklingsmiljön gradle för att direkt extrahera en ForSyDe IO modell utan att behöva undersöka varje element i modellen. Det finns många moduler i ForSyDe ramverket, en för varje beräkningsmodell och därför menar uppsatsen att undersöka en modul: SDF. Att undersöka SDF modulen anses tillräckligt för att bestämma sig huruvida det är möjligt att uppnå liknande modellering som Haskell erbjuder fast i java miljön, utan att offra användarvänligheten då ett system modelleras. Resultatet blev en Groovy prototyp som kan beskriva SDF-modulen med syftet att modellera SDF-grafer vars funktion ofta används inom bildbehandling. En SDF-graf beskriver ett systems dataflöde och via det resulterande domänspecifika språket kan en utvecklare på ett tillfredsställande sätt beskriva dataflöden i javamiljön. Det visade sig att det resulterande domän specifika språket i Groovy skiljer sig en aning från Haskell i hur man specificerar aktörer och deras kopplingar, men det fundamentala konceptet är detsamma. Groovy i kombination med Gradle erbjöd ett smidigt sätt att programmera ett domänspecifikt språk med hjälp av closures vilket kan användas för framtida bruk inom utvecklingsområdet. Den skapade prototypen är den första medlemmen i en familj av framtida modelleringsspråk som beskriver beräkningsmodeller. Resultatet av projektet utgör en grund för ett fortsatt arbete med att bygga vidare på prototypen, men även för att kunna lägga till fler beräkningsmoduler som i sin tur bidrar med utbyggningen av ramverket ForSyDe.
|
3 |
Conception et mise en oeuvre d'une plate-forme pour la sûreté de fonctionnement des services WebSalatgé, Nicolas 08 December 2006 (has links) (PDF)
Basés sur les protocoles XML, SOAP et WSDL, les Services Web (SW) sont la technologie de base pour le développement d'Architectures Orientées Services (AOS). Ces architectures permettent de mettre en place des applications faiblement couplées avec un fort degré de configuration dynamique. Elles se basent sur la notion de relation de "services" formalisée par un contrat qui unit le client et le prestataire de services. Ce contrat est le point charnière de ce type d'applications. D'un point de vue purement marketing, les Services Web peuvent être développés pour satisfaire les besoins des clients, être facile à maintenir et aussi fournir un haut niveau de qualité de service. Les prestataires de Services Web doivent s'assurer de la fiabilité et de la disponibilité de leur infrastructure individuelle de Services Web. Cependant, les prestataires ne peuvent pas tenir compte de tous les besoins possibles des clients et des contraintes liées au développement de l'application donnée. Cela signifie que des mécanismes additionnels doivent être développés et ciblés pour un contexte d'utilisation donné. C'est exactement le type de problèmes que j'ai examiné dans mes travaux. Les développeurs d'application regardent les Services Web comme des COTS (Component Off-The Shell) et ignorent donc leurs implémentations et leurs comportements en présence de fautes. De ce point de vue, les clients ont besoin de développer des mécanismes de tolérances aux fautes spécifiques bien adaptés à leurs applications. Dans ce but, mes travaux de thèse m'ont conduit à proposer une plate-forme pour aider les clients à réaliser des connecteurs spécifiques de tolérance aux fautes (SFTC - Specifique Fault Tolerance Connectors) qui implémentent des filtres et autres techniques de détection d'erreurs (c.à.d des assertions exécutables) ainsi que des mécanismes de recouvrement qui sont déclenchés quand les Services Web ne satisfont plus les caractéristiques de sûreté demandées. De plus, le même Services Web peut être employé dans plusieurs applications orientées services avec différentes contraintes et peut donc tirer profit de plusieurs connecteurs (SFTCs). Le problème est similaire à l'utilisation des composants COTS dans les systèmes critiques de sûreté, et des travaux précédents ont déjà prouvé que des mécanismes tels que les wrappers étaient une solution possible. La différence dans le contexte des Architectures Orientées Services est que des wrappers prédéfinis ne peuvent pas être spécifiés pour satisfaire tous les besoins possibles. L'approche doit être plus adaptative pour permettre à des mécanismes de sûreté : 1) d'être définis au cas par cas pour une utilisation donnée du Service Web et 2) d'avoir une forte dynamique afin d'être modifiés selon les besoins. Ainsi, mes travaux de recherches ont permis de fournir aux développeurs d'Architectures Orientées Services: 1) un langage nommé DeWeL pour décrire les caractéristiques de sûreté de fonctionnement du connecteur et 2) l'infrastructure IWSD pour dynamiquement contrôler et exécuter les connecteurs dans des applications critiques. L'objectif final est de fournir aux développeurs d' Architectures Orientées Services une infrastructure et des outils capables de les aider à déployer des applications orientées services tolérants les fautes.
|
Page generated in 0.0672 seconds