fix install

Author: NADOOITChristophBa

Agent/README.md

@@ -0,0 +1,52 @@
+# Agent Plan: Make Fork a Drop-in Replacement for Official CTranslate2 (pip install)
+
+## Objective
+Ensure that this fork of CTranslate2 can be installed via pip (from Git or local path) and behaves as a true drop-in replacement for the official package, including building the Python native extension and matching the official Python API and directory layout.
+
+---
+
+## Step-by-Step Plan
+
+### 1. **Audit and Sync Python Packaging**
+- [ ] Compare `python/` directory structure and contents with the official CTranslate2 repo.
+- [ ] Ensure all packaging files (`setup.py`, `pyproject.toml`, `CMakeLists.txt`) match upstream or are compatible.
+- [ ] Confirm all required `.cc` files and Python modules are present.
+
+### 2. **Test Clean pip Install**
+- [ ] In a fresh virtual environment, run:
+  ```sh
+  pip install git+https://github.com/NADOOIT/CTranslate2.git
+  python -c "import ctranslate2; print(ctranslate2.__version__)"
+  ```
+- [ ] Confirm that `ctranslate2` imports and the native extension (`_ext.*.so`) is present in `site-packages/ctranslate2`.
+
+### 3. **Fix Any Build or Packaging Issues**
+- [ ] If the build fails or no `.so` is installed, check:
+    - CMake errors or missing dependencies
+    - Extension sources and install paths
+    - `setup.py`/`pyproject.toml` configuration
+- [ ] Update packaging files or CMake as needed for compatibility.
+
+### 4. **Automate and Document**
+- [ ] Add or update a `README.md` in the fork with clear install/build instructions.
+- [ ] Optionally, add a GitHub Actions workflow to test pip install and import on push/PR.
+
+### 5. **(Optional) Build and Upload Wheels**
+- [ ] Build a wheel (`pip wheel .` or `python -m build`) for your fork.
+- [ ] Upload to a private index or GitHub Release for even easier installs (optional).
+
+---
+
+## Deliverables
+- This plan and all supporting scripts/docs in the `Agent/` folder.
+- A fork that can be installed via pip as a drop-in replacement for the official CTranslate2.
+- Documentation and (optionally) CI for ongoing compatibility.
+
+---
+
+## Progress Tracking
+- [ ] Audit complete
+- [ ] Clean pip install tested
+- [ ] Issues fixed
+- [ ] Documentation updated
+- [ ] (Optional) Wheel built and/or CI added

Agent/plan_steps.md

@@ -0,0 +1,55 @@
+# Agent Execution Steps: Drop-in CTranslate2 Fork
+
+This file tracks the concrete steps and findings as we execute the plan from README.md.
+
+---
+
+## 1. Audit and Sync Python Packaging
+
+### a. Directory Structure
+- [x] `python/` exists with `setup.py`, `pyproject.toml`, and `cpp/` sources.
+- [x] `python/ctranslate2/` exists with `__init__.py`, `_ext.*.so`, and all required submodules.
+
+### b. Packaging Files
+- [x] `setup.py` present, custom build logic for C++/Metal extension.
+- [x] `pyproject.toml` present, declares build dependencies.
+- [ ] Compare these files line-by-line with upstream for subtle differences.
+
+### c. CMake Integration
+- [x] Top-level `CMakeLists.txt` present.
+- [ ] Confirm Python extension is built and installed to correct location by CMake.
+
+---
+
+## 2. Test Clean pip Install
+- [ ] Create a fresh virtual environment.
+- [ ] Run `pip install .` from the `python/` directory.
+- [ ] Verify `ctranslate2` imports and `_ext.*.so` is present in `site-packages`.
+
+---
+
+## 3. Fix Any Build/Packaging Issues
+- [ ] If build fails, capture error logs and diagnose.
+- [ ] If `.so` not installed, check `setup.py`/CMake install logic.
+- [ ] Update packaging or CMake files as needed.
+
+---
+
+## 4. Automate and Document
+- [ ] Update `README.md` in root or `python/` with install/build instructions.
+- [ ] (Optional) Add GitHub Actions workflow for install/import test.
+
+---
+
+## 5. (Optional) Build and Upload Wheels
+- [ ] Build a wheel for the fork.
+- [ ] (Optional) Upload to private index or GitHub Release.
+
+---
+
+## Progress
+- [x] Initial audit complete
+- [ ] Upstream comparison
+- [ ] Clean install tested
+- [ ] Issues fixed (if any)
+- [ ] Documentation/automation

Testing/Temporary/CTestCostData.txt

@@ -0,0 +1 @@
+---

Testing/Temporary/LastTest.log

@@ -0,0 +1,3 @@
+Start testing: Apr 26 21:01 CEST
+----------------------------------------------------------
+End testing: Apr 26 21:01 CEST

