---
title: Archer in Computer Science Research
url: https://www.emergentmind.com/topics/archer
type: topic
---

# Archer in Computer Science Research

Searching arXiv for relevant "Archer" papers to ground the article.
Searching arXiv for "Archer".
In arXiv literature, **Archer** denotes several technically unrelated artifacts rather than a single research object. The term names a **community-distributed computing infrastructure** for computer architecture research and education, appears as **ARCHER** in work on the UK national supercomputing service and on a GPU-accelerated Monte Carlo CT dose engine, identifies **Aggressive Rewards to Counter bias in Hindsight Experience Replay** in reinforcement learning, titles a **human-labeled bilingual text-to-SQL dataset**, and labels an **agentic code review tool for compiler optimizations**. Separately, **Archer** also appears as an authorial reference in combinatorics and algorithmic mechanism design, where later papers resolve conjectures or extend frameworks introduced by Archer and collaborators [0807.1765] [1906.03884] [1908.00360] [1809.02070] [2402.12554] [2607.01808] [0907.3068].

## 1. Archer as a community-distributed computing infrastructure

Archer was introduced as a **community-distributed computing infrastructure** designed specifically to support **computer architecture research and education** by turning geographically separated, institutionally owned machines into a single, high-throughput computing environment. Its core composition is explicit: **virtual machine appliances** as the unit of deployment, **a self-configuring virtual network overlay** for connectivity across NATs and firewalls, **Condor batch scheduling middleware** for distributed job management and resource sharing, and **community-contributed hardware and software resources** for both computation and simulation artifacts. The paper describes the resulting environment as a **“Wide-area Overlay of virtual Workstations (WOW)”**, presented to users as a cohesive HTC system [0807.1765].

The motivation was the centrality of **quantitative simulation** in computer architecture research, especially detailed, cycle-accurate simulators, multiple benchmark suites, and large configuration sweeps that generate **massive numbers of CPU-intensive jobs**. Archer was therefore framed as a way to reduce barriers created by **lack of access to high-throughput computing capacity**, **high costs of hardware and administration**, **the time and expertise needed to deploy and maintain shared systems**, and **difficulty sharing not just machines, but also complete simulation environments**. The stated design goals were **scalability with community buy-in**, **ease of joining and use**, and a **repository of reusable simulation environments** containing code, data, scripts, and documentation [0807.1765].

Its implementation relied on a VM layer, the **IPOP self-configuring virtual network overlay**, and **Condor**. Each compute node was a preconfigured Linux virtual appliance capable of running existing binary software unmodified, including tools such as **SimpleScalar**, **SESC**, **PTLsim**, and **Simics**. IPOP provided IP connectivity among appliances, support for nodes behind **firewalls and NATs**, and self-organization without user network configuration. Condor supplied job submission and queueing, resource monitoring, workflow and job supervision, fault tolerance, scalable scheduling, and support for both dedicated and opportunistic resources. A central mechanism was **Condor flocking**, which allowed local pools to lend idle cycles to the wider community while preserving local priority policies [0807.1765].

The prototype wide-area deployment evaluated **200 jobs** submitted from a virtual appliance on a laptop behind a **1 MB/s broadband connection**, executed across **56 VMs** distributed across **five universities**. The workload was a **cache simulation** using **SimpleScalar sim-cache** on SPEC **`go`**, with each job simulating **1 billion instructions** under varying **L1 cache size**, **L2 cache size**, and **associativity**. The system completed the batch in about **7.5 hours**; on a single node, the same workload would have taken about **9.5 days**. In steady state, Archer completed about **one job every 90 seconds**, whereas a single resource would have managed about **one job per 42 minutes**. The reported **median single-job execution time** was **4080 seconds**, the **average single-job execution time** was **4320 seconds**, and VMware-based virtualization overhead for this workload was **11%**; the paper also notes prior Xen results of roughly **1% overhead** for a similar SimpleScalar workload [0807.1765].

The system’s significance lay in its specific combination of **wide-area aggregation**, **support for unmodified simulation software**, **NAT/firewall traversal**, **local autonomy**, and the sharing of complete experiment environments rather than bare compute cycles alone. A plausible implication is that Archer treated reproducibility and throughput as coupled infrastructure problems rather than as separate concerns.

## 2. ARCHER as a national supercomputing service and an object of I/O analytics

In a distinct usage, **ARCHER** denotes the **UK national supercomputing service**, analyzed through Cray’s **LASSi** and EPCC’s **SAFE**. In that setting, ARCHER is described as a **4,920-node Cray XC30 system with over 118,000 Ivy Bridge cores** and **three Lustre file systems**, each based on Cray Sonexion 1600 appliances. The monitoring problem arose because users reported runtime variation, slow jobs, and poor interactive filesystem response, while the workload mixed many domains on common shared resources [1906.03891] [1906.03884].

