The same semantic-search question-answering pipeline: embed a knowledge base, find the nearest match, and ask the LLM.

Dieselbe semantische Such-&-Frage-Pipeline: Wissensbasis embedden, nächsten Treffer finden und das LLM fragen.

1.9× less code — measured on the real files in benchmarks/python-vs-pipe. Same DeepSeek model on both sides; the Python side additionally needs an embedding provider (Ollama) because DeepSeek has no embeddings API, while Pipe embeds locally with zero setup.

1,9× weniger Code — gemessen an den realen Dateien in benchmarks/python-vs-pipe. Beide Seiten mit demselben DeepSeek-Modell; die Python-Seite braucht zusätzlich einen Embedding-Anbieter (Ollama), weil DeepSeek keine Embedding-API hat, während Pipe lokal ohne Einrichtung embeddet.

-- Pipe RAG (14 lines)
ai_provider "deepseek"

docs: [read_file "data/docs/database.txt"]
push docs (read_file "data/docs/caching.txt")
push docs (read_file "data/docs/api.txt")
push docs (read_file "data/docs/deployment.txt")

vectors: embed_batch docs
q_vec: embed "How do we rate-limit API requests?"
top: nearest q_vec vectors 3

context: ""
for idx in top
    context: context ++ (at docs idx) ++ "\n---\n"

answer: ask ("Context:\n" ++ context ++ "\nQuestion: " ++ "How do we rate-limit API requests?")
print answer

Three independent LLM calls (deepseek-v4-flash). Sequential Python takes ~3.3s. Python + asyncio.gather() runs them in ~1.3s. Pipe's >> operator: ~1.2s total — with no interpreter/import startup at all.

Drei unabhängige LLM-Calls (deepseek-v4-flash). Sequentielles Python braucht ~3,3s. Python + asyncio.gather() läuft in ~1,3s. Der >>-Operator von Pipe: ~1,2s gesamt — ohne Interpreter-/Import-Startup.

2.8× faster than sequential. Both parallel versions are LLM-latency-bound, but the Python process needs ~7s of interpreter + import startup (langchain, openai, ...) before the first call — Pipe starts in milliseconds. ai_batch scales the same idea to hundreds of texts with built-in rate limiting.

2,8× schneller als sequentiell. Beide Parallel-Varianten sind LLM-Latenz-gebunden, aber der Python-Prozess braucht ~7s Interpreter- + Import-Startup (langchain, openai, ...) vor dem ersten Call — Pipe startet in Millisekunden. ai_batch skaliert dieselbe Idee auf hunderte Texte mit eingebautem Rate-Limiting.

-- 3 calls in parallel — ~1.2s total
a: "Löse 7*8+4 und antworte nur mit der Zahl."  >> ask
b: "Löse 12*12 und antworte nur mit der Zahl."  >> ask
c: "Löse 100/4 und antworte nur mit der Zahl."  >> ask

print a ++ " | " ++ b ++ " | " ++ c

The real Python venv behind the examples above (langchain, langchain-deepseek, langchain-ollama, faiss-cpu, fastapi) measures 345 MB on disk — Pipe is one statically-linked 8.6 MB binary.

Das reale Python-venv hinter den obigen Beispielen (langchain, langchain-deepseek, langchain-ollama, faiss-cpu, fastapi) misst 345 MB auf der Platte — Pipe ist eine einzige statisch gelinkte 8,6-MB-Binary.

40× smaller. Deploy to a server or Raspberry Pi with scp pipe binary. No venv, no pip, no Docker, no runtime dependencies.

40× kleiner. Deploy auf Server oder Raspberry Pi per scp pipe binary. Kein venv, kein pip, kein Docker, keine Laufzeit-Abhängigkeiten.

Run with pipe -vm -q script.pipe to compile to bytecode and execute on a stack-based VM instead of the tree-walker. Speedup depends heavily on the workload — from 0.6× to 55×. Here are the measured medians (pipe -bench, pure execution time):

Ausführen mit pipe -vm -q script.pipe kompiliert zu Bytecode und führt auf einer Stack-basierten VM statt im Tree-Walker aus. Die Beschleunigung hängt stark vom Workload ab — von 0,6× bis 55×. Hier die gemessenen Mediane (pipe -bench, reine Ausführungszeit):

The VM wins big on function-call and recursion-heavy code (up to 55× on fib), but simple loops, list building and string concatenation are comparable or even slower — the tree-walker optimizes those well. Take a single "~7×" claim with a grain of salt: measure your own workload with pipe -bench.

Die VM gewinnt deutlich bei funktionsaufruf- und rekursionslastigem Code (bis 55× bei fib), aber einfache Schleifen, Listen-Aufbau und String-Concatenation sind vergleichbar oder sogar langsamer — der Tree-Walker optimiert diese gut. Ein pauschales „~7×" mit Vorsicht genießen: eigenen Workload messen mit pipe -bench.

Identical programs, no LLM calls, wall time including interpreter startup (median of 5 runs). CPython wins these — Pipe is not a JIT compiler and is not designed to outrun Python on raw CPU. Where Pipe actually wins is LLM workflows: no 7-second langchain import startup, built-in parallel >> and ai_batch.

Identische Programme, keine LLM-Calls, Wandzeit inkl. Interpreter-Startup (Median aus 5 Läufen). CPython gewinnt diese Benchmarks — Pipe ist kein JIT-Compiler und nicht dafür gebaut, Python bei roher CPU-Leistung zu schlagen. Wo Pipe wirklich gewinnt, sind LLM-Workflows: kein 7-Sekunden-langchain-Import-Startup, eingebautes Parallel->> und ai_batch.

Note the startup share: Pipe's ~100 ms here includes binary startup + bytecode compile, Python's ~15 ms is pure interpreter startup. Both are negligible next to the ~7s Python import startup for langchain in the real LLM benchmarks above. Rerun: python3 tools/measure_perf.py.

Startup-Anteil beachten: Pipe's ~100 ms hier beinhalten Binary-Start + Bytecode-Kompilierung, Python's ~15 ms sind reiner Interpreter-Start. Beides ist vernachlässigbar neben dem ~7s-Import-Startup von langchain bei den echten LLM-Benchmarks oben. Neu messen: python3 tools/measure_perf.py.