Metadata-Version: 2.4
Name: mopr
Version: 0.0.70
Summary: Monorepo Optimal Portable Runtime
Author: Quant1X
Author-email: Quant1X <wangfengxy@sina.cn>
License-Expression: AGPL-3.0-only
Project-URL: Homepage, https://github.com/quant1x/mopr
Keywords: monorepo,portable-runtime,benchmark,performance
Requires-Python: >=3.12
Description-Content-Type: text/markdown
License-File: LICENSE
Requires-Dist: loguru>=0.7.3
Requires-Dist: python-dotenv>=1.0.0
Requires-Dist: pandas>=2.1.0
Requires-Dist: apscheduler~=3.11.3
Requires-Dist: PyYAML>=6.0
Requires-Dist: requests>=2.32.0
Dynamic: license-file

# MOPR

> **单仓最优可移植运行时**
> *Monorepo Optimal Portable Runtime*
>
> 统一规范，基准驱动，**性能第一，正确与稳定是隐含前提**。
>
> 读作 *M-O-P-R*（或 *mopr*，/mɑpr/）。

---

## 项目简介

MOPR 是在统一规范约束下，以多轮基准测试为验证手段，从所有异构实现中筛选并维护性能最优运行时解的项目。它不是“基础库”，也不是“标准实现”——它的定位是**标杆实现**：为同一份规范下的其他实现提供可量化的性能参照与验证基准。

### 核心概念

| 概念 | 定义 | 职责 |
| --- | --- | --- |
| Spec | 规范 | 定义行为契约与接口边界，划定实现必须遵守的范围 |
| Benchmark | 基准测试 | 以多轮、多维度的量化测试验证实现，产出排名依据 |
| MOPR | 标杆实现 | 满足 Spec 与 Benchmark 验证的前提下，性能最优的实现 |

## 设计原则

### 1. 性能第一，正确与稳定是隐含前提

性能是优化方向与排名依据的第一优先级。正确性与稳定性并非与性能并列的取舍维度，而是参与性能排名的前置条件：不满足正确性与稳定性验证的实现，不具备参与性能排名的资格。

每一轮基准测试同时覆盖三个维度：

- **正确性**：输出是否符合 Spec 定义的行为契约
- **稳定性**：长时间运行、压力与边界条件下是否可靠
- **性能**：在前两者满足的前提下，是否达到最优

正确性与稳定性作为过滤条件，性能作为排序依据。

### 2. Spec 统一，实现自由

Spec 定义行为契约与接口边界。同一份规范下允许存在多种异构实现，MOPR 是其中经过多轮基准测试反复验证、在目标平台上始终正确且性能最优的实现，作为其他实现的对标基准。

### 3. 基准测试是设计驱动力

每个设计决策都必须回答一个问题：**该改动是否提升性能？** 其成立前提是不得破坏正确性与稳定性——若基准数据改善但正确性或稳定性测试失败，则该改动不成立。

### 4. 可移植性不等于性能下限

MOPR 在不同平台上分别追求该平台能达到的最高性能，而非让所有平台退化为同一套低性能通用实现。平台相关的极致优化是核心策略，但每份平台实现都必须先通过正确性与稳定性验证。

## 基准测试体系

基准测试套件按验证目标分为四类：

| 目录 | 类型 | 验证目标 |
| --- | --- | --- |
| `benchmark/micro/` | 微基准 | 吞吐、延迟、内存占用 |
| `benchmark/macro/` | 场景基准 | 端到端性能 |
| `benchmark/stability/` | 稳定性测试 | 长时间运行、压力、边界条件 |
| `benchmark/regression/` | 回归检测 | 性能劣化监测 |

只有通过正确性与稳定性验证的实现，其性能数据才纳入排名与对照。

## 项目结构