LASSi was developed to analyze application usage and contention caused by use of shared resources, especially the Lustre filesystem. It defined **risk metrics** intended to quantify how unusual or potentially harmful an application’s I/O behavior is relative to filesystem norms, and **ops metrics** intended to capture I/O quality. For any filesystem operation \(x\), the per-filesystem risk was defined as
\[
risk_{fs}(x) = \frac{x-\alpha*avg_{fs}(x)}{\alpha*avg_{fs}(x)},
\]
with \(\alpha = 2\) in the analysis. Aggregate risks were then defined by
\[
risk_{oss} = risk_{read\_kb} + risk_{read\_ops} + risk_{write\_kb} + risk_{write\_ops} + risk_{other},
\]
and
\[
risk_{mds} = risk_{open} + risk_{close} + risk_{getattr} + risk_{setattr} + risk_{mkdir} + risk_{rmdir} + risk_{mknod} + risk_{link} + risk_{unlink} + risk_{ren} + risk_{getxattr} + risk_{setxattr} + risk_{statfs} + risk_{sync} + risk_{cdr} + risk_{sdr}.
\]
Non-positive contributions were ignored. For I/O quality, LASSi defined
\[
read\_kb\_ops = \frac{read\_ops * 1024}{read\_kb}, \qquad write\_kb\_ops = \frac{write\_ops * 1024}{write\_kb},
\]
with **1 MB per operation** described as optimal, so the preferred values were **0 for risk** and **1 for ops** [1906.03884] [1906.03891].

Operationally, LASSi combined Lustre statistics with scheduler or PBS information to attribute I/O activity to application runs and generate automated reports. The workflow used **LAPCAT**, **Cerebro**, **MySQL**, scheduler or **ALPS** logs, and implementations in **PySpark**, **C**, and **Scala**; the reporting layer used **Python** and **matplotlib**. The papers emphasize that investigations that had previously taken **several days**, or **a day or two**, could typically be reduced to a diagnosis performed **“in a moment”** or **in minutes** by using automated daily reports [1906.03884] [1906.03891].

The broader system-level study imported LASSi-derived per-job I/O data into SAFE and analyzed **all jobs run on ARCHER from July to December 2018**. Over that period, the papers report **11,279.4 TiB read** and **22,094.3 TiB written**, with jobs on ARCHER **writing roughly twice as much as they read**. The studies also emphasize that the same application can stress different filesystem components depending on how it is run, and that metadata-heavy behaviors such as directory-creation storms or task-farm-style workloads can generate disproportionate **MDS risk** even when individual jobs do not look exceptional in isolation [1906.03891].

This usage of ARCHER differs categorically from the 2008 architecture-research infrastructure. Here ARCHER is a national HPC service, and the research focus is not resource federation but **operational observability**, **contention attribution**, and the analysis of filesystem stress under production load.

## 3. ARCHER as a GPU-accelerated Monte Carlo CT dose engine

In medical physics, **ARCHER** refers to a **GPU-accelerated Monte Carlo photon transport / dose computing engine** used for patient-specific CT dosimetry. The relevant workflow couples **deep-learning-based multi-organ segmentation** from each patient’s CT scan with **GPU-accelerated Monte Carlo dose computation** using ARCHER. The paper describes ARCHER as simulating **low-energy X-ray photon transport in CT anatomy** and computing voxel-wise dose maps from a CT scan protocol and a patient-specific anatomical model [1908.00360].

The segmentation component used a **3D U-Net–based convolutional neural network** trained on two public datasets: **Lung CT Segmentation Challenge 2017 (LCTSC)**, with **60 thoracic CT scan patients** and **5 segmented organs**, and **Pancreas-CT (PCT)**, with **43 abdominal CT scan patients** and **8 segmented organs**. Preprocessing included HU clipping to **[-200, 300]**, normalization to **[0, 1]**, cropping to body contour or ROI, and downsampling. The network used an encoder-decoder structure with **4 repeated residual blocks** in the encoder, **4 repeated segmentation blocks** in the decoder, **3×3×3 convolutions**, **instance normalization**, **leaky ReLU**, stride **2×2×2** downsampling, skip connections, and a final **1×1×1 convolution** followed by **SoftMax**. Reported median DSCs included **0.97** for the right lung, **0.96** for the left lung, **0.93** for the heart, **0.88** for the spinal cord, **0.78** for the esophagus, **0.96** for the spleen and liver, **0.95** for the left kidney, **0.89** for the stomach, **0.87** for the gallbladder, **0.79** for the pancreas, **0.74** for the esophagus, and **0.64** for the duodenum; the segmentation step took **less than 5 seconds per patient** [1908.00360].