maybe.md

@@ -0,0 +1,22 @@
+| Enhancement Name                              | Probable Speed-up (×)         |
+|-----------------------------------------------|-------------------------------|
+| GPU Offload (Metal / MPS)                     | 10–100×                       |
+| FP16 (Half-Precision) Compute                 | 2×                            |
+| Hybrid CPU + GPU + ANE                        | 1.5–2×                        |
+| ANE-Only Offload                              | 3–5× (for supported ops)      |
+| Data-Transfer Minimization (shared MTLBuffer) | 1.1–2×                        |
+| Kernel Tile & Threadgroup Tuning              | 1.1–1.5×                      |
+| Batching & Operation Fusion                   | 1.1–2×                        |
+| Auto-Tune Backend Selection                   | 1.1–1.5×                      |
+| *Strassen / Coppersmith–Winograd Algorithm*   | *1.2–2×*                      |
+| *Block Floating-Point Quantization*           | *2–4×*                        |
+| *Spiking Neuromorphic Approximate GEMM*       | *5–10× (very high risk)*      |
+| *Optical Co-processor Offload*                | *100–1000× (theoretical)*     |
+| *Quantum Matrix Multiplication*               | *1 000–10 000× (theoretical)* |
+| *In-Memory Resistive Computing*               | *100–1000× (early research)*  |
+
+**Quantum Matrix Multiplication**
+This refers to using quantum computing algorithms (e.g., the Harrow-Hassidim-Lloyd algorithm) to perform matrix multiplication exponentially faster than classical methods. In theory, a large-scale, fault-tolerant quantum computer could multiply matrices in polylogarithmic time, yielding speed-ups on the order of 1 000× to 10 000×. However, current quantum hardware is noisy, limited in qubit count, and lacks error correction, making practical quantum GEMM for real-world sizes unfeasible today.
+
+**In-Memory Resistive Computing**  
+Also known as analog crossbar computing, this approach uses arrays of resistive memory (e.g., PCM, RRAM) to perform multiply–accumulate operations directly in memory cells. It can compute entire matrix-vector products in one analog pass, potentially offering 100×–1 000× speed-ups and energy savings. Yet, prototype devices suffer from low precision, device variability, and integration challenges, so widescale, reliable in-memory GEMM remains early-stage research.

plot_benchmarks.py

@@ -0,0 +1,55 @@
+import pandas as pd
+import matplotlib.pyplot as plt
+import os
+
+# Set paths to CSV files (update if needed)
+root = os.path.dirname(os.path.abspath(__file__))
+bench_ops_path = os.path.join(root, 'tests/metal/ops/build/benchmarks_ops.csv')
+gemm_cpu_path = os.path.join(root, 'tests/metal/ops/build/gemm_cpu_bench.csv')
+gemm_metal_path = os.path.join(root, 'tests/metal/ops/build/gemm_metal_bench.csv')
+
+def plot_ops_benchmarks():
+    df = pd.read_csv(bench_ops_path)
+    # Plot GEMM speedup
+    df_gemm = df[df['operator'] == 'GEMM']
+    plt.figure(figsize=(8, 5))
+    plt.title('GEMM: Metal vs CPU Speedup')
+    plt.bar(df_gemm['size'], df_gemm['speedup'], color='royalblue')
+    plt.xlabel('Matrix Size')
+    plt.ylabel('Speedup (CPU ms / Metal ms)')
+    plt.grid(True, axis='y')
+    plt.tight_layout()
+    plt.show()
+    # Plot ReLU speedup
+    df_relu = df[df['operator'] == 'ReLU']
+    plt.figure(figsize=(8, 5))
+    plt.title('ReLU: Metal vs CPU Speedup')
+    plt.bar(df_relu['size'], df_relu['speedup'], color='orange')
+    plt.xlabel('Input Size')
+    plt.ylabel('Speedup (CPU ms / Metal ms)')
+    plt.grid(True, axis='y')
+    plt.tight_layout()
+    plt.show()
+
+def plot_gemm_cpu():
+    df = pd.read_csv(gemm_cpu_path)
+    # Only plot a subset for clarity
+    sizes = df['size'].unique()
+    for size in sizes:
+        df_size = df[df['size'] == size]
+        plt.plot(df_size['batch'], df_size['avg_ms'], marker='o', label=f'Size {size}')
+    plt.title('CPU GEMM: Batch Size vs Time')
+    plt.xlabel('Batch Size')
+    plt.ylabel('Avg Time (ms)')
+    plt.legend()
+    plt.grid(True)
+    plt.tight_layout()
+    plt.show()
+
+def main():
+    plot_ops_benchmarks()
+    plot_gemm_cpu()
+    # You can add more plots for gemm_metal_bench.csv if data is available
+
+if __name__ == '__main__':
+    main()