Demo Data from VLDB 2026 / reviewers in the wild / expert
David Majnemer
dblp:201/4809
· DBLP profile ↗
2ranked-venue papers
0as first author
1since 2021 · last 2022
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Artificial intelligence and machine learning · 1 · 1 since 2021Software engineering, systems software and programming languages · 1
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Databases, data mining, and information retrieval
1 paper |
Information retrieval · 100% | |
| Computer architecture, parallel and distributed computing, and storage systems
1 paper |
Hardware accelerators and domain-specific architectures · 100% | |
| Software engineering, system software, and programming languages
1 paper |
Compilers and program optimization · 100% |
Topics — the 7 heaviest of 7, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Information retrieval › similarity search › nearest neighbor search
approximate nearest neighbor search |
0.6 | 1 | 2022 | TPU-KNN: K Nearest Neighbor Search at Peak FLOP/s · NeurIPS 2022 |
Information retrieval › similarity search
nearest neighbor search |
0.6 | 1 | 2022 | TPU-KNN: K Nearest Neighbor Search at Peak FLOP/s · NeurIPS 2022 |
Hardware accelerators and domain-specific architectures
machine learning accelerator |
0.6 | 1 | 2022 | TPU-KNN: K Nearest Neighbor Search at Peak FLOP/s · NeurIPS 2022 |
Hardware accelerators and domain-specific architectures › tensor accelerator
tensor processing unit |
0.6 | 1 | 2022 | TPU-KNN: K Nearest Neighbor Search at Peak FLOP/s · NeurIPS 2022 |
Compilers and program optimization
compiler correctness |
0.3 | 1 | 2017 | Taming undefined behavior in LLVM · PLDI 2017 |
Compilers and program optimization › compiler correctness
compiler optimization correctness |
0.3 | 1 | 2017 | Taming undefined behavior in LLVM · PLDI 2017 |
Compilers and program optimization
intermediate representation |
0.3 | 1 | 2017 | Taming undefined behavior in LLVM · PLDI 2017 |
Methods — techniques the papers use, named apart from their topics
recall analysis · 1.1performance modeling · 1.1loop unswitching · 0.3global value numbering · 0.3IR semantics design · 0.3
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2022 | TPU-KNN: K Nearest Neighbor Search at Peak FLOP/sabstractThis paper presents a novel nearest neighbor search algorithm achieving TPU (Google Tensor Processing Unit) peak performance, outperforming state-of-the-art GPU algorithms with similar level of recall. The design of the proposed algorithm is motivated by an accurate accelerator performance model that takes into account both the memory and instruction bottlenecks. Our algorithm comes with an analytical guarantee of recall in expectation and does not require maintaining sophisticated index data structure or tuning, making it suitable for applications with frequent updates. Our work is available in the open-source package of Jax and Tensorflow on TPU. Felix Chern, Blake Hechtman, Andy Davis, David Majnemer, Sanjiv Kumar |
NeurIPS | 5 |
| 2017 | Taming undefined behavior in LLVMabstractA central concern for an optimizing compiler is the design of its intermediate representation (IR) for code. The IR should make it easy to perform transformations, and should also afford efficient and precise static analysis. In this paper we study an aspect of IR design that has received little attention: the role of undefined behavior. The IR for every optimizing compiler we have looked at, including GCC, LLVM, Intel's, and Microsoft's, supports one or more forms of undefined behavior (UB), not only to reflect the semantics of UB-heavy programming languages such as C and C++, but also to model inherently unsafe low-level operations such as memory stores and to avoid over-constraining IR semantics to the point that desirable transformations become illegal. The current semantics of LLVM's IR fails to justify some cases of loop unswitching, global value numbering, and other important "textbook" optimizations, causing long-standing bugs. We present solutions to the problems we have identified in LLVM's IR and show that most optimizations currently in LLVM remain sound, and that some desirable new transformations become permissible. Our solutions do not degrade compile time or performance of generated code. Juneyoung Lee, Yoonseung Kim, Youngju Song, Chung-Kil Hur, Sanjoy Das, David Majnemer, John Regehr, Nuno P. Lopes |
PLDI | 6 |