ARCHER then computed dose maps using a previously validated **GE Lightspeed Pro 16 MDCT scanner model** with **120 kVp**, **20 mm beam collimation**, **axial body scan**, **100 mAs**, and scanner rotation modeled by **step-and-shoot** with **16 discrete positions** per rotation. Once voxel-wise doses were generated, organ masks from the CNN were overlaid to compute **mean absorbed dose for each organ**. The evaluation used **Relative Dose Error (RDE)**,
\[
RDE = \frac{D - D_r}{D_r} \times 100\%,
\]
where \(D_r\) was the ARCHER dose computed on the manually segmented patient anatomy [1908.00360].

Compared with population-average phantoms from **VirtualDose**, the patient-specific workflow produced much narrower RDE ranges. Reported examples include **lung** at **-4.3% to 1.5%** versus **-31.5% to 33.9%**, **heart** at **-7.0% to 2.3%** versus **-15.2% to 125.1%**, **spleen** at **-5.6% to 1.6%** versus **-20.3% to 57.4%**, **pancreas** at **-4.5% to 4.6%** versus **-19.5% to 61.0%**, and **liver** at **-0.9% to 1.6%** versus **-30.1% to 72.5%**. The dose computation used **1 × 10^8 photons**, achieved **< 0.5%** statistical uncertainty in all organ doses, and took **less than 4 seconds per patient** [1908.00360].

In this literature, ARCHER is neither an HPC service nor a distributed system. It is the physics engine in a workflow whose defining property is the coupling of **patient-specific anatomy** and **rapid Monte Carlo dose estimation**.

## 4. Archer as the name of methods, datasets, and automated reasoning systems

In reinforcement learning, **ARCHER** expands to **Aggressive Rewards to Counter bias in Hindsight Experience Replay**. The method modifies HER by introducing two scalar weights, \(\lambda_r\) for real rewards and \(\lambda_h\) for hindsight rewards, so that
\[
r_t = \lambda_r \times r(s_t, a_t, g), \qquad r_t^h = \lambda_h \times r(s_t, a_t, g^h).
\]
The stated aim is to counter the bias introduced when HER relabels failed trajectories with hindsight goals while reusing the same actions as if they had been sampled under the new goal condition. For **positive reward** tasks the paper uses \(\lambda_r < \lambda_h\); for **negative reward** tasks it uses \(\lambda_r > \lambda_h\). Experiments on **Reacher** and **Finger** from the DeepMind Control Suite, under sparse negative rewards, sparse positive rewards, dense negative rewards, shaped rewards, and both **final** and **future** goal-sampling strategies, are reported as showing improved sample efficiency when hindsight rewards are made numerically more aggressive [1809.02070].

In semantic parsing, **Archer** is a **human-labeled bilingual text-to-SQL dataset** designed specifically for **arithmetic reasoning**, **commonsense reasoning**, and **hypothetical reasoning**. It contains **1,042 English questions**, **1,042 Chinese questions**, **521 unique SQL queries**, **20 English databases**, and **20 domains**. The paper reports **7.55 tables per database**, **45.25 columns per database**, **average question length: 34.0 tokens in English, 47.8 in Chinese**, **average SQL length: 79.71**, **average number of tables mentioned in SQL: 2.17**, **average nested level per SQL: 1.08**, **average value slots per question: 6.21**, **44.0% hypothetical reasoning**, **51.4% commonsense reasoning**, and **100% arithmetic reasoning**. Its headline evaluation result is that **GPT-4 + DIN-SQL** achieved only **6.73% execution accuracy** on the Archer test set, despite a cited **85.3%** execution accuracy on Spider for the same method [2402.12554].

In compiler engineering, **Archer** is presented as the **first automated agentic code review tool for compiler optimizations**, built for LLVM middle-end optimization patches. Its architecture combines **dynamic obligation construction** with a **deterministic validation guard**. Obligations are extracted from historical correctness fixes, grouped by pass, turned into executable IR pairs, validated with a checker such as **Alive2**, and summarized into pass-level obligation bases. The validation guard materializes candidate cases from a strategy \(\sigma\), transforms the source IR with the post-patch compiler, runs **ProofCheck** and, if necessary, **TestCheck** with **LLUBI**, and admits only findings that are both **oracle-checkable** and **patch-triggered**. On a real-world dataset of **398 total PRs**—**70 open** and **328 closed**—the paper reports **51 semantic bugs**, including **15 bugs in open PRs** and **36 bugs in closed PRs**; it states that **21% of open PRs** and **11% of closed PRs** were buggy [2607.01808].

These three usages share the label **Archer** while differing sharply in ontology: one is a reward-reweighting method in off-policy RL, one is a bilingual benchmark for reasoning-heavy SQL generation, and one is an evidence-driven agentic review system for compiler correctness.

## 5. Archer in combinatorics, permutation theory, and rooted forests

