Download to read offline
Uploaded byAbhishek Gupta
Gupta_Keynote_VTDC-3
HPC in the cloud provides opportunities to improve resource utilization and reduce costs through elasticity and pay-as-you-go models. However, HPC applications often perform poorly in clouds due to communication overhead, multi-tenancy, and heterogeneity. Bridging this gap requires making clouds more HPC-aware through application-aware scheduling, dynamic load balancing, and enabling malleable jobs. This allows improving both HPC performance and cloud utilization.
Gupta_Keynote_VTDC-3
- 1. EFFICIENT HIGH PERFORMANCE COMPUTINGIN THE CLOUD KEYNOTE, VTDC’15 Dr. Abhishek Gupta PhD, University of Illinois at Urbana Champaign gupta59@Illinois.edu 06/15/20151
- 2.
- 3. HPC 3 Aggregating computing power Computationally intensive applications HPCtraditionally restricted to a niche segment - few influential labs. Why?
- 4. 4 What is CloudComputing?
- 5. Cloud Computing Physical or virtualcomputing infrastructure, processing, storage, network. Examples - Amazon EC2, HP cloud Computing platforms including programming language execution framework, database, OS. Examples - Google App Engine, Microsoft Azure Applications running on cloud infrastructure, Examples - Google Apps, Salesforce Essential characteristics Deployment Models Service Models
- 6. 6 What do wemean by HPC +/in Cloud
- 7. 7 Marriage of twovery different computing paradigm Learn from best known principles and apply to each other
- 8. HPC AND CLOUDS(1) 8 Computationally intensive applications HPC in public clouds: Cloud as a solution to HPC users’ needs Public Clouds
- 9. HPC AND CLOUDS(2) 9 Computationally intensive applications Custom “HPC-clouds” Customized HPC Clouds
- 10. HPC AND CLOUDS(3) 10 Renting Supercomputer on a cloud model - virtualization, elasticity, pay-as-you-go model Computationally intensive applications Cloud technologies on existing HPC infrastructure
- 11. HPC AND CLOUDS(4) 11 Computationally intensive applications Hybrid HPC+cloud infrastructure – bursting to cloud Public Clouds
- 12. HPC AND CLOUDS HPC in public clouds Cloud as a solution to HPC users’ needs HPC as a service – ubiquity Cloud technologies on existing HPC infrastructure Virtualization, elasticity, pay-as-you-go model Renting Supercomputer on a cloud model Custom “HPC-clouds” Hybrid HPC+cloud – bursting to cloud 12 Public cloud very appealing for HPC users, why?
- 13. MOTIVATION: WHY CLOUDSFOR HPC ? Rent vs. own, pay-as-you-go No startup/maintenance cost, cluster create time Elastic resources No risk e.g. in under-provisioning Prevents underutilization Benefits of virtualization Flexibility and customization Security and isolation Migration and resource control 13 Cloud for HPC: A cost-effective and timely solution? Multiple providers – Infrastructure as a Service
- 14. RESEARCH QUESTIONS How: Bridge HPC-cloudgap Improve HPC performance Improve cloud utilization=> Reduce cost 14 What (applications), why (benefits), who (users) HPC in cloud
- 15.
- 16. 16 Plants (HPC applications) TypicalHPC platformsTypical cloud FlowersRotten plants Traditional Belief
- 17. 17 Typical HPC platformsTypical cloud FlowersSome plantsmay flourish Our Belief Plants (HPC applications)
- 18. 18 Typical HPC platformsTypical cloud Flowers Make HPC Cloud-AwarePlants (HPC applications)
- 19.
- 20. OUTLINE Performance analysis HPC cloud divide Bridging the gap between HPC and cloud HPC-aware clouds Application-aware cloud scheduler and VM consolidation Cloud-aware HPC Dynamic load balancing: improve HPC performance Parallel runtime for malleable jobs: improve utilization Models, cost analysis and multiple platforms in cloud Lessons, conclusions, impact, and future work 20
- 21. EXPERIMENTAL TESTBED ANDAPPLICATIONS NAS Parallel Benchmarks class B (NPB3.3-MPI) NAMD - Highly scalable molecular dynamics ChaNGa - Cosmology, N-body Sweep3D - A particle in ASCI code Jacobi2D - 5-point stencil computation kernel Nqueens - Backtracking state space search Platform/ Resource Ranger (TACC) Taub (UIUC) Open Cirrus (HP) HPC-optimized Cloud (EC2-CC) Private Cloud Public Cloud Network Infiniband (10Gbps) Voltaire QDR Infiniband 10 Gbps Ethernet internal; 1 Gbps Ethernet x-rack Xen HVM hypervisor, same placement group (10Gbps Ethernet) Emulated network KVM hypervisor (1Gbps Ethernet) Emulated network KVM hypervisor (1Gbps Ethernet) 21
- 22. PERFORMANCE (1/3) Some applicationscloud-friendly 22
- 23. PERFORMANCE (2/3) Some applicationsscale till 16-64 cores 23 NAMD scales on EC2-CC
- 24. PERFORMANCE (3/3) Some applicationscannot survive in cloud 24
- 25. Co-relation: communicationand performance Communication-intensive applications perform poorly in clouds CC2-EC2: Bandwidth sensitive ok, latency-sensitive not ok Cloud message latencies (150-200μs) vs. supercomputers (4μs) Bandwidths off by 2 orders of magnitude (10Gbps vs. 100Mbps) Except : CC2-EC2 bandwidth comparable to supercomputers Commodity network + virtualization overhead (e.g. ~100μs latency) Thin VMs, Containers, CPU affinity Grain size control and larger problem sizes Noise and performance variability in cloud Similar network performance for public and private cloud. Then, why does public cloud perform worse? Scheduling policy allowed multi-tenancy Infrastructure was heterogeneous PERFORMANCE ANALYSIS 25
- 26. MULTI-TENANCY AND HETEROGENEITY CHALLENGE Multi-tenancy: Cloud providers run profitable business by improving utilization of underutilized resources Cluster-level by serving large number of users, Server-level by consolidating VMs of complementary nature Heterogeneity: Cloud economics is based on: Creation of a cluster from existing pool of resources and Incremental addition of new resources. 26 Heterogeneity and multi-tenancy intrinsic in clouds, driven by cloud economics but For HPC, one slow processor => all underutilized processors
- 27. HPC-CLOUD DIVIDE SUMMARY 27 Performance Dedicated execution Homogeneity HPC-optimized interconnects, OS Not cloud-aware Service, cost, utilization Multi-tenancy Heterogeneity Commodity network, virtualization Not HPC-aware HPC Cloud Mismatch: HPC requirements and cloud characteristics. How to bridge this gap? A. Gupta et al. “The Who, What, Why and How of High Performance Computing in the Cloud” in IEEE CloudCom 2013 Best Paper
- 28.
- 29. VM CONSOLIDATION FORHPC IN CLOUD (1) 29 HPC performance vs. Resource utilization (prefers dedicated execution) (shared usage in cloud)? Up to 23% savings Can we improve utilization with acceptable performance penalty? How much interference?
- 30. VM CONSOLIDATION FORHPC IN CLOUD (2) 30 Experiment: Shared mode (2 apps on each node – 2 cores each on 4 core node) performance normalized wrt. dedicated mode Challenge: Interference EP = Embarrassingly Parallel LU = LU factorization IS = Integer Sort ChaNGa = Cosmology 4 VM per app High is better Careful co-locations can actually improve performance. Why? Correlation : LLC misses/sec and shared mode performance. Scope
- 31. HPC-AWARE CLOUD SCHEDULERS 1.Characterize applications along two dimensions Cache intensiveness and network sensitivity 2. Co-locate applications with complementary profiles Dedicated execution, topology- and hardware-awareness for extremely tightly-coupled HPC applications ~20% improvement Multi-dimensional Online Bin Packing: Memory, CPU Dimension aware heuristic Cross application interference aware 45% performance improvement, interference < 8%, (OpenStack) But, what about resource utilization? Improve throughput by 32.3% (simulation using CloudSim) 31A. Gupta, L. Kale, D. Milojicic, P. Faraboschi, and S. Balle, “HPC-Aware VM Placement in Infrastructure Clouds ,” at IEEE Intl. Conf. on Cloud Engineering IC2E ’13
- 32. Cloud-Aware HPC in Cloud OpportunitiesChallenges/Bottlenecks Heterogeneity Cloud-aware HPCLoad Balancer Malleable Jobs (Runtime Shrink/Expand) Multi- tenancy Elasticity Next … 32
- 33. HETEROGENEITY AND MULTI-TENANCY 33 Multi-tenancy => Dynamic heterogeneity Interference random and unpredictable Challenge: Running in VMs makes it difficult to determine if (and how much of) the load imbalance is Application-intrinsic or Caused by extraneous factors such as interference Idle times VMs sharing CPU: application functions appear to be taking longer time Existing HPC load balancers ignore effect of extraneous factors Time CPU/VM
- 34. CHARM++ AND LOADBALANCING Migratable objects (chares) Object-based over-decomposition Background/ Interfering VM running on same host Objects (Work/Data Units) Load balancer migrates objects from overloaded to under loaded VM Physical Host 1 Physical Host 2 HPC VM1 HPC VM2 34
- 35. CLOUD-AWARE LOAD BALANCER 35 •CPUfrequency estimation •Periodic instrumentation of task times and interference •Periodic task redistribution
- 36. LOAD BALANCING APPROACH Allprocessors should have load close to average load Average load depends on task execution time and overhead Overhead is the time processor is not executing tasks and not in idle mode. Charm++ LB database from /proc/stat file Tlb: wall clock time between two load balancing steps, Ti: CPU time consumed by task i on VCPU p To get a processor-independent measure of task loads, normalize the execution times to number of ticks 36
- 37. RESULTS: STENCIL3D 37 Periodically measuringidle time and migrating load away from time-shared VMs works well in practice. • OpenStack on Open Cirrus test bed (3 types of processors), KVM, virtio-net, VMs: m1.small, vcpupin for pinning VCPU to physical cores • Sequential NPB-FT as interference, Interfering VM pinned to one of the cores that the VMs of our parallel runs use Low is better Multi-tenancy awareness Heterogeneity awareness
- 38. RESULTS: IMPROVEMENTS BYLB 38 Heterogeneity and Interference – one Slow node, hence four Slow VMs, rest Fast, one interfering VM (on a Fast core) which starts at iteration 50. High is better Up to 40% benefits, evaluated till 64 cores. Larger scale? A. Gupta, O. Sarood, L. Kale, and D. Milojicic, “Improving HPC Application Performance in Cloud through Dynamic Load Balancing,” at IEEE/ACM CCGRID ’13
- 39. 39 SCALABILITY RESULTS ONDISTEM CLOUD Good scaling with runtime-triggered MetaLB approach, MetaLB: Adaptive with low load balancing overhead LeanMD Low is better
- 40. OUTLINE Performance analysis HPC cloud divide Bridging the gap between HPC and cloud HPC-aware clouds Application-aware cloud scheduler and VM consolidation Cloud-aware HPC Dynamic load balancing: improve HPC performance Parallel runtime for malleable jobs: improve utilization Models, cost analysis and multiple platforms in cloud Lessons, conclusions, impact, and future work 40
- 41. MALLEABLE PARALLEL JOBS Dynamic shrink/expand number of processors Twofold merit in the context of cloud computing. Cloud provider perspective Better system utilization, response time, and throughput Honor job priorities Cloud user perspective: Dynamic pricing offered by cloud providers, such as Amazon EC2 Better value for the money spent based on priorities and deadlines Applicable beyond clouds 41 Malleable jobs have tremendous but unrealized potential, What do we need to enable malleable HPC jobs?
- 42. Scheduling Policy Engine Job Queue NewJobs Adaptive Job Scheduler Adaptive Resource Manager Adaptive/Malleable Parallel Runtime System Node Scheduler Launch Monitor Shrink Expand Cluster Shrink Ack. Expand Ack. Decisions Cluster State Changes Execution Engine Nodes We will focus on Malleable Parallel Runtime COMPONENTS OF A MALLEABLE JOBS SYSTEM 42
- 43. MALLEABLE RTS SUMMARY 43 Object migration, checkpoint-restart, Linux shared memory, load balancing, implemented atop Charm++ Adapts load distribution well on rescale (Efficient) 2k->1k in 13s, 1k->2k in 40s (Fast) Scales well with core count and problem size (Scalable) Little application programmer effort (Low-effort) 4 mini-applications: Stencil2D, LeanMD, Wave2D, Lulesh 15-37 SLOC, For Lulesh, 0.4% of original SLOC Can be used in most systems (Practical) What are the benefits for HPC in cloud? A. Gupta, B. Acun, O. Sarood, and L. Kale “Towards Realizing the Potential of Malleable Parallel Jobs,” IEEE HiPC ’14
- 44. APPLICABILITY TO HPCIN CLOUD 44 Provider perspective Improve utilization: malleable jobs + adaptive job scheduling Stampede interactive mode as cluster for demonstration User Perspective Price-sensitive rescale in spot markets
- 45. PROVIDER PERSPECTIVE: CASESTUDY 45 •5 jobs •Stencil2D, 1000 iterations each •4-16 nodes, 16 cores per node •16 nodes total in cluster •Dynamic Equipartitioning for malleable jobs •FCFS for rigid jobs Improved utilization Idle nodes Job 1 shrinks Job 5 expands Reduced makespan Reduced response time Time Rigid Malleable Cluster State
- 46. USER PERSPECTIVE: PRICE-SENSITIVERESCALE IN SPOT MARKETS 46 Our solution: keep two pools Static: certain minimum number of reserved instances Dynamic: price-sensitive rescale over the spot instance pool Expand when the spot price falls below a threshold Shrink when it exceeds the threshold. Amazon EC2 spot price variation: cc2.8xlarge instance Jan 7, 2013 Spot markets Bidding based Dynamic price Set high bid to avoid termination (e.g. $1.25) Pay whatever the spot price or no progress Can I control the price I pay, and still make progress?
- 47. 47 Dynamic shrinking andexpansion of HPC jobs can enable lower effective price in cloud spot markets USER PERSPECTIVE: PRICE-SENSITIVE RESCALE IN SPOT MARKETS No rescale: $16.65 for 24 hours With rescale: freedom to select price threshold Usable hours may be reduced Price Calculation
- 48. OUTLINE Performance analysis HPC cloud divide Bridging the gap between HPC and cloud HPC-aware clouds Application-aware cloud scheduler and VM consolidation Cloud-aware HPC Dynamic load balancing: improve HPC performance Parallel runtime for malleable jobs: improve utilization Models, cost analysis and multiple platforms in cloud Lessons, conclusions, impact, and future work 48
- 49. MODELS FOR HPCIN CLOUD Cloud as substitute for supercomputers for all HPC applications? (Past work) Supercomputers defeat cloud in raw performance Some HPC applications just do not scale in cloud Cloud complement supercomputers? (Our position) User perspective Lower cost of running in cloud vs. supercomputer? For some applications? Provider perspective Hybrid cloud supercomputer approach Use underutilized resource “good enough” for a job Reduce wait time and improve throughput 49
- 50. 50 USER PERSPECTIVE: HPC-CLOUDECONOMICS Interesting cross-over points when considering cost. Best platform depends on scale, budget. Time constraint Choose this Cost constraint Choose this Low is better Cost = instance price ($ per core-hour) × P × Time Low is better NAMD Scaling Right to left
- 51. 51 Cost = Chargingrate($ per core-hour) × P × Time Low is better •Best platform depends on application characteristics. •Automated platform selection simulation: up to 60% cost reduction at 10-15% performance penalty A. Gupta et al., “Exploring the Performance and Mapping of HPC Applications to Platforms in the cloud,” short paper in HPDC ’12. New York, NY, USA: ACM, 2012 USER PERSPECTIVE: HPC-CLOUD ECONOMICS 51
- 52. 52 PROVIDER PERSPECTIVE: MULTI-PLATFORMAPPROACH Can clouds complement supercomputer? Is it a feasible model? How to map jobs? Use Heuristics Job Ji = (t,p), tn= f(n,p), n∈N platforms Mapping jobs to platforms
- 53. STATIC APPLICATION-AWARE HEURISTICS 53 Red:Slowdown Light blue: No slowdown Scale (number of cores) Scale (number of cores)
- 54. STATIC APPLICATION-AWARE HEURISTICS 54 Red:Slowdown Light blue: No slowdown AppPartition SupercomputerClusterCloud
- 55. STATIC APPLICATION-AWARE HEURISTICS 55 Red:slowdown Light blue: No slowdown Supercomputer Cluster Cloud ScalePartition
- 56. 56 MULTI-PLATFORM MAPPING BENEFITS Highload: runtimes scaled up by 2X.Normal load Significant improvement in throughput (6X) and makespan (1.8X), attributed to improved response time and runtime CloudSim: 3 datacenters – supercomputer, cluster, cloud (256 cores each) Job logs from Parallel Workload Archive, first 1000 jobs Each job record: (job’s arrival time, number of cores (P), runtime on supercomputer, application name assigned randomly) Steeper is better A. Gupta et al., “Evaluating and Improving the Performance and Mapping of HPC in Cloud,” IEEE TCC Special issue.
- 57. KEY TAKEAWAYS Evaluationand Mapping Lightweight virtualization necessary to remove overheads Characterization for complex applications non-trivial but economic benefits are substantial (e.g. multi-platforms) HPC-aware clouds Although counterintuitive, HPC users and cloud providers can achieve win-win by consolidating VMs using smart co-locations Cloud schedulers need knowledge of application characteristics Cache, communication, HPC vs. non-HPC Cloud-aware HPC Heterogeneity and multi-tenancy challenge for HPC Dynamic environment in clouds necessitate adaptive HPC RTS 57
- 58. CONCLUSIONS (1) 58 Computationally intensive applications HPCin current clouds is suitable for some but not all applications – needs characterization and mapping Public Clouds
- 59. CONCLUSIONS (2) 59 Feasible tobridge the gap between HPC and cloud – HPC-aware clouds and cloud-aware HPC Public Clouds
- 60. CONCLUSIONS HPC in currentclouds is suitable for some but not all applications and can be made more efficient using intelligent mapping of applications to platforms, HPC-aware cloud scheduling, and cloud-aware HPC execution. HPC in the cloud for some applications not all Application characteristics and scale, performance-cost tradeoffs Intelligent mapping of applications to platforms Bridge the gap between HPC and cloud HPC-aware cloud scheduling Application-aware scheduling Characterization and interference-aware consolidation Cloud-aware HPC execution Heterogeneity and Multi-tenancy aware load balancing Malleable jobs Challenges and opportunities, cloud provider vs. cloud user 60
- 61. OPEN PROBLEMS ANDDIRECTIONS Linux containers, Docker for packaging HPC applications Multi-platforms, mapping, and models Application characterization HPC-as-a-Service and multi-level cloud scheduling system Supercomputer using a cloud model HPC-aware clouds Interaction between application and resource manager Job interference categorization Security for HPC in cloud Cloud-aware HPC Communication optimizations in HPC runtime Adaptive communication-aware load balancing 61
- 62. RESOURCES Amazon EC2,Microsoft Azure, Grid 5000, … Docker, Openstack MPI, Charm++ http://charm.cs.uiuc.edu/research/cloud gupta59@Illinois.edu , LinkedIn 62
- 63. THANKS VTDC Organizers Dr. Laxmikant V. Kale, UIUC Dr. Dejan Milojicic, HP Labs. 63
- 64. REFERENCES A. Guptaet al., “Evaluating and Improving the Performance and Mapping of HPC in Cloud,” IEEE TCC Special issue A. Gupta et al., “The Who, What, Why and How of High Performance Computing Applications in the Cloud,” Best paper at IEEE CloudCom 2013 A. Gupta, O. Sarood, L. Kale, and D. Milojicic, “Improving HPC Application Performance in Cloud through Dynamic Load Balancing,” accepted at IEEE/ACM CCGRID ’13 A. Gupta, L. Kale, D. Milojicic, P. Faraboschi, and S. Balle, “HPC-Aware VM Placement in Infrastructure Clouds ,” at IEEE Intl. Conf. on Cloud Engineering IC2E ’13 A. Gupta et al., “Exploring the Performance and Mapping of HPC Applications to Platforms in the cloud,” short paper in HPDC ’12. New York, NY, USA: ACM, 2012 A. Gupta et al., “Realizing the Potential of Malleable Parallel Jobs,” HiPC 2014 A. Gupta and D. Milojicic, “Evaluation of HPC Applications on Cloud,” in Open Cirrus Summit Best Student Paper, Atlanta, GA, Oct. 2011 A. Gupta, D. Milojicic, and L. Kale, “Optimizing VM Placement for HPC in Cloud,” in Workshop on Cloud Services, Federation and the 8th Open Cirrus Summit, San Jose, CA, 2012 A. Gupta and L. V. Kale, “Towards Efficient Mapping, Scheduling, and Execution of HPC Applications on Platforms in Cloud,” short paper and poster at 27th International Parallel and Distributed Processing Symposium(IPDPS) Ph.D Forum’13 Best PhD Forum award O. Sarood, A. Gupta, and L. V. Kale, “Cloud Friendly Load Balancing for HPC Applications: Preliminary Work,” in 41st Intl. Conf. on Parallel Processing Workshops (ICPPW), 2012 64
Editor's Notes
- #3 High Performance Computing (HPC) refers to the practice of aggregating computing power to deliver much higher performance than typical desktop/laptop computers with the goals of solving computationally intensive applications in science, engineering, or business. HPC has traditionally been restricted to a niche segment comprising scientists who use super- computers at national laboratories to enhance human knowledge by understanding how the universe works. They use the tremendous computational power to understand how scientic phenomena operate and evolve in scientic elds such as cosmology, molecular dynamics, quantum chemistry, climate, and human genetics. More recently, HPC is also being used in industry for business and analytics. According to November 2013 top500 list, 56.4% of top 500 supercomputing systems are used by industry
- #4 High Performance Computing (HPC) refers to the practice of aggregating computing power to deliver much higher performance than typical desktop/laptop computers with the goals of solving computationally intensive applications in science, engineering, or business. HPC has traditionally been restricted to a niche segment comprising scientists who use super- computers at national laboratories to enhance human knowledge by understanding how the universe works. They use the tremendous computational power to understand how scientic phenomena operate and evolve in scientic elds such as cosmology, molecular dynamics, quantum chemistry, climate, and human genetics. More recently, HPC is also being used in industry for business and analytics. According to November 2013 top500 list, 56.4% of top 500 supercomputing systems are used by industry
- #6 What is cloud, what is HPC A model for provinding computing as a service .. Shared pool of resources.. Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models.
- #9 High Performance Computing (HPC) refers to the practice of aggregating computing power to deliver much higher performance than typical desktop/laptop computers with the goals of solving computationally intensive applications in science, engineering, or business. HPC has traditionally been restricted to a niche segment comprising scientists who use super- computers at national laboratories to enhance human knowledge by understanding how the universe works. They use the tremendous computational power to understand how scientic phenomena operate and evolve in scientic elds such as cosmology, molecular dynamics, quantum chemistry, climate, and human genetics. More recently, HPC is also being used in industry for business and analytics. According to November 2013 top500 list, 56.4% of top 500 supercomputing systems are used by industry
- #10 High Performance Computing (HPC) refers to the practice of aggregating computing power to deliver much higher performance than typical desktop/laptop computers with the goals of solving computationally intensive applications in science, engineering, or business. HPC has traditionally been restricted to a niche segment comprising scientists who use super- computers at national laboratories to enhance human knowledge by understanding how the universe works. They use the tremendous computational power to understand how scientic phenomena operate and evolve in scientic elds such as cosmology, molecular dynamics, quantum chemistry, climate, and human genetics. More recently, HPC is also being used in industry for business and analytics. According to November 2013 top500 list, 56.4% of top 500 supercomputing systems are used by industry
- #11 High Performance Computing (HPC) refers to the practice of aggregating computing power to deliver much higher performance than typical desktop/laptop computers with the goals of solving computationally intensive applications in science, engineering, or business. HPC has traditionally been restricted to a niche segment comprising scientists who use super- computers at national laboratories to enhance human knowledge by understanding how the universe works. They use the tremendous computational power to understand how scientic phenomena operate and evolve in scientic elds such as cosmology, molecular dynamics, quantum chemistry, climate, and human genetics. More recently, HPC is also being used in industry for business and analytics. According to November 2013 top500 list, 56.4% of top 500 supercomputing systems are used by industry
- #12 High Performance Computing (HPC) refers to the practice of aggregating computing power to deliver much higher performance than typical desktop/laptop computers with the goals of solving computationally intensive applications in science, engineering, or business. HPC has traditionally been restricted to a niche segment comprising scientists who use super- computers at national laboratories to enhance human knowledge by understanding how the universe works. They use the tremendous computational power to understand how scientic phenomena operate and evolve in scientic elds such as cosmology, molecular dynamics, quantum chemistry, climate, and human genetics. More recently, HPC is also being used in industry for business and analytics. According to November 2013 top500 list, 56.4% of top 500 supercomputing systems are used by industry
- #13 Cloud-aware HPC runtime HPC-aware Clouds
- #15 Prior work focus only on perf eval.. We take holistic perspective.. . Doe Megellan project Cloud provider + User perspective HPC-aware Cloud + Cloud-aware HPC Performance achieved on cloud vs. supercomputer? The bigger and more important question: why and who should choose (or not choose) cloud for HPC, for what applications, and how should cloud be used for HPC? 2 ways how : improve performance or reduce cost by improving utilization
- #21 Increase resource util cost savings They appear to be conflicting but as we will see, we can actually do good on both Cloud offerings use application-agnostic VM placement Poor performance of HPC apps in Cloud Cost savings potential through application aware consolidation
- #22 Todo: Change table, keep only relevant aspects which I will discuss Details in report
- #23 Execution Time vs. Number of cores (strong scaling for all except Sweep3D) for different applications. All applications scale very well on Taub and Ranger and moderately well on Open Cirrus. On Private Cloud, IS does not scale at all, LU and NAMD stop scaling after 32 cores whereas EP, Jacobi2D and NQueens scale well. Public cloud exhibits poor scalability. For NPB, we present results for only Embarrassingly parallel (EP), LU solver (LU), and Integer sort (IS) benchmarks due to space constraints. The first observation is the difference in sequential performance: Ranger takes almost twice as long as the other platforms, primarily because of the older and slower processors. The slope of the curve shows how the applications scale on different platforms. Despite the poor sequential speed, Ranger’s performance crosses Open Cirrus, private cloud and public cloud for some applications at around 32 cores, yielding a much more linearly scalable parallel performance. We investigated the reasons for better scalability of these applications on Ranger using application profiling, performance tools and microbenchmarking the platforms and found that network performance is a dominant factor (section IV-A). While all applications scale well on Ranger and Taub, some applications, especially the NPB IS (Integer Sort) benchmark, fail to scale on the clouds and Open Cirrus. IS is a communication intensive benchmark and involves data reshuffling and permutation operations for sorting. Sweep3D also exhibits poor weak scaling after 4–8 cores on cloud. Other communication intensive applications such as LU, NAMD and ChaNGa also stop scaling on private cloud around 32 cores, but do reasonably well on Open Cirrus, because of the impact of virtualization on network performance (which we confirm below). The remaining applications, EP, Jacobi2D, and NQueens, scale well on all the platforms up to 256 cores except the public cloud where most applications suffer a hit above 4 cores. On public cloud, we used VM instances with 4 virtual cores, hence there is no inter-VM communication up to 4 cores, resulting in good parallel scaling and a sudden performance penalty as the communication starts happening across VMs. Split into 3 sub-plots. -- apps doing well on all -- IS -- all except public and private (and diff bw public, private) ---- what are the reasons?? Comm – why ?? (we went ahead?? – what factors – thin VM, … amazon ec2 clouds…) – extensive researched… Public and private? … not much has been done for these?? – attribute this to multi-tenancy, scheduling.. Cost
- #24 Execution Time vs. Number of cores (strong scaling for all except Sweep3D) for different applications. All applications scale very well on Taub and Ranger and moderately well on Open Cirrus. On Private Cloud, IS does not scale at all, LU and NAMD stop scaling after 32 cores whereas EP, Jacobi2D and NQueens scale well. Public cloud exhibits poor scalability. For NPB, we present results for only Embarrassingly parallel (EP), LU solver (LU), and Integer sort (IS) benchmarks due to space constraints. The first observation is the difference in sequential performance: Ranger takes almost twice as long as the other platforms, primarily because of the older and slower processors. The slope of the curve shows how the applications scale on different platforms. Despite the poor sequential speed, Ranger’s performance crosses Open Cirrus, private cloud and public cloud for some applications at around 32 cores, yielding a much more linearly scalable parallel performance. We investigated the reasons for better scalability of these applications on Ranger using application profiling, performance tools and microbenchmarking the platforms and found that network performance is a dominant factor (section IV-A). While all applications scale well on Ranger and Taub, some applications, especially the NPB IS (Integer Sort) benchmark, fail to scale on the clouds and Open Cirrus. IS is a communication intensive benchmark and involves data reshuffling and permutation operations for sorting. Sweep3D also exhibits poor weak scaling after 4–8 cores on cloud. Other communication intensive applications such as LU, NAMD and ChaNGa also stop scaling on private cloud around 32 cores, but do reasonably well on Open Cirrus, because of the impact of virtualization on network performance (which we confirm below). The remaining applications, EP, Jacobi2D, and NQueens, scale well on all the platforms up to 256 cores except the public cloud where most applications suffer a hit above 4 cores. On public cloud, we used VM instances with 4 virtual cores, hence there is no inter-VM communication up to 4 cores, resulting in good parallel scaling and a sudden performance penalty as the communication starts happening across VMs. Split into 3 sub-plots. -- apps doing well on all -- IS -- all except public and private (and diff bw public, private) ---- what are the reasons?? Comm – why ?? (we went ahead?? – what factors – thin VM, … amazon ec2 clouds…) – extensive researched… Public and private? … not much has been done for these?? – attribute this to multi-tenancy, scheduling.. Cost
- #25 Execution Time vs. Number of cores (strong scaling for all except Sweep3D) for different applications. All applications scale very well on Taub and Ranger and moderately well on Open Cirrus. On Private Cloud, IS does not scale at all, LU and NAMD stop scaling after 32 cores whereas EP, Jacobi2D and NQueens scale well. Public cloud exhibits poor scalability. For NPB, we present results for only Embarrassingly parallel (EP), LU solver (LU), and Integer sort (IS) benchmarks due to space constraints. The first observation is the difference in sequential performance: Ranger takes almost twice as long as the other platforms, primarily because of the older and slower processors. The slope of the curve shows how the applications scale on different platforms. Despite the poor sequential speed, Ranger’s performance crosses Open Cirrus, private cloud and public cloud for some applications at around 32 cores, yielding a much more linearly scalable parallel performance. We investigated the reasons for better scalability of these applications on Ranger using application profiling, performance tools and microbenchmarking the platforms and found that network performance is a dominant factor (section IV-A). While all applications scale well on Ranger and Taub, some applications, especially the NPB IS (Integer Sort) benchmark, fail to scale on the clouds and Open Cirrus. IS is a communication intensive benchmark and involves data reshuffling and permutation operations for sorting. Sweep3D also exhibits poor weak scaling after 4–8 cores on cloud. Other communication intensive applications such as LU, NAMD and ChaNGa also stop scaling on private cloud around 32 cores, but do reasonably well on Open Cirrus, because of the impact of virtualization on network performance (which we confirm below). The remaining applications, EP, Jacobi2D, and NQueens, scale well on all the platforms up to 256 cores except the public cloud where most applications suffer a hit above 4 cores. On public cloud, we used VM instances with 4 virtual cores, hence there is no inter-VM communication up to 4 cores, resulting in good parallel scaling and a sudden performance penalty as the communication starts happening across VMs. Split into 3 sub-plots. -- apps doing well on all -- IS -- all except public and private (and diff bw public, private) ---- what are the reasons?? Comm – why ?? (we went ahead?? – what factors – thin VM, … amazon ec2 clouds…) – extensive researched… Public and private? … not much has been done for these?? – attribute this to multi-tenancy, scheduling.. Cost
- #26 ExtremeHPC: Extremely tightly coupled or topology sensitive applications for which the best will be to provide dedicated nodes, example – IS. SyncHPC: Sensitive to interference, but less compared to ExtremeHPC and can sustain small degree of interference to get consolidation benefits, examples – LU, ChaNGa. AsyncHPC: Asynchronous (and less communication sensitive) and can sustain more interference than SyncHPC, examples – EP, MapReduce applications. NonHPC: Do not perform any communication, can sustain more interference, and can be placed on heterogeneous hardware, example – Web applications.
- #27 Heterogeneity, multi-tenancy are intrinsic from cost point of view but they result in perf degradation… so then how does economics work for hpc –clouds.. We evaluated the cost of running apps on cloud vs sc..
- #29 Cloud offerings use application-agnostic VM placement Poor performance of HPC apps in Cloud Cost savings potential through application aware consolidation
- #30 Challenge: Cross-Application Interference, Sensitivity to network topology Sensitivity to heterogeneity -- cloud economics wants resource packing.. Scope: Improved Resource Utilization Amazon EC2 – pack cluster compute and High Memory Instance = 23% cost savings
- #31 Co-relation between LLC misses/sec and shared mode perf. Apps with high LLC misses/s benefit when sharing node with apps with low LLC misses/s – e.g. LU Apps with low LLC misses/s marginally affected when sharing node with apps with high LLC misses/s e.g. EP But what about IS? IS is network-intensive, so local vs. remote dominates
- #32 ExtremeHPC: Extremely tightly coupled or topology sensitive applications for which the best will be to provide dedicated nodes, example – IS. SyncHPC: Sensitive to interference, but less compared to ExtremeHPC and can sustain small degree of interference to get consolidation benefits, examples – LU, ChaNGa. AsyncHPC: Asynchronous (and less communication sensitive) and can sustain more interference than SyncHPC, examples – EP, MapReduce applications. NonHPC: Do not perform any communication, can sustain more interference, and can be placed on heterogeneous hardware, example – Web applications.
- #34 Existing LB do not consider extraneous factors Heterogeneity-awareness: significant performance improvement for HPC in cloud. Besides the static heterogeneity, multi-tenancy in cloud introduces dynamic heterogeneity, which is random and unpredictable. Poor performance of tightly-coupled iterative HPC applications. To demonstrate its severity, we conducted a simple experiment where we ran a tightly-coupled 5-point stencil benchmark, referred to as Stencil2D (2K 2K matrix), on 8-VMs, each with a single virtual core (VCPU), pinned to a different physical core of 4-core nodes. More details of our experimental setup and benchmarks are given in Section V. To study the impact of heterogeneity, we ran this benchmark in 2 cases - first, we used two physical nodes of same fast (3.00 GHz) processor type (Figure 1a) and second, we used two physical nodes with different processor types – fast (3.00 GHz) and slow (2.13 GHz) (Figure 1b). In the context of cloud, the execution environment depends on VM to physical machine mapping, which makes it (a) dynamic and (b) inconsistent across multiple runs. Hence, would be inefficient. Most existing dynama static allocation of compute tasks to parallel processes ic load balancing techniques operate based exclusively on the imbalance internal to the application, whereas in cloud, the imbalance might be due to the effect of extraneous factors. These factor originate from two characteristics, which are intrinsic to cloud: 1) Heterogeneity: Cloud economics is based on the creation of a cluster from existing pool of resources and incremental addition of new resources. While doing this, homogeneity is lost. 2) Multi-tenancy: Cloud providers run a profitable business by improving utilization of underutilized resources. This is achieved at cluster-level by serving large number of users, and at server-level by consolidating VMs of complementary nature (such as memory- and computeintensive) on same server. Hence, multi-tenancy can be at resource-level (memory, CPU), node-level, rack-level, zone-level, or data center level.
- #35 Charm++ is a perfect match for our technique. Its object based over-decomposition coupled with migrateability of objects allows us to trasnfer tasks to load balance the application Time logging of task, provided by charm++, is also an essential part of our scheme. We use these times to come up with decisions about which tasks to migrate in order to restore load balance.
- #37 The main challenge is that the CPU time may include the time taken by interfering VM, so they may be inaccurate. P is the total number of VCPUs, Np is the number of tasks assigned to VCPU p, ti is the CPU time consumed by task i running on VCPU p, fp is the frequency for VCPU p estimated using the loop in Figure 2, and Op is the total background load for VCPU p. normalize the execution times to number of ticks by multiplying the execution times for each task and the overhead to the estimated VCPU frequency. The conversion from CPU time to ticks is performed to get a processor-independent measure of task loads, which is necessary for balancing load across heterogeneous configuration, where the same task can take different time when executing on a different CPU.
- #38 To understand the effect of our load balancer under heterogeneity and interference, we ran 500 iterations of Stencil2D on 32 VMs (8 physical nodes – one Slow, rest Fast), and plotted the iteration time (execution time of an iteration) vs. iteration number in Figure 3. In this experiment, we started the job in interfering VM after 100 iterations of parallel job had completed. Load balancing was performed after every 20 steps, which manifests itself as spikes in the iteration time every 20th step. We report execution times averaged across three runs and use wall clock time, which includes the time taken for object migration. The LB curve starts to show benefits as we reach 100 iterations, due to heterogeneity-aware load balancing. After 100 iterations, interfering job starts. When the load balancer kicks in, it restores load balance by redistributing tasks among VMs according to Algorithm 1. Now, there is a large gap between the two curves demonstrating the benefits of our refinement based approach, which takes around 3 load balancing steps to gradually reduce the iteration time after interference appears. The interfering job finishes at iteration 300 and hence the NoLB curve comes down. There is little reduction in LB curve, since the previous load balancing steps had reduced the impact of interference to a very small amount. The difference between the two curves after that is due to heterogeneity-awareness in load distribution.
- #39 an interfering VM, we achieve up to 45% improvement in 500 iterations for Stencil2D and Wave2D and 200 iterations for Mol3D, with load balancing every 20th step execution time (Figure 6a). The amount of benefits is different for different applications, especially in Figure 6b. We studied this behavior using Projections tool and found that our load balancer is distributing tasks well for all applications, but the difference in achieved benefits is due to the different sensitivity of these applications to CPU type and frequency. It can be inferred from Figure 6b that Mol3D is the most sensitive to CPU frequency, having most scope for improvement. Next, Figure 6c shows that our techniques are also effective in the presence of both the effects – the inherent hardware heterogeneity and the heterogeneity introduced by multi-tenancy. Another observation from Figure 6 is the variation in the achieved benefits with increasing number of VMs. This is attributed to the tradeoff between two factors: (1) Since there is only one VM sharing physical CPU with interfering VM, running on larger number of VMs implies distributing the work of the overloaded VM to an increasing number of underutilized VMs, which results in larger reduction in execution time (e.g. Figure 6a Mol3D, 8 VM vs. 16 VM). (2) As we scale, the average compute load per VM decreases. Hence, other factors, such as communication time, dominate the total execution time. This implies that even with better load balance and higher % reduction in compute time, overall benefit is small, since communication time is unaffected. Hence, as we scale further, benefits decrease, but they still remain substantial. Moreover, as we scale, benefits can actually be more important because we save across larger number of processors. As an example, from Figure 6b Stencil2D, we save 18.8% over 32 VMs, with absolute savings = 32 0:188 48:09 = 289:28 CPU-seconds, where application took 48.09 seconds on 32 VMs. Juxtaposing this with 20.5% reduction in time over 16 VMs which results in absolute savings = 160:20586:77 = 284:32 CPU-seconds, where application took 86.77 seconds on 16 VMs, we see that the overall savings are more for 32 VM case compared to 16 VMs. Also, since we achieve higher % benefits with larger problem sizes (Section VI-A3, Figure 5c), the benefits will be even higher for weak scaling compared to strong scaling as the impact of factor 2 above is minimized.
- #41 Increase resource util cost savings They appear to be conflicting but as we will see, we can actually do good on both Cloud offerings use application-agnostic VM placement Poor performance of HPC apps in Cloud Cost savings potential through application aware consolidation
- #42 dynamic expand/shrink capability of a job is invaluable in case of dynamic pricing offered by cloud providers, such as Amazon EC2 spot pricing which is based on variable market demands and supply. Such adaptivity gives the user additional flexibility and helps him in obtaining better value for the money spent based on his priorities and deadlines. Secondly, from the cloud provider’s perspective, adaptive jobs along with a smart scheduler are pivotal to attain better system utilization, response time, and throughput while following Quality of Service (QoS) agreements such as fixed execution time for the agreed budget
- #44 Downloaded SLURM code and doing preliminary investigation. In SLURM, job launch can be done by SLURM (using srun), or by application (e.g. we can use charmrun). Job allocation, that is assignment of nodes to a job request, is separate from job launch. SLURM has a manager daemon and a slurmd daemon on each compute node. slurmd daemons are used by srun. We can decide if we want to use srun or not. I recommend we can stick with charmrun for now. For shrink/expand, we can add commands like sexpand, sshrink or srealloc analogous to existing SLURM commands (e.g. salloc). srealloc would: 1. Do the SLURM pre-processing that happens with salloc (e.g database update) 2. Communicate with the application using CCS 3. Wait (block?) for some time or expect a response from aplication 4. Dp SLURM post-processing e.g that happens when a job exits, here part of nodes are reusable in case of shrink. Besides this, we will need to add new scheduling algorithms, I think that can be added as a plugin. A link to SLURM quickstart: https://computing.llnl.gov/linux/slurm/quickstart.html
- #45 Downloaded SLURM code and doing preliminary investigation. In SLURM, job launch can be done by SLURM (using srun), or by application (e.g. we can use charmrun). Job allocation, that is assignment of nodes to a job request, is separate from job launch. SLURM has a manager daemon and a slurmd daemon on each compute node. slurmd daemons are used by srun. We can decide if we want to use srun or not. I recommend we can stick with charmrun for now. For shrink/expand, we can add commands like sexpand, sshrink or srealloc analogous to existing SLURM commands (e.g. salloc). srealloc would: 1. Do the SLURM pre-processing that happens with salloc (e.g database update) 2. Communicate with the application using CCS 3. Wait (block?) for some time or expect a response from aplication 4. Dp SLURM post-processing e.g that happens when a job exits, here part of nodes are reusable in case of shrink. Besides this, we will need to add new scheduling algorithms, I think that can be added as a plugin. A link to SLURM quickstart: https://computing.llnl.gov/linux/slurm/quickstart.html
- #46 Downloaded SLURM code and doing preliminary investigation. In SLURM, job launch can be done by SLURM (using srun), or by application (e.g. we can use charmrun). Job allocation, that is assignment of nodes to a job request, is separate from job launch. SLURM has a manager daemon and a slurmd daemon on each compute node. slurmd daemons are used by srun. We can decide if we want to use srun or not. I recommend we can stick with charmrun for now. For shrink/expand, we can add commands like sexpand, sshrink or srealloc analogous to existing SLURM commands (e.g. salloc). srealloc would: 1. Do the SLURM pre-processing that happens with salloc (e.g database update) 2. Communicate with the application using CCS 3. Wait (block?) for some time or expect a response from aplication 4. Dp SLURM post-processing e.g that happens when a job exits, here part of nodes are reusable in case of shrink. Besides this, we will need to add new scheduling algorithms, I think that can be added as a plugin. A link to SLURM quickstart: https://computing.llnl.gov/linux/slurm/quickstart.html
- #47 Amazon offers 2 types of VM instances – reserved/on-demand and spot Spot instances offer the unused cloud capacity at a dynamically varying price, typically very small compared to on-demand instance price. Spot instances work on a bidding based model. A users places her bid for compute power. If and when her bid exceeds the current spot price, instances are allocated to the user. When the spot price exceeds the bid, the instances are terminated without notice. The user is charged with the spot price at the start of each instance-hour. The spot price changes periodically based on supply and demand.
- #48 Downloaded SLURM code and doing preliminary investigation. In SLURM, job launch can be done by SLURM (using srun), or by application (e.g. we can use charmrun). Job allocation, that is assignment of nodes to a job request, is separate from job launch. SLURM has a manager daemon and a slurmd daemon on each compute node. slurmd daemons are used by srun. We can decide if we want to use srun or not. I recommend we can stick with charmrun for now. For shrink/expand, we can add commands like sexpand, sshrink or srealloc analogous to existing SLURM commands (e.g. salloc). srealloc would: 1. Do the SLURM pre-processing that happens with salloc (e.g database update) 2. Communicate with the application using CCS 3. Wait (block?) for some time or expect a response from aplication 4. Dp SLURM post-processing e.g that happens when a job exits, here part of nodes are reusable in case of shrink. Besides this, we will need to add new scheduling algorithms, I think that can be added as a plugin. A link to SLURM quickstart: https://computing.llnl.gov/linux/slurm/quickstart.html
- #49 So far we discussed the perf evaluation results and some techniques for bridging the gap.. Does that mean we can use a model for hpc in clpud where sc can be substituted by clouds? Increase resource util cost savings They appear to be conflicting but as we will see, we can actually do good on both Cloud offerings use application-agnostic VM placement Poor performance of HPC apps in Cloud Cost savings potential through application aware consolidation
- #50 To justify our position and evaluate the benefits.. We present both perspectives..
- #51 Application to app scale
- #52 We will come back to this point in proposed work section.
- #53 App charact for complex hpc apps is extremely challenging problem.. In this thesis, we focus on the mapping issues.. That is you have some benchmarking data..
- #54 For AppPartition – Take avg slowdown along vertical dimension.. Sort cloud vs sc.. Assign lowest according to equi-partition Then cluster vs sc and assign lowest according to equip For scalePartition.. Equipart.. Diagonal heurstic…
- #55 Downloaded SLURM code and doing preliminary investigation. In SLURM, job launch can be done by SLURM (using srun), or by application (e.g. we can use charmrun). Job allocation, that is assignment of nodes to a job request, is separate from job launch. SLURM has a manager daemon and a slurmd daemon on each compute node. slurmd daemons are used by srun. We can decide if we want to use srun or not. I recommend we can stick with charmrun for now. For shrink/expand, we can add commands like sexpand, sshrink or srealloc analogous to existing SLURM commands (e.g. salloc). srealloc would: 1. Do the SLURM pre-processing that happens with salloc (e.g database update) 2. Communicate with the application using CCS 3. Wait (block?) for some time or expect a response from aplication 4. Dp SLURM post-processing e.g that happens when a job exits, here part of nodes are reusable in case of shrink. Besides this, we will need to add new scheduling algorithms, I think that can be added as a plugin. A link to SLURM quickstart: https://computing.llnl.gov/linux/slurm/quickstart.html
- #56 Downloaded SLURM code and doing preliminary investigation. In SLURM, job launch can be done by SLURM (using srun), or by application (e.g. we can use charmrun). Job allocation, that is assignment of nodes to a job request, is separate from job launch. SLURM has a manager daemon and a slurmd daemon on each compute node. slurmd daemons are used by srun. We can decide if we want to use srun or not. I recommend we can stick with charmrun for now. For shrink/expand, we can add commands like sexpand, sshrink or srealloc analogous to existing SLURM commands (e.g. salloc). srealloc would: 1. Do the SLURM pre-processing that happens with salloc (e.g database update) 2. Communicate with the application using CCS 3. Wait (block?) for some time or expect a response from aplication 4. Dp SLURM post-processing e.g that happens when a job exits, here part of nodes are reusable in case of shrink. Besides this, we will need to add new scheduling algorithms, I think that can be added as a plugin. A link to SLURM quickstart: https://computing.llnl.gov/linux/slurm/quickstart.html
- #57 Downloaded SLURM code and doing preliminary investigation. In SLURM, job launch can be done by SLURM (using srun), or by application (e.g. we can use charmrun). Job allocation, that is assignment of nodes to a job request, is separate from job launch. SLURM has a manager daemon and a slurmd daemon on each compute node. slurmd daemons are used by srun. We can decide if we want to use srun or not. I recommend we can stick with charmrun for now. For shrink/expand, we can add commands like sexpand, sshrink or srealloc analogous to existing SLURM commands (e.g. salloc). srealloc would: 1. Do the SLURM pre-processing that happens with salloc (e.g database update) 2. Communicate with the application using CCS 3. Wait (block?) for some time or expect a response from aplication 4. Dp SLURM post-processing e.g that happens when a job exits, here part of nodes are reusable in case of shrink. Besides this, we will need to add new scheduling algorithms, I think that can be added as a plugin. A link to SLURM quickstart: https://computing.llnl.gov/linux/slurm/quickstart.html
- #59 High Performance Computing (HPC) refers to the practice of aggregating computing power to deliver much higher performance than typical desktop/laptop computers with the goals of solving computationally intensive applications in science, engineering, or business. HPC has traditionally been restricted to a niche segment comprising scientists who use super- computers at national laboratories to enhance human knowledge by understanding how the universe works. They use the tremendous computational power to understand how scientic phenomena operate and evolve in scientic elds such as cosmology, molecular dynamics, quantum chemistry, climate, and human genetics. More recently, HPC is also being used in industry for business and analytics. According to November 2013 top500 list, 56.4% of top 500 supercomputing systems are used by industry
- #60 High Performance Computing (HPC) refers to the practice of aggregating computing power to deliver much higher performance than typical desktop/laptop computers with the goals of solving computationally intensive applications in science, engineering, or business. HPC has traditionally been restricted to a niche segment comprising scientists who use super- computers at national laboratories to enhance human knowledge by understanding how the universe works. They use the tremendous computational power to understand how scientic phenomena operate and evolve in scientic elds such as cosmology, molecular dynamics, quantum chemistry, climate, and human genetics. More recently, HPC is also being used in industry for business and analytics. According to November 2013 top500 list, 56.4% of top 500 supercomputing systems are used by industry
- #61 Goal of increasing the utilization of underutilized resources through The high-level question I wanted to answer in this talk is, can we build a large-scale update-intensive Internet service using and make it cheap, fast, manageable, available at the same time. And I think I answered the question affirmatively. The key insight I used to answer this question is the exploitation of A. S. For example, ….. By using application-specific requirements, we can achieve goals that are often contradicting, such as in cheapness and availability. A system for cloud providers.. A system for HPC-cloud users.. Many ideas applicaton to exascale RTS..
- #62 Goal of increasing the utilization of underutilized resources through The high-level question I wanted to answer in this talk is, can we build a large-scale update-intensive Internet service using and make it cheap, fast, manageable, available at the same time. And I think I answered the question affirmatively. The key insight I used to answer this question is the exploitation of A. S. For example, ….. By using application-specific requirements, we can achieve goals that are often contradicting, such as in cheapness and availability. A system for cloud providers.. A system for HPC-cloud users.. Many ideas applicaton to exascale RTS..
- #63 Goal of increasing the utilization of underutilized resources through The high-level question I wanted to answer in this talk is, can we build a large-scale update-intensive Internet service using and make it cheap, fast, manageable, available at the same time. And I think I answered the question affirmatively. The key insight I used to answer this question is the exploitation of A. S. For example, ….. By using application-specific requirements, we can achieve goals that are often contradicting, such as in cheapness and availability. A system for cloud providers.. A system for HPC-cloud users.. Many ideas applicaton to exascale RTS..
- #64 Goal of increasing the utilization of underutilized resources through The high-level question I wanted to answer in this talk is, can we build a large-scale update-intensive Internet service using and make it cheap, fast, manageable, available at the same time. And I think I answered the question affirmatively. The key insight I used to answer this question is the exploitation of A. S. For example, ….. By using application-specific requirements, we can achieve goals that are often contradicting, such as in cheapness and availability. A system for cloud providers.. A system for HPC-cloud users.. Many ideas applicaton to exascale RTS..