1,051 research outputs found
Desempenho comparativo do BLAST e do mpiBLAST
Em Bioinformática são frequentes problemas cujo tratamento necessita de considerável poder de processamento/cálculo e/ou grande capacidade de armazenamento de dados e elevada largura de banda no acesso aos mesmos (de forma não comprometer a eficiência do seu processamento). Um exemplo deste tipo de problemas é a busca de regiões de similaridade em sequências de amino-ácidos de proteínas, ou em sequências de nucleótidos de DNA, por comparação com uma dada sequência fornecida (query sequence). Neste âmbito, a ferramenta computacional porventura mais conhecida e usada é o BLAST (Basic Local Alignment Search Tool) [1]. Donde, qualquer incremento no desempenho desta ferramenta tem impacto considerável (desde logo positivo) na atividade de quem a utiliza regularmente (seja para investigação, seja para fins comerciais). Precisamente, desde que o BLAST foi inicialmente introduzido, foram surgindo
diversas versões, com desempenho melhorado, nomeadamente através da aplicação
de técnicas de paralelização às várias fases do algoritmo (e. g., partição e distribuição
das bases de dados a pesquisar, segmentação das queries, etc. ), capazes de tirar
partido de diferentes ambientes computacionais de execução paralela, como:
máquinas multi-core (BLAST+ 2), clusters de nós multi-core (mpiBLAST3J e, mais
recentemente, co-processadores aceleradores como GPUs" ou FPGAs. É também
possível usar as ferramentas da família BLAST através de um interface/sítio WEB5,
que permite, de forma expedita, a pesquisa de uma variedade de bases de dados
conhecidas (e em permanente atualização), com tempos de resposta suficientemente
pequenos para a maioria dos utilizadores, graças aos recursos computacionais de
elevado desempenho que sustentam o seu backend. Ainda assim, esta forma de
utilização do BLAST poderá não ser a melhor opção em algumas situações, como por
exemplo quando as bases de dados a pesquisar ainda não são de domínio público,
ou, sendo-o, não estão disponíveis no referido sitio WEB. Adicionalmente, a utilização
do referido sitio como ferramenta de trabalho regular pressupõe a sua disponibilidade
permanente (dependente de terceiros) e uma largura de banda de qualidade
suficiente, do lado do cliente, para uma interacção eficiente com o mesmo. Por estas
razões, poderá ter interesse (ou ser mesmo necessário) implantar uma infra-estrutura
BLAST local, capaz de albergar as bases de dados pertinentes e de suportar a sua
pesquisa da forma mais eficiente possível, tudo isto levando em conta eventuais
constrangimentos financeiros que limitam o tipo de hardware usado na implementação
dessa infra-estrutura. Neste contexto, foi realizado um estudo comparativo de diversas versões do
BLAST, numa infra-estrutura de computação paralela do IPB, baseada em
componentes commodity: um cluster de 8 nós (virtuais, sob VMWare ESXi) de
computação (com CPU Í7-4790K 4GHz, 32GB RAM e 128GB SSD) e um nó dotado de
uma GPU (CPU Í7-2600 3.8GHz, 32GB RAM, 128 GB SSD, 1 TB HD, NVIDIA GTX
580). Assim, o foco principal incidiu na avaliação do desempenho do BLAST original e
do mpiBLAST, dado que são fornecidos de base na distribuição Linux em que assenta o cluster [6]. Complementarmente, avaliou-se também o BLAST+ e o gpuBLAST no nó
dotado de GPU. A avaliação contemplou diversas configurações de recursos, incluindo
diferentes números de nós utilizados e diferentes plataformas de armazenamento das
bases de dados (HD, SSD, NFS). As bases de dados pesquisadas correspondem a
um subconjunto representativo das disponíveis no sitio WEB do BLAST, cobrindo uma
variedade de dimensões (desde algumas dezenas de MBytes, até à centena de
GBytes) e contendo quer sequências de amino-ácidos (env_nr e nr), quer de
nucleótidos (drosohp. nt, env_nt, mito. nt, nt e patnt). Para as pesquisas foram 'usadas
sequências arbitrárias de 568 letras em formato FASTA, e adoptadas as opções por
omissão dos vários aplicativos BLAST. Salvo menção em contrário, os tempos de
execução considerados nas comparações e no cálculo de speedups são relativos à
primeira execução de uma pesquisa, não sendo assim beneficiados por qualquer
efeito de cache; esta opção assume um cenário real em que não é habitual que uma
mesma query seja executada várias vezes seguidas (embora possa ser re-executada,
mais tarde).
As principais conclusões do estudo comparativo realizado foram as seguintes:
- e necessário acautelar, à priori, recursos de armazenamento com capacidade
suficiente para albergar as bases de dados nas suas várias versões
(originais/compactadas, descompactadas e formatadas); no nosso cenário de teste a
coexistência de todas estas versões consumiu 600GBytes;
- o tempo de preparação (formataçâo) das bases de dados para posterior pesquisa
pode ser considerável; no nosso cenário experimental, a formatação das bases de
dados mais pesadas (nr, env_nt e nt) demorou entre 30m a 40m (para o BLAST), e
entre 45m a 55m (para o mpiBLAST);
- embora economicamente mais onerosos, a utilização de discos de estado sólido, em
alternativa a discos rígidos tradicionais, permite melhorar o tempo da formatação das
bases de dados; no entanto, os benefícios registados (à volta de 9%) ficam bastante
aquém do inicialmente esperado;
- o tempo de execução do BLAST é fortemente penalizado quando as bases de dados
são acedidas através da rede, via NFS; neste caso, nem sequer compensa usar vários
cores; quando as bases de dados são locais e estão em SSD, o tempo de execução
melhora bastante, em especial com a utilização de vários cores; neste caso, com 4
cores, o speedup chega a atingir 3.5 (sendo o ideal 4) para a pesquisa de BDs de
proteínas, mas não passa de 1.8 para a pesquisa de BDs de nucleótidos;
- o tempo de execução do mpiBLAST é muito prejudicado quando os fragmentos das
bases de dados ainda não se encontram nos nós do cluster, tendo que ser distribuídos
previamente à pesquisa propriamente dita; após a distribuição, a repetição das
mesmas queries beneficia de speedups de 14 a 70; porém, como a mesma base de
dados poderá ser usada para responder a diferentes queries, então não é necessário
repetir a mesma query para amortizar o esforço de distribuição;
- no cenário de teste, a utilização do mpiBLAST com 32+2 cores, face ao BLAST com
4 cores, traduz-se em speedups que, conforme a base de dados pesquisada (e
previamente distribuída), variam entre 2 a 5, valores aquém do máximo teórico de 6.5
(34/4), mas ainda assim demonstradores de que, havendo essa possibilidade,
compensa realizar as pesquisas em cluster; explorar vários cores) e com o gpuBLAST, realizada no nó com GPU (representativo
de uma workstation típica), permite aferir qual a melhor opção no caso de não serem
possíveis pesquisas em cluster; as observações realizadas indicam que não há
diferenças significativas entre o BLAST e o BLAST+; adicionalmente, o desempenho
do gpuBLAST foi sempre pior (aproximadmente em 50%) que o do BLAST e BLAST+,
o que pode encontrar explicação na longevidade do modelo da GPU usada;
- finalmente, a comparação da melhor opção no nosso cenário de teste, representada
pelo uso do mpiBLAST, com o recurso a pesquisa online, no site do BLAST5, revela
que o mpiBLAST apresenta um desempenho bastante competitivo com o BLAST
online, chegando a ser claramente superior se se considerarem os tempos do
mpiBLAST tirando partido de efeitos de cache; esta assunção acaba por se justa, Já
que BLAST online também rentabiliza o mesmo tipo de efeitos; no entanto, com
tempos de pequisa tão reduzidos (< 30s), só é defensável a utilização do mpiBLAST
numa infra-estrutura local se o objetivo for a pesquisa de Bds não pesquisáveis via
BLAS+ online
Las relaciones entre universidad y entidades externas en el marco de las fundaciones universidad-empresa
La casa de la reina Mariana de Austria durante el reinado de Felipe IV y el periodo de regencia
Practical study of bare metal virtualization solutions
With the hardware breakthroughs accomplished through the years, the idea of software defined hardware has become a reality. Hypervisors such as KVM, Xen, Hyper-V and ESXi enable the cloud of today, with hardware consolidation bringing a reduction in operating costs. In this scope, it is imperative to address the performance of all the different virtualization implementations, in order to discover any potential bottlenecks and bugs. In this work, the performance of all the prominent Type-1 virtualization platforms is analyzed, using guests representative of the Windows NT and Linux kernels, in the form of Windows 10 LTSB and Ubuntu Server 16.04 LTS. The effectiveness of the CPU scheduler of each hypervisor is put to the test, as well as the storage backend performance under multiple scenarios (iSCSI, NFS and local). In short, this project provides a snapshot of the current state of the virtualization market, covering CPU, Memory, 2D & 3D Graphics performance of oVirt, Proxmox, XenServer, Hyper-V and VMware Vsphere. All the benchmarks were executed using their own default settings, with some automation scripts, in order to accelerate the process and exclude variability as much
as possible. Among the selected benchmarks were: Passmark Performance Test 9 to benchmark Windows performance; Unixbench, providing a way to extrapolate the performance of Linux guests; (ez)FIO allowed in-depth analysis of filesystem performance across platforms. Concluding, there are a few generalizations that can
be made from the information gathered: XenServer, oVirt and Proxmox require the presence
of xentools/virtio in order to provide good I/O throughput; GPU passthrough provides native performance as
long as there is no resource overcommitment; VMware's Vsphere provides impressive CPU performance, edging out the competition, with 98% of the native performance; Hyper-V offers mediocre 2D Desktop performance (28% of the native performance), as such, it should not be used in VMs that provide interactive desktops; Similarly, Hyper-V's performance plunges in memory related workloads, when compared to the
remaining platforms and bare metal, with a mere 83%; The remote I/O results crown iSCSI as best performer, with double the performance of NFS; All the open source platforms (Proxmox, oVirt and XenServer) display
impressive remote I/O performance, in both iSCSI and NFS.info:eu-repo/semantics/publishedVersio
Evaluation of type-1 hypervisors on desktop-class virtualization hosts
System Virtualization has become a fundamental IT tool, whether it is type-2/hosted virtualization, mostly exploited by end-users in their personal computers, or type-1/bare metal, well established in IT departments and thoroughly used in modern datacenters as the very foundation of cloud computing. Though bare metal virtualization is meant to be deployed on server-grade hardware (for performance, stability and reliability reasons), properly configured desktop-class systems or workstations are often used as virtualization servers, due to their attractive performance/cost ratio. This paper presents the results of a study conducted on commodity virtualization servers, aiming to assess the performance of a representative set of the type-1 platforms mostly in use today: VMware ESXi, Citrix XenServer, Microsoft Hyper-V, oVirt and Proxmox. Hypervisor performance is indirectly measured through synthetic benchmarks performed on Windows 10 LTSB and Linux Ubuntu Server 16.04 guests: PassMark for Windows, UnixBench for Linux, and the cross-platform Flexible I/O Tester and iPerf3 benchmarks. The evaluation results may be used to guide the choice of the best type-1 platform (performance-wise), depending on the predominant guest OS, the performance patterns (CPUbound, IO-bound, or balanced) of that OS, its storage type (local/remote) and the required network-level performance.info:eu-repo/semantics/publishedVersio
Benchmarking of bare metal virtualization platforms on commodity hardware
In recent years, System Virtualization became a fundamental IT tool, whether it is type-2/hosted virtualization, mostly exploited by end-users in their personal computers, or type-1/bare metal, well established in IT departments and thoroughly used in modern datacenters as the very foundation of cloud computing. Though bare metal virtualization is meant to be deployed on server-grade hardware (for performance, stability and reliability reasons), properly configured desktop-class systems are often used as virtualization “servers”, due to their attractive performance/cost ratio. This paper presents the results of a study conducted on such systems, about the performance of Windows 10 and Ubuntu Server 16.04 guests, when deployed in what we believe are the type-1 platforms most in use today: VMware ESXi, Citrix XenServer, Microsoft Hyper-V, and KVM-based (represented by oVirt and Proxmox). Performance is measured using three synthetic benchmarks: PassMark for Windows, UnixBench for Ubuntu Server, and the cross-platform Flexible I/O Tester. The benchmarks results
may be used to choose the most adequate type-1 platform (performance-wise), depending on guest OS, its performance requisites (CPU-bound, IO-bound, or balanced) and its storage type (local/remote) used.info:eu-repo/semantics/publishedVersio
Extending heterogeneous applications to remote Co-processors with rOpenCL
In heterogeneous computing systems, general purpose CPUs are coupled with co-processors of different architectures, like GPUs and FPGAs. Applications may take advantage of this heterogeneous device ensemble to accelerate execution. However, developing heterogeneous applications requires specific programming models, under which applications unfold into code components targeting different computing devices. OpenCL is one of the main programming models for heterogeneous applications, set apart from others due to its openness, vendor independence and support for different co-processors. In the original OpenCL application model, a heterogeneous
application starts in a certain host node, and then resorts to the local co-processors attached to that host. Therefore, co-processors
at other nodes, networked with the host node, are inaccessible and cannot be used to accelerate the application. rOpenCL (remote
OpenCL) overcomes this limitation for a significant set of the OpenCL 1.2 API, offering OpenCL applications transparent access to remote devices through a TPC/IP based network. This paper presents the architecture and the most relevant implementation details of rOpenCL, together with the results of a preliminary set of reference benchmarks. These prove the stability of the current prototype and show that, in many scenarios, the network overhead is smaller than expected.info:eu-repo/semantics/publishedVersio
- …