In several combinatorial papers, Archer appears through earlier definitions and conjectures later proved or generalized by other authors. One line concerns **pattern avoidance of cyclic permutations**. Archer et al. introduced avoidance in **one-line form** and in **all cycle forms**, and the set
\[
\mathcal{A}_n^\circ(\sigma;\tau)
\]
for cyclic permutations that avoid \(\sigma\) in one-line form and \(\tau\) in all cycle forms. The note "On a conjecture about pattern avoidance of cycle permutations" proves that
\[
\left|\mathcal{A}_n^\circ(2431;1324)\right| = P_{n-1},
\]
where \(P_n\) denotes the Pell numbers, thereby giving a **positive answer** to Archer et al.’s conjecture [2409.17482].

A second line concerns **quasi-Stirling permutations**, introduced by Archer, Gregory, Pennington, and Slayden as permutations of \(\{1,1,2,2,\dots,n,n\}\) avoiding \(1212\) and \(2121\). Elizalde proves Archer et al.’s conjecture that the number of quasi-Stirling permutations of size \(n\) with the maximum number of descents is
\[
(n+1)^{n-1}.
\]
The paper also derives the descent generating function through
\[
Q(t,z)=A\bigl(t,\,zQ(t,z)\bigr),
\]
proves asymptotic normality with
\[
\mathbb E[X_n]=\frac{3n+1}{4},
\]
and states that the corresponding quasi-Stirling polynomials have only real, distinct, nonpositive roots [2002.00985].

A third line extends Archer and Geary’s work on **descents in powers of permutations**. For all \(k\in\mathbb Z^+\) and \(n\ge 2k+1\), the paper "Descents and inversions in powers of permutations" proves
\[
\frac1{n!}\sum_{\pi\in\mathcal{S}_n}\des(\pi^k) = \frac{n-1}{2} -\frac{\tau^2(k)-\tau(k)-\eta(k)+\sigma(k)}{2n},
\]
where \(\tau(k)\) is the number of divisors of \(k\), \(\sigma(k)\) is the sum of divisors, and \(\eta(k)\) is the number of odd divisors of \(k\). Setting \(k=2\) or \(k=3\) yields
\[
\frac{n-1}{2}-\frac{2}{n},
\]
which exactly confirms Archer–Geary’s conjecture for those cases [2408.01211].

Archer also appears in the rooted-forest pattern-avoidance literature through **Anders and Archer**. The paper "Classical and consecutive pattern avoidance in rooted forests" generalizes their results by constructing bijections between forests avoiding patterns that differ by swapping the last two values, introducing **forest-Young diagrams**, extending **shape-Wilf equivalence** to forests, and adapting the **Goulden–Jackson cluster method** to consecutive pattern avoidance in rooted trees. One notable result is that \(1324\) and \(1423\) are **strong-c-forest-Wilf equivalent**, even though they are not c-Wilf equivalent with respect to permutations [2005.08889].

Across these works, Archer functions as a source of initial definitions, bijections, and conjectures that later papers resolve exactly, often by deriving explicit recurrences, bijections, or generating-function identities.

## 6. Archer and the truthful scheduling framework for related machines

In algorithmic mechanism design, Archer’s most prominent appearance is through the **Archer–Tardos** framework for truthful scheduling on related machines. The problem is \(Q\|\|C_{\max}\), where machine \(i\) has private speed \(s_i\), job \(j\) has size \(p_j\), and processing time is
\[
t_{ij} = \frac{p_j}{s_i}.
\]
Archer and Tardos are credited with showing that an algorithm minimizing makespan can be truthfully implemented because the optimal allocation is monotone, although their mechanism was **exponential-time** [0907.3068].

The paper "A deterministic truthful PTAS for scheduling related machines" presents itself as a direct continuation of that line of work and resolves the open question of whether a **deterministic truthful PTAS** exists. Its main theorem states that for every \(0<\varepsilon<1\), the deterministic algorithm **PTAS** outputs a \((1+3\varepsilon)\)-approximate optimal allocation in polynomial time. The construction relies on **canonical allocations**, an **\(\varepsilon\)-division** of a machine’s job set \(P\) into large and small jobs, a directed layered **configuration graph** \(H_I\), dynamic programming over configurations, deterministic tie-breaking, and a monotonicity proof establishing that a machine that reports a lower speed cannot receive more work. Once monotonicity is proved, the Archer–Tardos payment formula yields a truthful mechanism [0907.3068].

This line of work is distinct from the many systems and datasets named Archer, but it is central to the surname’s presence in theoretical computer science. Here the term does not name an artifact at all; it denotes a foundational authorial contribution around **monotonicity**, **truthfulness**, and the interface between approximation and efficient mechanism design.

Source: https://www.emergentmind.com/topics/archer