Hardware-accelerated Aggregation: Unification and Specialization Alireza ShateriT , Hongshi TanS , Michael NgT , Bingsheng HeS , Qizhen ZhangT T University of Toronto, S National University of Singapore
ABSTRACT
Computation
The high e!ciency of domain-speci"c hardware has sparked substantial interest in adopting accelerators in data analytics systems. Among many choices, GPUs and FPGAs thrived as two popular solutions due to their prevalent deployments in cloud data centers. This paper investigates hardware acceleration solutions for aggregation, a critical data analytics operation. Speci"cally, we implement aggregation with a uni"ed hardware acceleration framework, which trades e!ciency for ease of programming and portability, and then further develop hardware-speci"c optimizations. We evaluate these solutions on three recent computing hardware platforms: a CPU, a GPU, and an FPGA, with metrics that cover both the performance and energy consumption of on-device and end-to-end processing.
1
Agg Data Access
Parallelization
Figure 1: Aggregation performance is determined by the e!ciency of data access, parallelization, and function computation, stressing the underlying hardware in various aspects.
INTRODUCTION
factors determine the performance of in-memory aggregation: how fast data is accessed from memory, how e!ciently the aggregation function is computed by the processing unit, and how well the operation is parallelized. To accelerate this operation with heterogeneous devices, we "rst use a uni"ed hardware acceleration framework, called TornadoVM [10], which compiles a high-level implementation into binaries that can run on di#erent target hardware via two levels of JIT compilation. This uni"cation advocates ease of programming and portability but unfortunately sacri"ces performance. We show the ine!ciencies of the generated aggregation kernels by the framework and develop optimizations specialized for each hardware platform. Finally, we compare data aggregation performance between state-of-the-art CPU, GPU, and FPGA, to investigate the e#ect of hardware acceleration. Our study involves metrics for both aggregation performance and its energy e!ciency. In the analysis of the results, we consider not only on-device performance, i.e., data is preloaded into the device memory, but also end-to-end performance. The former represents an ideal scenario where the overhead of moving data between the host and the accelerator, which has been shown as the primary bottleneck of adopting hardware acceleration for databases [23, 43], is avoided. Including results for both setups paints a complete picture of the bene"ts and limitations of hardware acceleration. This work makes the following contributions.
The demand for high compute e!ciency in cloud applications continues to increase due to rapid data growth, but hardware scaling laws for general-purpose processors (i.e., CPUs) have slowed down over the years. Compared to CPUs, domain-speci"c accelerators, e.g., Graphics Processing Units (GPUs) and Field Programmable Gate Arrays (FPGAs), o#er higher compute performance and energy e!ciency. Accelerators have been widely deployed in cloud data centers to o$oad a variety of infrastructure and application functionalities [2–4, 9, 15, 27]. Generally, their high parallelism, e.g., tens of thousands of cores in recent GPUs, and memory speed, e.g., up to 1 TB/s bandwidth with High Bandwidth Memory (HBM), can drastically improve the performance of data analytics tasks. Prior work has shown promising results about utilizing FPGAs and GPUs for relational data analytics such as sorting [26, 32], projections [32], and joins [11, 12, 20, 31] However, there is a lack of cross-hardware investigation into common relational data analytical operations. Di#erent accelerators present di#erent performance and energy characteristics. For instance, GPUs and FPGAs provide higher parallelism and on-device memory speed, but both accelerators clock less frequently than CPUs. A horizontal comparison between state-of-the-art hardware devices can provide meaningful insights. In this paper, we present a study of the e#ect of hardware acceleration on data aggregation, an operation frequently involved in a variety of data analytics jobs, including MapReduce [7, 16], graph processing [22, 45], streaming and time series analytics [5, 13], and distributed machine learning [1, 17]. Despite many variants, the most fundamental task of data aggregation is to scan the data items in a given database and apply an aggregation function (e.g., min or sum), as shown in Figure 1. We focus on in-memory aggregation— otherwise the performance is dominated by storage I/O. Three
• Implementation of aggregation in a uni"ed acceleration framework and hardware-specialized optimizations (§3). • Evaluation of aggregation over realistic datasets on CPU (Intel Xeon) and popular data center accelerators: GPU (NVIDIA A100) and FPGA (AMD Alveo U55C) (§4). • Cross-device comparison with metrics covering performance (§5) and energy consumption (§6). 1
Conference’17, July 2017, Washington, DC, USA
Shateri et al.
2 BACKGROUND 2.1 Data Aggregation
Streaming Multiprocessors Core
Aggregation is a basic construct baked in many real-world data analytics systems, including cloud data warehouses [6, 34], Business Intelligence [24, 35], MapReduce [7, 16], graph processing [22, 45], streaming and time series analytics [5, 13], as well as distributed machine learning training [1, 17]. Optimizing its performance has practical meanings. Essentially, this operation scans the data items in a given database, applies an aggregation function (e.g., min or sum), and returns the summarized view of the data. As shown in Figure 1, aggregation stresses the underlying hardware in three aspects: how fast data items are accessed, how e!ciently the aggregation function is computed, and how well the operation is parallelized. Prior work explored speci"c hardware, especially GPUs [18, 32], to improve aggregation performance, but there has been a lack of cross-hardware comparison and analysis, which can help to better navigate through the design space.
2.2
..
Register
Logic Block
Core
Wire
Register
Memory Engine
L1, Shared Memory
L2
Global Memory
Global Memory
Figure 2: GPU
1 2 3 4 5
Hardware Acceleration
6 7
Graphics Processing Units (GPUs). GPUs are designed for highthroughput computation. They feature many simple cores that can execute thousands of threads in parallel. Figure 2 shows the high-level architecture of a modern GPU, which comprises multiple Streaming Multiprocessors (SMs). Each SM contains numerous Processing Elements (PEs) or cores that execute instructions in a Single Instruction, Multiple Data (SIMD) or Single Instruction, Multiple Threads (SIMT) fashion. The memory hierarchy in GPUs includes global memory, L2 cache, SM-local shared memory and L1 cache, and registers, each varying in size and access speed. With High Bandwidth Memory (HBM), even the slowest level, i.e., the global memory, in today’s GPUs can provide terabits/s bandwidth.
Figure 3: FPGA (logics and wires are programmable)
!
"
#
$
class Aggregation { public void static kernel ([ Schema ] input , @Reduce [ Type ] r ) { for ( @Parallel i = 0; i != input . size () ; i ++) { r . set ( aggregate ( r . get () , input . get (i))); } } }
Figure 4: Aggregation implemented with TornadoVM. This simple implementation is automatically compiled into hardware-local executables by the framework.
learning workloads in Flink with heterogeneous hardware [38]. Two annotations, @Parallel and @Reduce, are provided by TornadoVM for applications to parallelize loops and reduction operations.
3
Field-Programmable Gate Arrays (FPGAs). FPGAs have programmable logic blocks and gates (Figure 3). These blocks can be con"gured to implement functions tailored to speci"c applications. Blocks are interconnected via programmable wires, allowing users to further custom circuits. Modern FPGAs are equipped with sizable onboard memory (global memory). This memory is distributed across independent channels, each accessible by a memory engine (ME). Unlike "xed-architecture processors, FPGAs excel in parallel pipeline processing. Despite the promise, FPGAs are notoriously di!cult to program. Designing an optimal hardware architecture requires deep expertise and careful resource management.
ACCELERATION AND OPTIMIZATIONS
We "rst present aggregation implementation in the uni"ed acceleration framework and then show how we improve its performance via hardware-speci"c optimizations.
3.1
Uni"ed Acceleration
Figure 4 illustrates the aggregation implemented in Java with TornadoVM ’s API. The kernel is a static Java method that iterates over input tuples to apply an aggregation function. We express data parallelism by annotating the loop with @Parallel and the output accumulator with @Reduce. The former executes each loop iteration in parallel, while the latter speci"es that the result r is a reduction variable that must accumulate contributions from all iterations. Writing code in TornadoVM is similar to writing a regular Java program. With the annotations, the framework JIT-compiles the kernel to an intermediate OpenCL representation and further generates the executable for the target device.
Uni"ed Framework. TornadoVM [10] is a JVM plugin that allows Java applications to o$oad functions to heterogeneous hardware, such as multi-core CPUs, GPUs, and FPGAs, with a uni"ed API. Speci"cally, its task-schedule abstraction speci"es groups of Java methods as tasks that are automatically scheduled by the runtime on target hardware. To support heterogeneous hardware, TornadoVM adopts a two-tier Just-In-Time (JIT) compilation technique to specialize the code at compile time: Java bytecode from the application is "rst compiled to OpenCL [30] C code, which is further compiled to machine code by the OpenCL driver for the target hardware. Hence, TornadoVM serves as a uni"ed framework that supports any OpenCL-compatible hardware. This framework has been adopted as a solution to transparently accelerate compute-intensive machine
Ine!ciencies. While the uni"ed approach provides ease of programming and portability, the automatically generated code does not exploit device-speci"c characteristics. The ine!ciencies of the TornadoVM-generated aggregation per hardware are as follows. • On CPUs, although multi-threading is exploited, by default TornadoVM con"gures thread count as the number of data items to aggregate. Spawning threads more than available 2
Hardware-accelerated Aggregation: Unification and Specialization
Conference’17, July 2017, Washington, DC, USA
cores incurs signi"cant scheduling overhead and thread contention. In addition, within each thread, the reduction process linearly scans individual tuples. Advanced CPU features, e.g., SIMD instructions and cache locality, are not utilized. • On FPGAs, the generic kernel sequentially reads input data from global memory and utilizes only one memory channel, while modern FPGAs often have multiple memory channels. Moreover, FPGA-speci"c spatial parallelism, e.g., unrolling loops to create pipelines, is not exploited and thus resources, including logic units and DSPs, are not fully utilized. • On GPUs, TornadoVM generates two kernels for aggregation, one for computing the partial aggregate within each thread block and the other for summarizing the "nal aggregate. Global synchronization primitives, e.g., memory fence, are used to coordinate threads. Also, accesses to global memory are not coalesced and thus underutilize memory speed.
3.2
Global Memory
Read Engine
input[0]
Global Memory
Read Engine
input[1]
...
...
Read Engine
input[n]
Global Memory
Aggregation
r Kept in registers
Figure 5: Optimized aggregation on FPGAs. tuples from the same thread block are coalesced with grid-stride loops [28]. At runtime, threads perform block-local reductions by accumulating over tuples entirely in registers. Finally, partial aggregates of blocks are merged with a global synchronization.
4
EXPERIMENTAL SETUP
Workloads and Metrics. The dataset where we run aggregation is the lineitem table (sum over the suppkey attribute) from the TPCH benchmark with varying scale factors. We evaluate two scenarios: data resides in the device memory (where there are no data transfers between the host and the device), and data resides in the host memory. In addition to aggregation performance, we also consider energy consumption (in Joules) to provide more perspectives.
Specialization
CPU Optimizations. We "rst align the thread count with the number of available CPU cores. This eliminates the overhead of excessive threads. To utilize vectorized instructions, we adopt the simd directive in OpenMP to issue wide Intel AVX instructions in each thread to aggregate multiple tuples in one cycle.
Hardware. Our experiments are conducted on recent production hardware. We run CPU experiments on a server equipped with an Intel Xeon Silver 4314 CPU with 16 physical cores (32 hyperthreads), each clocking at 2.4 GHz, and 128 GB of DDR4 memory. For FPGA experiments, we use an AMD/Xilinx Alveo U250 FPGA, which o#ers 1.7 million logic look-up tables and 12 K DSP slices and 64 GB of four-channel DDR4 memory, o#ering up to 77 GB/s of sequential access bandwidth. Finally, the GPU experiments are carried out on an NVIDIA A100 GPU, which consists of 6912 CUDA cores and 432 Tensor cores and 80 GB of high-bandwidth HBM2 memory.
FPGA Optimizations. Based on TornadoVM’s uni"ed acceleration framework, the high-level aggregation kernel is compiled into a hardware data processing element (PE) that is instantiated directly on the FPGA fabric. To fully utilize the memory bandwidth from the FPGA’s multiple memory channels, we parallelize aggregation across multiple PEs, each concurrently processing a partition of the input data. As shown in Figure 5, given an FPGA equipped with 𝐿 memory channels, the input tuples are evenly partitioned across 𝐿 channels. Each channel is assigned a dedicated read engine, which fetches tuples from global memory and streams them into the processing pipeline for data aggregation. To enhance performance and better exploit FPGA-speci"c architectural features, we further incorporate two key building components into the generated design. First, we optimize the scalar memory loads generated from TornadoVM with 512-bit vector reads to saturate the external memory bandwidth and ensure that each PE receives data at full throughput. These accesses are independently mapped to separate memory controllers, enabling spatial parallelism across banks without arbitration or cache contention. Second, we incorporate the aggregation computation through a statically scheduled reduction tree fully realized in registers. Each input stream is processed by a pipelined adder network with an initiation interval of one cycle, allowing the production of one aggregated result per cycle. In contrast to the default TornadoVM-generated design, which relies on atomics and memory fences to resolve con%icts, our optimization guarantees deterministic and con%ict-free updates by construction. This eliminates synchronization overhead and allows the pipeline to operate at full utilization.
5
PERFORMANCE
We "rst present the aggregation speed achieved by the uni"ed framework on each of the three hardware devices and then show the e#ectiveness of our hardware-speci"c optimizations. In addition to on-device performance, we also report end-to-end results that account for data transfer times between the host and the accelerator.
5.1
Uni"ed Acceleration
The "rst-hand aggregation performance of TornadoVM on TPC-H scale factor 200 is shown in Figure 6. The CPU takes 0.5 seconds to aggregate 9.6 billion tuples—19 billion tuples/s. The FPGA is signi"cantly slower with 30 million tuples/s. The GPU achieves the highest performance at 660 billion tuples/s, 35→ and 19000→ faster than the CPU and the FPGA, respectively. This experiment shows that although the uni"ed framework can achieve highe performance the GPU, it generally underutilizes hardware capability for aggregation due to the ine!ciencies we identi"ed (§3).
5.2
GPU Optimizations. We fuse the two GPU kernels into a single one and exploit cooperative groups (CGs) [29] to improve synchronization and memory e!ciency. Speci"cally, thread count is aligned with the number of SMs on the device and accesses to the input
Optimizations
Our hardware-speci"c optimizations can e#ectively improve aggregation performance. As Figure 6 shows, our "rst CPU optimization, which aligns thread count with available cores, brings 1.7→ speedup. 3
Conference’17, July 2017, Washington, DC, USA
Shateri et al.
Figure 9: Optimized aggregation performance with varying data sizes. Dashed lines represent the throughput of GPU, FPGA, and CPU (top to bottom).
Figure 6: Uni"ed and specialized aggregation performance on di#erent hardware. CT, SIMD, AC, Pipe, CG refer to our optimizations for CPU (con"gured threads, SIMD), FPGA (all channels, optimized pipeline), and GPU (cooperative groups).
Figure 7: CLB utilization
Figure 8: DSP utilization
With SIMD instructions, CPU aggregation is 13→ faster than the uni"ed code. The improvement is most pronounced for FPGA execution: utilizing all memory channels improves speed by 32→, and FPGA performance is fully unlocked with our optimized pipeline, which brings !ve orders of magnitude improvement. The FPGA is now 2.7→ faster than the CPU. Figures 7 and 8 explain why our FPGA implementation is more e!cient: FPGA resources, i.e., Con"gurable Logic Block (CLB) and Digital Signal Processing (DSP) units, are much better utilized. For GPU execution, although TornadoVM can already utilize this accelerator to achieve higher performance than the CPU, our optimization with cooperative groups can further elevate GPU aggregation speed by 2.1→. Figure 9 shows scalability of optimized aggregation with the data size, from scale factor 50 to 200. The trend is clear: the GPU is the fastest hardware in all scenarios, followed by the FPGA. They achieve 5.7→ (1.3 trillion tuples/s) and 2.7→ (620 billion tuples/s) higher throughput than the CPU (232 billion tuples/s), respectively. These results show that (1) our hardware-speci"c optimizations e#ectively eliminate the ine!ciencies in the uni"ed framework, and (2) hardware accelerators, when fully exploited, can provide signi"cantly faster aggregation than CPUs.
5.3
Figure 10: End-to-end performance. Dashed lines represent the throughput of CPU, GPU, and FPGA (top to bottom).
Figure 11: Energy consumption on di#erent hardware. billion tuples/s) are signi"cantly lower than that of the CPU (232 billion tuples/s). This result shows that even with advanced hardware today, to bene"t data analytics with hardware acceleration the host-device data transfer bottleneck must be addressed.
6
End-to-end Comparison
ENERGY CONSUMPTION
Kernel Power Consumption. When performing on-device aggregation, hardware accelerators are not only faster but also more energy-e!cient. Figure 11 shows that the CPU consumes 5.5 Joule (J) to aggregate 9.6 billion tuples (scale factor 200). In comparison, the FPGA consumes only 20% (1.1 J) and the GPU consumes only 10% (0.6 J) of the CPU power usage to aggregate the same tuples.
We "nally show the end-to-end perspective of aggregation performance, which accounts for the times of moving data from the host memory to the accelerator’s device memory. Figure 10 reports the results with hardware-speci"c optimizations on di#erent scale factors. Data transfers between the host and the accelerator via PCIe (v4.0) are the bottleneck: they contribute to 97.9% of the GPU execution time and 96.8% of the FPGA execution time. Hence, the throughputs of the GPU (61 billion tuples/s) and the FPGA (45
End-to-end Power Consumption. Similar "ndings in performance comparison also apply to energy consumption. When data 4
Hardware-accelerated Aggregation: Unification and Specialization
Conference’17, July 2017, Washington, DC, USA
transfers are included, the hardware accelerators consume signi"cantly more power than the CPU. Speci"cally, as the CPU aggregates the data in situ, its power consumption remains 5.5 J. The GPU is slightly more e!cient than the FPGA, but both accelerators consume more than 30 J to complete the end-to-end processing. This result con"rms that data transfers are the primary road blocker for developing e!cient hardware solutions for aggregation.
Extended Specialization. The current specialized code targets aggregation, e.g., SIMD reduction on the CPU and lockless reduction tree on the FPGA. In the future, we plan to expand these optimizations for more relational data analytical operators. Although some techniques, e.g., con"gured threads and fully-utilized memory channels, are applicable to all operators, other techniques, e.g., vectorized reduction, need adaptation for operators other than aggregation. We will also consider opportunities for fusing di#erent operators [37] on di#erent hardware platforms, which is crucial for more complex queries.
7
RELATED WORK
Aggregation on GPUs and FPGAs. The primary focus of recent work about accelerating aggregation with GPUs and FPGAs has been on group-by aggregations based on sorting or hashing. Specifically, on GPUs, Karnagel et al. [14] implemented a GPU architecture for hash-based group-by and tuned con"guration parameters to improve performance. Luan et al. [18, 19] studied CPU-GPU co-processing via inter-operator parallelization to optimize hashbased group-by and aggregation together. More recently, Wu et al. [36] investigated the ine!ciencies of GPU execution for jointhen-aggregate queries and proposed optimizations. On FPGAs, Zhang et al. [44] implemented various hash functions on FPGAs and use them to execute hash-based group-by. Moghaddamfar et al. [25] designed group-by aggregation with FPGA onchip cache and pipeline for enterprise DBMS. Xue et al. [40] developed a fully streaming FPGA pipeline for sorting-based group-by aggregation. Eryilmaz et al. [8] proposed a CPU-FPGA architecture for aggregation and a model that predicts the processing time. In comparison, we investigate the impact of uni"ed and specialized acceleration solutions on the foundational aggregation primitive and perform cross-hardware comparison. We also analyze the energy e!ciency of di#erent solutions.
End-to-end Optimizations. Despite orders of magnitude higher performance and energy e!ciency achieved in the kernel execution for the FPGA and the GPU, these accelerators are currently outperformed by the CPU due to expensive data transfers between the host and the device. We expect the cost to increase for other relational operators, e.g., joins, where more output data is moved from the accelerator to the host. This road blocker must be addressed to bene"t data analytics from hardware acceleration. An important future direction is to optimize data transfers between the host and the device. Existing work [21, 33] has exploited faster hostdevice interconnects and compression to speed up data transfers for certain operations, which are promising starting points. At-scale Uni"cation. TornadoVM has limited support for multidevice execution. As hardware accelerators are increasingly deployed in data centers, multi-accelerator data analytics are likely to become a commonplace in the future [41, 42]. We plan to investigate cross-device optimizations for large-scale data processing.
REFERENCES
[1] Martín Abadi, Paul Barham, Jianmin Chen, Zhifeng Chen, Andy Davis, Je#rey Dean, Matthieu Devin, Sanjay Ghemawat, Geo#rey Irving, Michael Isard, Manjunath Kudlur, Josh Levenberg, Rajat Monga, Sherry Moore, Derek Gordon Murray, Benoit Steiner, Paul A. Tucker, Vijay Vasudevan, Pete Warden, Martin Wicke, Yuan Yu, and Xiaoqiang Zheng. Tensor%ow: A system for large-scale machine learning. In Kimberly Keeton and Timothy Roscoe, editors, 12th USENIX Symposium on Operating Systems Design and Implementation, OSDI 2016, Savannah, GA, USA, November 2-4, 2016, pages 265–283. USENIX Association, 2016. [2] Alibaba Cloud Community . A detailed explanation about alibaba cloud cipu. https://www.alibabacloud.com/blog/ a-detailed-explanation-about-alibaba-cloud-cipu_599183, 2022. [3] Amin Vahdat. Announcing trillium, the sixth generation of google cloud tpu. https://cloud.google.com/blog/products/compute/ introducing-trillium-6th-gen-tpus, 2024. [4] AWS. Aws nitro system. https://aws.amazon.com/ec2/nitro/, 2024. [5] Sirish Chandrasekaran and Michael J. Franklin. Streaming queries over streaming data. In Proceedings of 28th International Conference on Very Large Data Bases, VLDB 2002, Hong Kong, August 20-23, 2002, pages 203–214. Morgan Kaufmann, 2002. [6] Databricks. Aggregate data on databricks. https://docs.databricks.com/aws/en/ transform/aggregation, 2025. [7] Je#rey Dean and Sanjay Ghemawat. Mapreduce: Simpli"ed data processing on large clusters. In Eric A. Brewer and Peter Chen, editors, 6th Symposium on Operating System Design and Implementation (OSDI 2004), San Francisco, California, USA, December 6-8, 2004, pages 137–150. USENIX Association, 2004. [8] Zubeyr F. Eryilmaz, Aarati Kakaraparthy, Rathijit Sen, Jignesh M. Patel, and Kwanghyun Park. FPGA for aggregate processing: The good, the bad, and the ugly. In 37th IEEE International Conference on Data Engineering, ICDE 2021, Chania, Greece, April 19-22, 2021, pages 1044–1055. IEEE, 2021. [9] Daniel Firestone, Andrew Putnam, Sambrama Mundkur, Derek Chiou, Alireza Dabagh, Mike Andrewartha, Hari Angepat, Vivek Bhanu, Adrian M. Caul"eld, Eric S. Chung, Harish Kumar Chandrappa, Somesh Chaturmohta, Matt Humphrey, Jack Lavier, Norman Lam, Fengfen Liu, Kalin Ovtcharov, Jitu Padhye, Gautham Popuri, Shachar Raindel, Tejas Sapre, Mark Shaw, Gabriel Silva, Madhan Sivakumar, Nisheeth Srivastava, Anshuman Verma, Qasim Zuhair, Deepak Bansal, Doug Burger, Kushagra Vaid, David A. Maltz, and Albert G. Greenberg. Azure accelerated networking: Smartnics in the public cloud. In 15th USENIX Symposium
Uni"ed hardware acceleration. Xekalaki et al. [39] adopted TornadoVM in Flink to accelerate various ML tasks with FPGAs and GPUs. We focus on aggregation and develop hardware-speci"c optimizations on top of the uni"ed framework.
8
CONCLUSION AND FUTURE DIRECTIONS
We investigated the bene"ts of popular data center hardware accelerators, i.e., FPGAs and GPUs, on data aggregation, compared to CPUs with performance and energy metrics. Our key contributions include implementing aggregation with a uni"ed acceleration framework (TornadoVM), developing hardware-speci"c optimizations, and evaluating these solutions on recent hardware. These results are useful for developing e!cient aggregation solutions. Our "ndings encourage the following directions for future explorations. Transparent Specialization. Our results reveal the trade-o# between ease of programming and e!ciency in the current uni"ed hardware acceleration framework. The fully hardware-specialized optimizations are manually implemented and separate from TornadoVM. It has a strong motivation to re%ect the specialized optimizations in a uni"ed framework to achieve both properties. However, doing so is challenging without heavy system modi"cations. A future direction is to incorporate hardware-speci"c characteristics within the TornadoVM’s backend, thereby moving specialization from applications to the framework. 5
Conference’17, July 2017, Washington, DC, USA
Shateri et al.
on Networked Systems Design and Implementation, NSDI 2018, Renton, WA, USA, 4278890, 2024. April 9-11, 2018, pages 51–66. USENIX Association, 2018. [25] Mehdi Moghaddamfar, Norman May, Christian Färber, Wolfgang Lehner, and [10] Juan Fumero, Michail Papadimitriou, Foivos S. Zakkak, Maria Xekalaki, James Akash Kumar. A study of early aggregation in database query processing on fpgas. Clarkson, and Christos Kotselidis. Dynamic Application Recon"guration on In Proceedings of the 2023 ACM/SIGDA Int. Symposium on Field-Programmable Heterogeneous Hardware. In Proceedings of the 15th ACM SIGPLAN/SIGOPS Gate Arrays (FPGA ’23), pages 55–65. ACM, 2023. International Conference on Virtual Execution Environments, VEE ’19. Association [26] René Müller, Jens Teubner, and Gustavo Alonso. Data processing on fpgas. Proc. for Computing Machinery, 2019. VLDB Endow., 2(1):910–921, 2009. [11] Robert J. Halstead, Ildar Absalyamov, Walid A. Najjar, and Vassilis J. Tsotras. Fpga[27] NVIDIA. Nvidia data center gpus: The heart of the modern data center. https: based multithreading for in-memory hash joins. In Seventh Biennial Conference //www.nvidia.com/en-us/data-center/data-center-gpus/, 2024. on Innovative Data Systems Research, CIDR 2015, Asilomar, CA, USA, January 4-7, [28] NVIDIA Developer. Write %exible kernels with 2015, Online Proceedings. www.cidrdb.org, 2015. grid-stride loops. https://developer.nvidia.com/blog/ [12] Bingsheng He, Ke Yang, Rui Fang, Mian Lu, Naga K. Govindaraju, Qiong Luo, cuda-pro-tip-write-%exible-kernels-grid-stride-loops/, 2013. and Pedro V. Sander. Relational joins on graphics processors. In SIGMOD 2008, [29] NVIDIA Developer. Cooperative groups: Flexible cuda thread programming. pages 511–524. ACM. https://developer.nvidia.com/blog/cooperative-groups/, 2017. [13] Uwe Jugel, Zbigniew Jerzak, Gregor Hackenbroich, and Volker Markl. M4: A [30] OpenCL. https://www.khronos.org/opencl/. 01 2022. [31] Ran Rui, Hao Li, and Yi-Cheng Tu. E!cient join algorithms for large database visualization-oriented time series data aggregation. Proc. VLDB Endow., 7(10):797– tables in a multi-gpu environment. Proc. VLDB Endow., 14(4):708–720, 2020. 808, 2014. [32] Anil Shanbhag, Samuel Madden, and Xiangyao Yu. A study of the fundamental [14] Tomas Karnagel, René Müller, and Guy M. Lohman. Optimizing gpu-accelerated performance characteristics of gpus and cpus for database analytics. In SIGMOD group-by and aggregation. In Rajesh Bordawekar, Tirthankar Lahiri, Bugra 2020, pages 1617–1632. ACM, 2020. Gedik, and Christian A. Lang, editors, International Workshop on Accelerating [33] Anil Shanbhag, Bobbi W. Yogatama, Xiangyao Yu, and Samuel Madden. TileData Management Systems Using Modern Processor and Storage Architectures based lightweight integer compression in GPU. In Zachary G. Ives, Angela ADMS 2015, Kohala Coast, Hawaii, USA, August 31, 2015, pages 13–24, 2015. Bonifati, and Amr El Abbadi, editors, SIGMOD ’22: International Conference on [15] Kushagra Vaid, General Manager, Azure Hardware Infrastructure. Improved Management of Data, Philadelphia, PA, USA, June 12 - 17, 2022, pages 1390–1403. cloud service performance through asic acceleration. https://azure.microsoft.com/ ACM, 2022. en-us/blog/improved-cloud-service-performance-through-asic-acceleration/, [34] Snow%ake. Aggregation placement — technical deep-dive and road 2019. to production. https://www.snow%ake.com/en/engineering-blog/ [16] Chang Liu, Jiaxing Zhang, Hucheng Zhou, Sean McDirmid, Zhenyu Guo, and aggregation-placement-technical-deep-dive-and-road-to-production, 2024. Thomas Moscibroda. Automating distributed partial aggregation. In Ed Lazowska, [35] Tableau. Data aggregation in tableau. https://help.tableau.com/current/pro/ Doug Terry, Remzi H. Arpaci-Dusseau, and Johannes Gehrke, editors, Proceedings desktop/en-us/calculations_aggregation.htm, 2025. of the ACM Symposium on Cloud Computing, Seattle, WA, USA, November 3-5, [36] Bowen Wu, Dimitrios Koutsoukos, and Gustavo Alonso. E!ciently processing 2014, pages 1:1–1:12. ACM, 2014. joins and grouped aggregations on gpus. Proc. ACM Manag. Data, 3(1):39:1–39:27, [17] Jiachen Liu, Fan Lai, Yinwei Dai, Aditya Akella, Harsha V. Madhyastha, and 2025. Mosharaf Chowdhury. Auxo: E!cient federated learning via scalable client [37] Bowen Wu, Dimitrios Koutsoukos, and Gustavo Alonso. E!ciently processing clustering. In Proceedings of the 2023 ACM Symposium on Cloud Computing, SoCC joins and grouped aggregations on gpus. Proc. ACM Manag. Data, 3(1):39:1–39:27, 2023, Santa Cruz, CA, USA, 30 October 2023 - 1 November 2023, pages 125–141. 2025. ACM, 2023. [38] Maria Xekalaki, Juan Fumero, Athanasios Stratikopoulos, Katerina Doka, Christos [18] Hua Luan and Lei Chang. An experimental study of group-by and aggregation Katsakioris, Constantinos Bitsakos, Nectarios Koziris, and Christos Kotselidis. on cpu-gpu processors. Journal of Engineering and Applied Science, 69(54), 2022. Enabling transparent acceleration of big data frameworks using heterogeneous [19] Hua Luan and Yan Fu. Optimising group-by and aggregation on the coupled hardware. Proc. VLDB Endow., 15(13):3869–3882, 2022. CPU-GPU architecture. Int. J. Comput. Sci. Eng., 27(2):219–229, 2024. [39] Maria Xekalaki, Juan Fumero, Athanasios Stratikopoulos, Katerina Doka, Christos [20] Clemens Lutz, Sebastian Breß, Ste#en Zeuch, Tilmann Rabl, and Volker Markl. Katsakioris, Constantinos Bitsakos, Nectarios Koziris, and Christos Kotselidis. Pump up the volume: Processing large data on gpus with fast interconnects. In Enabling transparent acceleration of big data frameworks using heterogeneous SIGMOD 2020, pages 1633–1649. ACM, 2020. hardware. Proc. VLDB Endow., 15(13):3869–3882, September 2022. [21] Clemens Lutz, Sebastian Breß, Ste#en Zeuch, Tilmann Rabl, and Volker Markl. [40] Haijun Xue, Shuai Wang, Xinxin Zhao, Hong Hao, Xiongru Wang, and Kai Pump up the volume: Processing large data on gpus with fast interconnects. Jiang. Fpga based database sort-aggregation query acceleration architecture. In In David Maier, Rachel Pottinger, AnHai Doan, Wang-Chiew Tan, Abdussalam Proceedings of the 9th Intl. Symposium on Computer and Information Processing Alawini, and Hung Q. Ngo, editors, Proceedings of the 2020 International Conference Technology (ISCIPT), pages 204–208. IEEE, 2024. on Management of Data, SIGMOD Conference 2020, online conference [Portland, [41] Bobbi W. Yogatama, Weiwei Gong, and Xiangyao Yu. Scaling your hybrid CPUOR, USA], June 14-19, 2020, pages 1633–1649. ACM, 2020. GPU DBMS to multiple gpus. Proc. VLDB Endow., 17(13):4709–4722, 2024. [22] Grzegorz Malewicz, Matthew H. Austern, Aart J. C. Bik, James C. Dehnert, Ilan [42] Yichao Yuan, Advait Iyer, Lin Ma, and Nishil Talati. Vortex: Overcoming memory Horn, Naty Leiser, and Grzegorz Czajkowski. Pregel: a system for large-scale capacity limitations in gpu-accelerated large-scale data analytics. Proc. VLDB graph processing. In Ahmed K. Elmagarmid and Divyakant Agrawal, editors, Endow., 18(4):1250–1263, 2024. Proceedings of the ACM SIGMOD International Conference on Management of Data, [43] Yuan Yuan, Rubao Lee, and Xiaodong Zhang. The yin and yang of processing SIGMOD 2010, Indianapolis, Indiana, USA, June 6-10, 2010, pages 135–146. ACM, data warehousing queries on GPU devices. Proc. VLDB Endow., 6(10):817–828, 2010. 2013. [23] Norman May, Daniel Ritter, Andre Dossinger, Christian Faerber, and Süley[44] Hui Zhang, Dexing Jia, Lei Chen, Xiongru Wang, Shuai Wang, and Rui Li. Acman Sirri Demirsoy. DASH: asynchronous hardware data processing services. In celeration and implementation of database aggregation query based on fpga. In 13th Conference on Innovative Data Systems Research, CIDR 2023, Amsterdam, The Proceedings of the 2023 China Automation Congress (CAC), pages 817–822. IEEE, Netherlands, January 8-11, 2023. www.cidrdb.org, 2023. 2023. [24] Microsoft. Boosting power bi performance with azure [45] Qizhen Zhang, Hongzhi Chen, Da Yan, James Cheng, Boon Thau Loo, and Pudatabricks through automatic aggregations. https: rushotham V. Bangalore. Architectural implications on the performance and cost //techcommunity.microsoft.com/blog/analyticsonazure/ of graph analytics systems. In SoCC 2017, Santa Clara, CA, USA, September 24-27, boosting-power-bi-performance-with-azure-databricks-through-automatic-aggregatio/ 2017, pages 40–51. ACM.
6