```
mopr/
├── spec/           # 规范定义
│   ├── api.md      # 接口契约
│   └── behavior.md # 行为语义
├── base/           # 基础组件：cache / mem / mmap / cron / timestamp ...
├── runtime/        # 运行时：ringbuffer / scheduler / once ...
├── distributed/    # 分布式：id（HLC / 生成器 / 状态存储）
├── encoding/       # 编码：csv / charsets / json / base64 / barcode ...
├── storage/        # 存储抽象
├── security/       # 安全：auth / audit / compliance
├── machine/        # 机器标识
├── log/            # 日志
├── finance/        # 金融：forex / exchange
├── benchmark/      # 基准测试套件
│   ├── micro/      # 微基准：吞吐、延迟、内存
│   ├── macro/      # 场景基准：端到端性能
│   ├── stability/  # 稳定性：长时间运行、压力、边界
│   └── regression/ # 性能回归检测
├── tests/          # 跨语言测试用例
├── docs/           # 设计决策记录
│   └── proposals/  # 提案（RFC）：跨语言语义 / 契约变更的决策过程
└── tools/          # 辅助工具（许可审计、许可证头）
```

**仓库根即实现根**：不设 `src/` 层，功能模块目录直接平铺在仓库根，同一功能的多语言实现共处同一目录、同名不同后缀（如 `base/mmap.py` / `base/mmap.h` / `base/mmap.rs` / `base/mmap/mmap.go`；各语言入口 `main.cpp` / `main.rs` 同样平铺在根）。

- **与 Go 的 package 对齐**：Go 的包边界以目录划分，功能模块目录因此与 Go 的 `package` 一一对应（`distributed/id` 即 `package id`）；C++ 命名空间第二级（`distributed/id/hlc.h` → `mopr::distributed::id`）、Python 子模块路径、Rust `mod` 路径均取自同一目录路径，保证同一功能在各语言的模块语义相同。
- **平台无关核心与平台极致优化就地组织**：核心语义落在各模块的公共实现中，平台相关优化留在同一模块内，按文件名后缀（`_posix` / `_windows` / `_unsupported`）或条件编译区分，不另设 `core/` / `platform/` 目录。

这些约定只服务一件事：**让同一语义在各语言占据同一位置**——看到 `mmap.py`，顺手就能看到 `mmap.h` / `mmap.rs` / `mmap/mmap.go`，跨语言对照不必先找路径。完整论证（层级为何由语言工具链决定、按语言分目录为何是反例、对 AI 的友好之处）见 [docs/directory-layout-rationale.md](docs/directory-layout-rationale.md)。

## 语言与版本要求

MOPR 是单仓多语言库（monolibrary），同一份规范下将来会有多种语言实现。各语言的版本基线由本项目独立维护，不要求与同系列 `quant1x` 仓库同步：

| 语言 | 最低版本 | 推荐版本 |
| --- | --- | --- |
| Python | 3.12+ | 3.12.x |
| C++ | C++20 | GCC 13+ / Clang 17+ / MSVC 14.3+ |
| Rust | 1.98.1+ | 1.98.1+（2024 edition） |
| Go | 1.27+ | 1.27.x |
| Java | 8+ | JDK 8 及以上（见 `pom.xml` 的 `java.version`） |

- 当前仓库实现以 **C++20 + MSVC v143（Visual Studio 2022）+ CMake（≥3.25）/ Conan 2** 为主，构建细节见 [BUILDING.md](BUILDING.md)。
- 后续新增 Python / Rust / Go / Java 实现时，须遵循上表最低版本基线，不得使用低于基线的语言特性与 API；版本表变更由本项目独立评估。

## 快速开始

当前 C++ 工程（CMake + Conan 2）的构建与编译步骤见 [BUILDING.md](BUILDING.md)。

```text
// TODO: 基准运行示例，待接口定义完成后补充
```

## 项目状态与路线图

🚧 早期阶段 — Spec 正在起草中，实现尚未稳定。

当前推进顺序：

1. 起草 Spec：确定 `spec/api.md`（接口契约）与 `spec/behavior.md`（行为语义）
2. 搭建基准测试套件与验证流程
3. 基于平台无关核心实现首个基准实现
4. 开展平台相关优化，并逐平台完成正确性、稳定性与性能验证

## License / 协议

本项目采用 **GNU Affero General Public License v3**（[AGPL-3.0](LICENSE) / SPDX: `AGPL-3.0-only`）授权。

- 允许自由使用、复制、修改与再分发，但派生作品必须同样以 AGPLv3 发布（强 Copyleft）。
- 通过网络提供服务的修改版本（含远程交互）须按第 13 条向用户开放对应源码。
- 完整条款见根目录 [LICENSE](LICENSE) 文件。

Copyright (C) 2026 Quant1X <wangfengxy@sina.cn>
