STAC (Securities Technology Analysis Center) recently released an ‘exploratory’ benchmark for machine learning which it hopes will evolve into a firm benchmark or suite of benchmarking tools to compare the performance of machine learning and deep learning workflows for financial applications across systems. The new report, Toward business-driven ML benchmarks: An NLP example, examined performance on different Google cloud instances.

“This study was designed to illustrate how STAC Benchmarks for machine learning (ML) can be constructed and used. It is also intended to help data scientists and data engineers know what to expect when using the data science tools and cloud products of this project and how to avoid common pitfalls. The workload is topic modeling of SEC Form 10-K filings using Latent Dirichlet Allocation (LDA), a form of natural language processing (NLP),” according to the report.

STAC used the workload to explore the question of scale-up versus scale-out in a cloud environment on three SUTs:

• A single Google Cloud Platform (GCP) n1-standard-16 instance with Skylake and RHEL 7.6
• A single GCP n1-standard-96 instance with Skylake and RHEL 7.6.
• A Google Cloud Dataproc (Spark as a service) cluster containing 13 x n1-standard-16 Skylake instances (1 master and 12 worker nodes) and Debian Linux 8.”

STAC’s foray into ML/DL benchmarking was presented with both caution and ambition: “While we hope these results are informative, it is important to understand what they are not. They are not competitive benchmark results of the sort readers are accustomed to finding in STAC Reports. No vendors contributed to optimization of the SUTs, so we can be fairly certain that they don’t represent the best possible results. As soon as the [STAC] Council adopts these or other benchmark specifications for ML, the competitive benchmark numbers will begin to flow.”

Extracting useful information from various sources – regulatory filings, company reports, news, etc. – has a long history in financial services. Recently various AI approaches have increasingly been pressed into service. The latest report notes the challenge ML presents:

 “…There are dozens upon dozens of ML algorithms; at least ten ML frameworks or libraries with implementations of those algorithms; nearly two dozen processor architectures vying for ML workloads (yes, you read that right); infrastructure-as-a-service and machine-learning-as-a-service offerings from all the major cloud providers; and countless software and software-as-a-service providers promising to simplify, accelerate, or otherwise enhance machine learning workflows. Data scientists and the technologists that support them face a tyranny of choice.

“The mission of the STAC Benchmark Council is to fight such tyranny. The Council develops benchmark standards that are based on real world use cases and that measure things that matter to a business (in the case of machine learning, those are primarily time to market, cost, and model quality, as discussed later in this report). This enables customers, vendors, and STAC to make apples-to-apples comparisons of techniques and technologies, thus making architectural and product choices easier for customers. It also gives the vendor community use cases developed by multiple customers (like a multi-customer POC) on which they can focus product development.”

The full study is available to STAC members however the STAC Study – Excerpts is freely available for download after registering and is fascinating. Issues around measuring performance, cost, and quality are tackled. Google (cloud resources) and Intel (funding) helped support this project. Presented below are snippets of the material contained in the excerpts report.

STAC compared performance on three instances (details below). “We defined three dataset sizes, as shown in Table 2. The first, 1/3 of a year, represents the sort of small subset that a quant might use for quick and dirty modeling before initiating a search on the full dataset of interest. The largest dataset size in this project was 3 years. This is a realistic size with manageable costs and time requirements for a benchmark project. In practice a firm may want to use substantially more, perhaps 10 or even 20 years, or perhaps compute models for a rolling 3-year window over a 10- or 20-year interval. Most firms will run this kind of workload many times, which raises the stakes.”

All three solutions used the same analytics software stack: Python 3.5; Python 3 library spaCy 2.0.12; Python 3 library Scikit-learn 0.20.0; Intel Python 3 library MKL 2018.0.3; Python 3 library Joblib 0.12.3.

To support this, two of the SUTs provided infrastructure as a service, and one provided Spark as a service. STAC described the Google instance configurations as follows:

“v16 – A single cloud instance representative of where a user might start when looking for something bigger than a laptop at a reasonable cost, in the absence of knowledge about how the workload scales. Configuration:

