Search

The GPRO suite is an in-progress bioinformatic project for -omics data analysis. As part of the continued growth of this project, we introduce a client- and server-side solution for comparative transcriptomics and analysis of variants. The client-side consists of two Java applications called “RNASeq” and “VariantSeq” to manage pipelines and workflows based on the most common command line interface tools for RNA-seq and Variant-seq analysis, respectively. As such, “RNASeq” and “VariantSeq” are coupled with a Linux server infrastructure (named GPRO Server-Side) that hosts all dependencies of each application (scripts, databases, and command line interface software). Implementation of the Server-Side requires a Linux operating system, PHP, SQL, Python, bash scripting, and third-party software. The GPRO Server-Side can be installed, via a Docker container, in the user’s PC under any operating system or on remote servers, as a cloud solution. “RNASeq” and “VariantSeq” are both available as desktop (RCP compilation) and web (RAP compilation) applications. Each application has two execution modes: a step-by-step mode enables each step of the workflow to be executed independently, and a pipeline mode allows all steps to be run sequentially. “RNASeq” and “VariantSeq” also feature an experimental, online support system called GENIE that consists of a virtual (chatbot) assistant and a pipeline jobs panel coupled with an expert system. The chatbot can troubleshoot issues with the usage of each tool, the pipeline jobs panel provides information about the status of each computational job executed in the GPRO Server-Side, while the expert system provides the user with a potential recommendation to identify or fix failed analyses. Our solution is a ready-to-use topic specific platform that combines the user-friendliness, robustness, and security of desktop software, with the efficiency of cloud/web applications to manage pipelines and workflows based on command line interface softw, This work was supported by the Marie Sklodowska-Curie OPATHY project grant agreement 642095, the pre-doctoral research fellowship from MINECO Industrial Doctorates (Grant 659 DI-17-09134); Grant TSI-100903-2019-11 from the Secretary of State for Digital Advancement from Ministry of Economic Affairs and Digital Transformation, Spain; the Expedient IDI-2021-158274-a from the Ministry of Science and Innovation, Spain; and the ThinkInAzul program supported by MCIN with funding from European Union NextGenerationEU (PRTR-C17.I1) and Generalitat Valenciana (THINKINAZUL/2021/024)., Peer Reviewed, "Article signat per 18 autors/es: Ahmed Ibrahem Hafez, Beatriz Soriano, Aya Allah Elsayed,Ricardo Futami,Raquel Ceprian, Ricardo Ramos-Ruiz, Genis Martinez, Francisco Jose Roig, Miguel Angel Torres-Font, Fernando Naya-Catala, Josep Alvar Calduch-Giner, Lucia Trilla-Fuertes, Angelo Gamez Pozo, Vicente Arnau, Jose Maria Sempere-Luna, Jaume Perez-Sanchez, Toni Gabaldon and Carlos Llorens ", Postprint (published version)

The GPRO suite is an in-progress bioinformatic project for -omics data analysis. As part of the continued growth of this project, we introduce a client- and server-side solution for comparative transcriptomics and analysis of variants. The client-side consists of two Java applications called “RNASeq” and “VariantSeq” to manage pipelines and workflows based on the most common command line interface tools for RNA-seq and Variant-seq analysis, respectively. As such, “RNASeq” and “VariantSeq” are coupled with a Linux server infrastructure (named GPRO Server-Side) that hosts all dependencies of each application (scripts, databases, and command line interface software). Implementation of the Server-Side requires a Linux operating system, PHP, SQL, Python, bash scripting, and third-party software. The GPRO Server-Side can be installed, via a Docker container, in the user’s PC under any operating system or on remote servers, as a cloud solution. “RNASeq” and “VariantSeq” are both available as desktop (RCP compilation) and web (RAP compilation) applications. Each application has two execution modes: a step-by-step mode enables each step of the workflow to be executed independently, and a pipeline mode allows all steps to be run sequentially. “RNASeq” and “VariantSeq” also feature an experimental, online support system called GENIE that consists of a virtual (chatbot) assistant and a pipeline jobs panel coupled with an expert system. The chatbot can troubleshoot issues with the usage of each tool, the pipeline jobs panel provides information about the status of each computational job executed in the GPRO Server-Side, while the expert system provides the user with a potential recommendation to identify or fix failed analyses. Our solution is a ready-to-use topic specific platform that combines the user-friendliness, robustness, and security of desktop software, with the efficiency of cloud/web applications to manage pipelines and workflows based on command line interface softw

