STAC Summit, 18 Jun 2019, Chicago

• Dr Michel Debiche, Director of Analytics Research, STAC

Michel will discuss progress toward benchmark standards for ML/DL techniques and technologies based on problems that finance firms in the STAC Benchmark Council have said they care about.

• Brian Peterson, Managing Director, Hehmeyer Trading + Investments
• Dr John Ashley, Director, Global Financial Services Strategy, NVIDIA [Slides]
• Dr Michel Debiche, Director of Analytics Research, STAC (moderator)

Financial firms are increasingly using machine learning or deep learning (broadly, “AI”) to improve outcomes or automate functions. Like many other key components of a business plan, AI is a team sport. A brilliant researcher can't be productive without a lot of help with data, technology, and process management. Fortunately, many of these skills exist already in the finance industry, whether it is managing large amounts of data, designing systems for high performance, or managing uncertain processes in an agile way. What are the key engineering and development skills needed on effective data science teams? What technologies are most crucial to understand today and in the near future? How much data science knowledge does a technologist need in order to be a highly effective data engineer or ML engineer? Which parts of the process are most likely to be automated, purchased, or outsourced in the near future, and which parts will continue to rely on in-house (human) technologists? Our panel will discuss.

• Dr Michel Debiche, Director of Analytics Research, STAC

A lot of innovative solutions for big data and big compute workloads like enterprise tick analytics, strategy backtesting, and market risk are being subjected to STAC Benchmarks. If he can catch his breath, Michel will take us through the latest research.

• VR Satish, CTO, Pavilion Data Systems
• Scott Henderson, Systems Solutions Engineer, Vcinity
• Shimon Ben-David, Director of Sales Engineering & Support, WekaIO
• Charles Fan, Co-founder and CEO, MemVerge
• Peter Lankford, Founder & Executive Director, STAC (moderator)

Ever-increasing demands from the business, the growth of new AI workloads, and the increasing pull of public clouds call for faster and more flexible ways to get data where it’s needed in computations. Fortunately, the vendor community is competing and collaborating to solve these problems. Innovations include standards like NVMe and NVMe over Fabrics, persistent memory with interesting properties, new and enhanced distributed file systems, rapidly evolving cloud services, and products that claim to substantially mitigate problems we expect when compute and storage are separated by long distances. Sorting through this Cambrian explosion of offerings is a good problem to have, but a problem nonetheless. How should application developers think about memory and storage today? What’s possible with file, block, and object storage? When is public cloud a realistic option, and when not? What are the promise and perils of disaggregated storage? Our panel of experts will debate.

• Ken Gibson, Director of Persistent Memory Software Architecture, Intel

Persistent memory or PMEM (which we've often referred to as storage class memory), is a new technology in the memory-storage hierarchy that combines the persistence of storage with the byte-level access and memory bus usage of DRAM. PMEM vendors promise users greater capacity, availability, and data protection than traditonal DRAM, with greater performance and endurance than traditonal SSDs. In this talk, Ken will give an overview of how operating systems expose PMEM to applications and how to program directly to it using the open source Persistent Memory Developer Kit (PMDK) APIs bundled in Linux and Windows. Along the way, he will give examples of how some popular open source databases have been modified for PMEM.

• Peter Lankford, Founder & Executive Director, STAC

Peter will discuss the latest research and Council activities related to low-latency/high-throughput realtime workloads.

• David Lidrbauch, Product Marketing Manager, Mentor, A Siemens Business

Public clouds—offering huge economies of scale, access to the latest hardware, copious memory, and fast storage—seem like a great way to improve the scalability, performance, and cost of verifying RTL designs for FPGA. But there are challenges. Cloud infrastructure as a service (IaaS) tends to be optimized for HPC-oriented jobs or multi-tenant, always-on, transactional tasks. According to David ,IaaS offerings can stumble on write-heavy tasks, latency-sensitive data transfer, and highly interactive workflows such as logic debug. FPGA verification teams invest heavily in on-prem environments to avoid these bottlenecks, and moving to cloud infrastructures risks losing those hard-won advantages. However, David will describe a real-world case in which the customer, a cloud provider, and other parties collaborated on a semi-custom that overcame some of these hurdles. More generally, he'll describe architectures that preserve specific verification environment advantages in a public cloud or hybrid cloud, presenting benchmark data to back up those claims.

• Jerry Nelligan, CTO, XR Trading
• Dr David Snowdon, Director of Engineering, Arista
• Dr Balaji Prabhakar, Co-Founder, Tick Tock Networks
• Matt Davey, Director of Product Management, Corvil
• Peter Lankford, Founder & Executive Director, STAC (moderator)

Maintaining event intelligence in electronic trading continues to get more challenging. Understanding events with clarity requires capturing those events, understanding exactly when they happened, and pulling them into meaningful analysis, whether that’s for operations management or strategy development and backtesting. Our panelists will discuss these challenges and opine on the best ways to solve them. What kind of accuracy do trading firms need in the near future, and what kind of accuracy is possible? Are these even separable questions, or do new capabilities create their own demand? What kind of network does high accuracy require? How are 40G and higher bandwidths affecting requirements for capture? How are advances in storage and memory affecting capture architectures? What’s changing and what’s not in the build-vs-buy equation?