• Google Compute Engine n1-standard-16 (16 vCPUs, 60 GB memory)
• CPU platform Intel Skylake or better
• 20 GB Google Persistent Disk as boot disk
• 1 TB Google Persistent Disk mounted read-only as data disk
• Red Hat Enterprise Linux 7.6

“v96 – A single cloud instance with the most vCPUs currently available. The point was to see how well the 
workload “scaled up” without the complexity of multiple nodes. Configuration:

• Google Compute Engine n1-standard-96 (96 vCPUs, 360 GB memory)
• CPU platform Intel Skylake or better
• 20 GB Google Persistent Disk as boot disk
• 1 TB Google Persistent Disk mounted read-only as data disk
• Red Hat Enterprise Linux 7.6

“DP-v192 – Google Cloud Dataproc (Spark as a service), using multiple nodes to double the number of cores versus the v96, with autoscaling enabled in order to limit the cost of under-utilized cores. This SUT used Dataproc simply to get access to more cores on which to run a Python script. This way we only had to write a Spark wrapper around exactly the same code as we ran on the single instances. This is a common transition path for data scientists initially trying to scale out in the cloud, but since it is neither Spark- nor cloud-native, it probably doesn’t represent optimal use of the platform. Configuration:

• Google Dataproc image 1.2.22 with autoscaling (alpha) and minimum CPU platform = Skylake (beta)
• Debian 8
• 13 x Google Compute Engine n1-standard-16 (16 vCPUs, 60 GB memory). One master nodes plus 12 worker nodes.
• 60 GB Google Persistent Disk as boot disk for each node
• Google Cloud Storage for the input datasets and persisted results”

As you can see the results were interesting.

The report also noted Google Cloud Dataproc utilized its autoscaling feature and that because that feature was still in alpha status, by STAC policy did not make the results public but included them in the full study.

STAC offered these additional observations:

• “While it’s easy to assume that one can accelerate a workload by throwing more cores at it, this isn’t always true. In fact, this study highlights a few cases where trying to exploit additional cores slowed a workload down.
• “For a given code base and processor type, there is a lower bound of elapsed time that cannot be overcome by scaling up or out. Individual experiments in this implementation were not able to utilize more than one vCPU. Thus, even with a surplus of cores and no platform overhead, the elapsed time for each work set is gated by its longest-running experiment. The only way to shrink that time is to improve performance per vCPU through faster code or a faster processor.
• “As documented in this study, v96 is preferable for some workloads while v16 is preferable for others, depending on the user firm’s priorities (operating cost vs data scientist cost vs time to market). Fortunately, the fact that Google Persistent Disk makes it possible to fire up any type of instance and access the same data as other instances makes it convenient to mix and match instance types according to the task at hand.”

It will be interesting to monitor how the STAC community responds, how the exploratory benchmark evolves, and when vendors start using the STAC ML benchmark on their systems. There are, of course, many tests being used to assess AI capabilities of systems. One new effort – the MLPerf benchmark suite for assessing training and inference performance introduced last May – has attracted considerable support and recently released its first round of results (see HPCwire article, Nvidia Leads Alpha MLPerf Benchmarking Round.) Another is aimed at large and leadership class systems, (see HPCwire article, The Deep500 – Researchers Tackle an HPC Benchmark for Deep Learning).

The STAC report offers the following assessment of its effort: “We think this [initial] implementation is good enough to yield technology comparisons that can be applied to the real world. While the implementation is constructed from mostly publicly available references and is perhaps not exactly what a firm would deploy (for example a firm might highly customize the preprocessing stage of the pipeline), we believe the algorithm is sufficiently representative of the real world with respect to performance and quality to make it a useful instrument to inform real algorithmic and architectural choices. We also think it is simple enough that STAC members (users and vendors) will be able to analyze and optimize its performance, as well as introduce new libraries and techniques, without a huge effort.”

Link to STAC report: https://stacresearch.com/topic_modeling_1