Today, companies are developing processor demanding applications on the web, for example, 3D visualization software and video and audio software. Some of these companies have a native desktop application written in for example C++. These C++ codebases can consist of several hundred thousand lines of code, and companies would therefore like to reuse their codebase in the web version of the software. This thesis makes a performance comparison between two different approaches that can be taken to reuse the C++ codebase. The first approach is to compile the C++ codebase to WebAssembly and run it on the client-side. The second approach is to compile the C++ codebase to native code and run it on the server-side. It is not clear which approach to take if the goal is to achieve low execution times. This thesis will therefore answer the question of whether a client-side solution inWebAssembly is faster than a server-side solution in native code. To answer this question, this project work looked at one use case namely image processing. Two different web applications were developed, one that did image processing on the server-side in native code, and another one that did image processing on the client-side in WebAssembly. Execution time measurements were collected from both web applications. The results showed that for most algorithms WebAssembly was a factor of 1.5 slower than native code, without considering the additional delay from the internet that will affect the web application that performs image processing on the server-side. If this delay is taken into account, the web application that performs image processing on the client-side inWebAssembly will be faster than the server-side solution in native code for most users in the world. If the Round-Trip Time (RTT) is 1 ms the required average throughput needed to make the two web applications equally fast is 249 Mbps (Google Chrome) or 226 Mbps (Firefox). Most users in the world do not have such a high average throughput., Idag utvecklar företag processorkrävande applikationer på webben, till exempel 3D-visualiseringsprogramvara och video- och ljudprogramvara. Några av dessa företag har även skrivbordsprogram skrivna i exempelvis C++. Dessa C++ kodbaser kan bestå av flera hundra tusen rader kod, och företag vill därför återanvända sin kodbas i webbversionen. Detta projektarbete gör en jämförelse mellan två olika tillvägagångssätt för att återanvända C++ kodbasen. Det första tillvägagångssättet är att kompilera C++ kodbasen till WebAssembly och köra koden på klientsidan. Det andra tillvägagångssättet är att kompilera C++ kodbasen till maskinkod och köra koden på serversidan. Det är inte klart vilken metod man ska ta om målet är att uppnå optimal prestanda. Detta projektarbete kommer därför att besvara frågan om en klientsidslösning i WebAssembly är snabbare än en serversidslösning i maskinkod. För att svara på den här frågan tittade projektarbetet på ett användningsfall, nämligen bildbehandling. Två olika webbapplikationer utvecklades, en som gjorde bildbehandling på serversidan i maskinkod och en annan som gjorde bildbehandling på klientsidan i WebAssembly. Körtidsmätningar samlades in från båda webbapplikationerna. Resultaten visade att för de flesta algoritmer var WebAssembly en faktor 1,5 långsammare än maskin kod, utan att ta hänsyn till den extra fördröjningen från internet som kommer att påverka webbapplikationen som utför bildbehandling på serversidan. Om denna fördröjning tas med i beräkningen kommer webbapplikationen som utför bildbehandling på klientsidan i WebAssembly att vara snabbare än serversidslösningen i maskinkod för de flesta användare i världen. Om tur och retur tiden (RTT) är 1 ms är den genomsnittliga genomströmning som krävs för att göra de två webbapplikationerna lika snabba 249 Mbps (Google Chrome) eller 226 Mbps (Firefox). De flesta användare i världen har inte så hög genomsnittlig genomströmning.

Today, companies are developing processor demanding applications on the web, for example, 3D visualization software and video and audio software. Some of these companies have a native desktop application written in for example C++. These C++ codebases can consist of several hundred thousand lines of code, and companies would therefore like to reuse their codebase in the web version of the software. This thesis makes a performance comparison between two different approaches that can be taken to reuse the C++ codebase. The first approach is to compile the C++ codebase to WebAssembly and run it on the client-side. The second approach is to compile the C++ codebase to native code and run it on the server-side. It is not clear which approach to take if the goal is to achieve low execution times. This thesis will therefore answer the question of whether a client-side solution inWebAssembly is faster than a server-side solution in native code. To answer this question, this project work looked at one use case namely image processing. Two different web applications were developed, one that did image processing on the server-side in native code, and another one that did image processing on the client-side in WebAssembly. Execution time measurements were collected from both web applications. The results showed that for most algorithms WebAssembly was a factor of 1.5 slower than native code, without considering the additional delay from the internet that will affect the web application that performs image processing on the server-side. If this delay is taken into account, the web application that performs image processing on the client-side inWebAssembly will be faster than the server-side solution in native code for most users in the world. If the Round-Trip Time (RTT) is 1 ms the required average throughput needed to make the two web applications equally fast is 249 Mbps (Google Chrome) or 226 Mbps (Firefox). Most users in the world do not have such a high average throughput., Idag utvecklar företag processorkrävande applikationer på webben, till exempel 3D-visualiseringsprogramvara och video- och ljudprogramvara. Några av dessa företag har även skrivbordsprogram skrivna i exempelvis C++. Dessa C++ kodbaser kan bestå av flera hundra tusen rader kod, och företag vill därför återanvända sin kodbas i webbversionen. Detta projektarbete gör en jämförelse mellan två olika tillvägagångssätt för att återanvända C++ kodbasen. Det första tillvägagångssättet är att kompilera C++ kodbasen till WebAssembly och köra koden på klientsidan. Det andra tillvägagångssättet är att kompilera C++ kodbasen till maskinkod och köra koden på serversidan. Det är inte klart vilken metod man ska ta om målet är att uppnå optimal prestanda. Detta projektarbete kommer därför att besvara frågan om en klientsidslösning i WebAssembly är snabbare än en serversidslösning i maskinkod. För att svara på den här frågan tittade projektarbetet på ett användningsfall, nämligen bildbehandling. Två olika webbapplikationer utvecklades, en som gjorde bildbehandling på serversidan i maskinkod och en annan som gjorde bildbehandling på klientsidan i WebAssembly. Körtidsmätningar samlades in från båda webbapplikationerna. Resultaten visade att för de flesta algoritmer var WebAssembly en faktor 1,5 långsammare än maskin kod, utan att ta hänsyn till den extra fördröjningen från internet som kommer att påverka webbapplikationen som utför bildbehandling på serversidan. Om denna fördröjning tas med i beräkningen kommer webbapplikationen som utför bildbehandling på klientsidan i WebAssembly att vara snabbare än serversidslösningen i maskinkod för de flesta användare i världen. Om tur och retur tiden (RTT) är 1 ms är den genomsnittliga genomströmning som krävs för att göra de två webbapplikationerna lika snabba 249 Mbps (Google Chrome) eller 226 Mbps (Firefox). De flesta användare i världen har inte så hög genomsnittlig genomströmning.