This paper proposes a delay mechanism to mitigate the impact of latency differences in the gRPC framework--a high-performance, open-source universal remote procedure call (RPC) framework--between different programming languages on the performance of agents in DareFightingICE, a fighting game research platform. The study finds that gRPC latency differences between Java and Python can significantly impact real-time decision-making. Without a delay mechanism, Java-based agents outperform Python-based ones due to lower gRPC latency on the Java platform. However, with the proposed delay mechanism, both Java-based and Python-based agents exhibit similar performance, leading to a fair comparison between agents developed using different programming languages. Thus, this work underscores the crucial importance of considering gRPC latency when developing and evaluating agents in DareFightingICE, and the insights gained could potentially extend to other gRPC-based applications.

A Federated Learning (FL) system typically consists of two core processing entities: the federation controller and the learners. The controller is responsible for managing the execution of FL workflows across learners and the learners for training and evaluating federated models over their private datasets. While executing an FL workflow, the FL system has no control over the computational resources or data of the participating learners. Still, it is responsible for other operations, such as model aggregation, task dispatching, and scheduling. These computationally heavy operations generally need to be handled by the federation controller. Even though many FL systems have been recently proposed to facilitate the development of FL workflows, most of these systems overlook the scalability of the controller. To meet this need, we designed and developed a novel FL system called MetisFL, where the federation controller is the first-class citizen. MetisFL re-engineers all the operations conducted by the federation controller to accelerate the training of large-scale FL workflows. By quantitatively comparing MetisFL against other state-of-the-art FL systems, we empirically demonstrate that MetisFL leads to a 10-fold wall-clock time execution boost across a wide range of challenging FL workflows with increasing model sizes and federation sites.

This paper presents a new communication interface for the DareFightingICE platform, a Java-based fighting game focused on implementing AI for controlling a non-player character. The interface uses an open-source remote procedure call, gRPC to improve the efficiency of data transfer between the game and the AI, reducing the time spent on receiving information from the game server. This is important because the main challenge of implementing AI in a fighting game is the need for the AI to select an action to perform within a short response time. The DareFightingICE platform has been integrated with Py4J, allowing developers to create AIs using Python. However, Py4J is less efficient at handling large amounts of data, resulting in excessive latency. In contrast, gRPC is well-suited for transmitting large amounts of data. To evaluate the effectiveness of the new communication interface, we conducted an experiment comparing the latency of gRPC and Py4J, using a rule-based AI that sends a kick command regardless of the information received from the game server. The experiment results showed not only a 65\% reduction in latency but also improved stability and eliminated missed frames compared to the current interface.

The first API Design model we are going to look at is Representational State Transfer (REST). REST follows the principles that HTTP and World-Wide Web are based on. It is practically just a set of rules built on top of what HTTP as a protocol allowed. For example, REST suggests that HTTP methods (GET, POST, PUT, PATCH…) are used accordingly to interact with resources, and this brings the advantage of having a predictable design when you know the resources you are dealing with. For an API to be intuitive and to be predictable has great importance.

AWS customers are increasingly using computer vision (CV) models for improved efficiency and an enhanced user experience. For example, a live broadcast of sports can be processed in real time to detect specific events automatically and provide additional insights to viewers at low latency. Inventory inspection at large warehouses capture and process millions of images across their network to identify misplaced inventory. CV models can be built with multiple deep learning frameworks like TensorFlow, PyTorch, and Apache MXNet. These models typically have a large input payload of images or videos of varying size.

Motivation is to build a complete DIY autonomy software from scratch (motion planning, guidance and motion control, SLAM, mission control, 2D/3D visualization etc..) with a real-time client-server communication stream using async gRPC for intercommunication and distributed compute. User serial permission is required to connect to Create over serial.

Writing a scalable application needs a better design principle. Let's say we want to design a e-Commerce application, it may have a different set of clients (browser, mobile device, etc.), also in the middle of the development stage a deep-learning based recommendation system which works on images to extract product information needs to be written to improve the user experience, but the main application was written in PHP. To make the design as modular as possible, it's better to choose a microservices based design strategy instead of writing the complete application as one cohesive unit, sharing the same memory space (monolith). If we want to extract car models from image data, we can solve the task with two steps, first, we localize the cars with semantic segmentation, finally, for each segmented car, we apply a classification model to get the car model. A simple scenario with microservices architecture would be, team 1 is working on the segmentation model which they developed and deployed with microservice 1.

A PyTorch implementation of IMPALA: Scalable Distributed Deep-RL with Importance Weighted Actor-Learner Architectures by Espeholt, Soyer, Munos et al. While PolyBeast is more powerful (e.g. MonoBeast requires only Python and PyTorch. For further details, see our paper. MonoBeast is a pure Python PyTorch implementation of IMPALA.

Imagine this: you've gotten aboard the AI Hype Train and decided to develop an app which will analyze the effectiveness of different chopstick types. To monetize this mind-blowing AI application and impress VC's, we'll need to open it to the world. And it'd better be scalable as everyone will want to use it. As a starting point, we will use this dataset, which contains measurements of food pinching efficiency of various individuals with chopsticks of different length. As we are not only data scientists but also responsible software engineers, we'll first draft out our architecture.

As a developer, I'm trying to better understand how developers work together with data scientists to build applications that leverage machine learning. In this context, one key question is how developers can access models from their applications. Below is a quick introduction to TensorFlow Serving and a description how to deploy TensorFlow models onto the IBM Cloud. "TensorFlow Serving is a flexible, high-performance serving system for machine learning models, designed for production environments. TensorFlow Serving makes it easy to deploy new algorithms and experiments, while keeping the same server architecture and APIs. TensorFlow Serving provides out-of-the-box integration with TensorFlow models, but can be easily extended to serve other types of models and data."