Scaling collectives on large clusters using Intel(R) architecture processors and fabric

Abstract

This paper provides results on scaling Barrier and Allreduce to 8192 nodes on a cluster of Intel ® Xeon Phi™ processors installed at the University of Tokyo and the University of Tsukuba. We will describe the effects of OS and platform noise on the performance of these collectives, and provide ways to minimize the noise as well as isolate it to specific cores. We will provide results showing that Barrier and Allreduce scale well when noise is reduced. We were able to achieve a latency of 94 usec (7.1x speedup from baseline) or 1 rank per node Barrier and 145 usec (3.3x speedup) for Allreduce at the 16 byte (16B) message size at 4096 nodes. CCS CONCEPTS • Networks → Network performance analysis; • Software and its engineering → Scheduling;

A Simulation Framework for Function as a Service

“…The single node deployment is offered via faasd where resource limits are not available. The recommended deployment option is again K8s where resource limits for memory and CPU can be set independently 100 . This feature is based on K8s facilities to restrict resources within the deployment YAML adapted by OpenFaaS.…”

“…[37], wanted to be more flexible in changing the frequency by hand during their benchmarks. Since some of the generic scaling governors are overwritten (by using the same name) by intel_pstate and others are not usable, sometimes researchers [63,82,100,140,236] disabled it to use the generic ones. None of the aforementioned papers specified one of the first three options (1-3) explicitly in their papers.…”