PSDP — Same-Language Parallelization

Measurements

Every figure is published together with its measurement conditions. We do not publish a speedup without them. Primary records are in the verification record.

Workload	Conditions	Speedup	Agreement
Nightly batch / aggregation	PostgreSQL 16.14 real server / fetch split by id range / 500k rows and above 8 connections at 4.73× is best; 20 connections degrades, so connection count is part of the judgment.	3.26 – 5.81×	bit-exact 20 / 20
Batch update of independent rows	Real PostgreSQL / 32-way (128 plateaus) / C# Npgsql	8.57×	bit-exact
E-commerce order batch (tax class / coupon / points / truncation)	5 DB engines (PostgreSQL / H2 / HSQLDB / SQLite / Derby)	2.98 – 4.54× (PostgreSQL 4.47×)	Identical bits on all 5 engines
Online response (pages with N+1)	Order history / localhost PostgreSQL = lower bound of the effect In production the DB is across a network, so the effect is larger.	5.95× / 5.29× 50 orders 11.8→2.0ms 200 orders 30.9→5.8ms	Evidence matches. CPU use drops to 0.63–0.71×
Compute-heavy work (matrix multiply / image convolution / spreadsheet / real TCP)	Rust (standard library only) / 1 to 20 threads	6.67× / 6.30× 5.35× / 16.88×	Digest dfcf3fee29d7d15c fixed at every thread count
Cross-language agreement (bundled sample)	Total work fixed at 200,000 tasks / 20 cores / matrix multiply N=16 / re-measured 2026-08-18	Go 4.05× C# 2.81×	Identical 0xe718490618e7f144 across all degrees of parallelism 1–20 and between Go and C#
Track A (mainline Java — determinism evidence)	Execution model is sequential (topological phase order)	—	bit-exact 378 / 378 Golden d2fc575a50086c6f reproduced. This is evidence of determinism, not of parallel performance.

★ The parallel execution paths above were implemented by us for measurement (they are not the output of an automatic converter). They represent the figures once application is complete. See § Preconditions and limits.

How it works — the machine decides first what is safe to speed up

Parallelizing is not the difficult part. Drawing the boundary where you get both the speed and an unchanged answer is. PSDP draws that boundary in four stages — and takes everything inside it.

The verdict is one of four values.

• AUTO_PARALLELIZEDProven that relaxing order does not change the result. Parallelize it.
• VERIFIED_SEQUENTIALProven that order carries meaning. Leave it sequential.
• NEEDS_CONTRACTA contract required for the decision (money scale, merge order, partition key) is not declared. Declare it and this becomes parallelizable.
• REJECTED_UNSAFEOrder dependence demonstrated. Do not parallelize.

The guarantee has two stages — front: bit-exact, rear: full agreement

PSDP's guarantee splits into within one language and across boundaries. The front stage belongs to the per-language options (the SlimeX2X family); the rear stage belongs to PSDP itself.

★ Why the rear stage is needed. The front stage alone only tells you "it agreed on that language, at that degree of parallelism, on that database". In our measurements the same SQL aggregation disagreed on 419 of 512 groups between PostgreSQL and H2, and an incorrectly partitioned parallel version returned a different value at every thread count. Only the rear stage can tell you that development and production will not disagree.

Where it applies

The effect is governed by what the work is bound on. We measured four kinds of bound. Which one applies is determined before rollout, so "we installed it and nothing got faster" does not happen.

Area	Bound by	Measured	Verdict
Batch update of independent rows	Round-trip latency	8.57×	Strongest effect.
Online response (pages with N+1)	Waiting	5.95×	Applies. CPU use actually drops. Under high concurrency the degree of parallelism is reduced automatically (measured: beyond 16 concurrent requests, sequential wins).
Nightly batch / aggregation (read-heavy)	Fetch	3.26 – 5.81×	Applies from roughly 500k rows upward.
Statements, line items, running balances	Prefix scan	Applies	Requires money held as integers (minor units) or BigDecimal / decimal. Java / C# e-commerce systems already satisfy this. Only double-denominated money is out of scope.
Compute-heavy work	CPU	5.35 – 16.88×	Applies. The correct split axis differs per domain (rows / phase / connection / id range), so axis selection is part of the judgment.
Orders, inventory, settlement (concentrated on one row)	Contention	1.00×	Does not apply. Still 560 ops/s no matter how much parallelism you add. We exclude it and change the lever instead — where optimistic locking is in use, switching to row locking / serialization alone is 9.9× faster and correct (measured 56.8 → 560 ops/s).
Ingestion-dominated work	Ingestion	1.06×	Parallelizing the aggregation does nothing (94.1% of the time is loading). We switch to parallelizing ingestion.

In 6 measured cases, the right answer was "do not parallelize" 4 times

These are the verdicts our judgment produced against real OSS and a real database. PSDP is not a tool that parallelizes everything — it is a tool that stops parallelization where it must not happen. That is what these six cases mean.

Subject	Right answer	Measured
Accounting-ledger ingestion (cl-ledger)	do not parallelize	Even on infinite cores the aggregation caps at 1.06× (94.1% is loading)
Updates to contended rows	do not parallelize	Row locking / serialization is 9.9× faster and also correct (optimistic locking is 10.2× slower than sequential)
Running balances	not until the type changes	f64 disagrees even with order preserved; integers / BigDecimal agree exactly
Already-parallel libraries (OpenBLAS)	do not parallelize the outer loop	★ Outer 8 × BLAS 20 is 2.7× slower than sequential. The fastest configuration is the one that leaves the outer loop alone
RAG retrieval	parallel scoring, sequential top-k	24 tied documents produced 100 distinct top-5s. A secondary sort on ID makes it deterministic at essentially zero cost
HNSW (approximate nearest neighbour) index build	parallelize the build, then freeze the artifact	Parallel build 5.96×. ★ Search is deterministic; the build is not, so fixing the index byte sequence restores reproducibility (reloading a saved index agreed 63/63)

Why bit-exactness is the deliverable evidence

Every lever that makes code faster changes money amounts when misapplied, and does not show up in tests. All of the following were observed on real systems. PSDP produces its speedups after passing all of them.

Failure observed	Measured	On the PSDP path
Pushing aggregation into SQL changes money per engine	419 / 512 groups disagree between PostgreSQL and H2 (490 / 512 vs HSQLDB, max |Δ| 1.6e-8)	Identical bits on all 5 engines. "The amounts do not move when the database is replaced" maps directly onto migration, audit and regulatory reporting.
ORDER BY is not a total order	Before the update, 4 of 5 engines are green. Running UPDATE … SET qty=qty over 1,893 rows breaks PostgreSQL and HSQLDB. The total, 3,238,609.2700000014, looks unchanged	Total-order-ness is part of the judgment. ★ Development on H2 with production on PostgreSQL is an ordinary Java configuration, and the fault cannot reproduce in development at all.
The money type decides eligibility	Even with order fully preserved, a prefix scan on f64 disagrees at every block width (9,742 / 10,000 at chunk 64). Integers and BigDecimal agree exactly	The money type is part of the judgment, so BigDecimal / decimal estates can be parallelized without hesitation.
The broken version is the faster one	E-commerce order batch: 4.47× correct vs 6.09× violating. Displayed amounts look identical while the low-order bits of the tax change (…767999999E8 → …768000002E8)	Optimizing on speed alone selects the wrong one. Hence the evidence.
The answer varies with thread count	The violating version returns a different value at every thread count — 8 cores in development, 16 in production	On a correct axis the digest is fixed across 1–20 threads (dfcf3fee29d7d15c).
Naive parallelization corrupts data structures	An unsynchronized shared HashMap threw and died; the merge(…, Double::sum) version disagreed 478 of 512 even between run 1 and run 2	That is per-customer revenue taking a different value every night. Rejected by the judgment.

Supported languages

24 converters across 16 languages. The effect differs by language, so we state it in tiers rather than claiming "16 languages, parallelized".

Speed measurable under fixed conditions (6 languages)	Implementations where thread count can be varied at fixed total work. C# / Go and others. Measured: Go 4.05× / C# 2.81×.
Executes in parallel	Java 17 / 8to17 / _prime create a new Thread( per task, so thread count cannot be varied at fixed total work (no comparative measurement is possible). Moving these to a thread pool is the next task.
No CPU parallelism exists	Node.js / PHP (the PHP converter itself states "PHP core lacks threads"). Python is 1.00× because of the GIL (bit-exactness still holds).
Sample	The sample bundled with the converters is one matrix multiply. The e-commerce and RDB measurements were written as separate PoCs, not run through the converters.

PSDP options — per-language parallel optimization (the SlimeX2X family) in development

PSDP itself holds the rear stage (full agreement across boundaries); the front stage (bit-exactness within one language) is held by per-language options. Every option is a same-language transformation — Java to parallel Java, Rust to parallel Rust.

Option	Transformation	Measurements backing the front stage	Status
SlimeJava2Java	Java → parallel Java	Speedup measurements for Java: none (mainline Track A runs sequentially). This is the gap in the volume segment, and the top priority.	In development
SlimeCSharp2CSharp	C# → parallel C#	C# 2.81× (fixed total work, 20 cores); batch update of independent rows 8.57× (real PostgreSQL / Npgsql). The measurement harness is in place.	Design
SlimeGo2Go	Go → parallel Go	Go 4.05×. Output hash matches C# at 0xe718490618e7f144 (the pair for which the rear stage is already demonstrated).	Design
SlimeRust2Rust	Rust → parallel Rust	Matrix multiply 6.67× / image convolution 6.30× / spreadsheet 5.35× / real TCP 16.88×, digest fixed across 1–20 threads. The four-domain measurements were taken in Rust.	Design
SlimeKotlin2Kotlin SlimeScala2Scala SlimeCpp2Cpp SlimeSwift2Swift, …	Same-language	Converters exist. Reworking them so thread count can be varied at fixed total work is a prerequisite.	Planned
Python / Node.js / PHP	—	Out of scope for parallel optimization, because CPU parallelism does not exist (Python 1.00× under the GIL; the PHP converter states "PHP core lacks threads"). Bit-exact transformation itself still holds.	Out of scope

★ Why stay within one language: the original code is retained as the execution oracle unchanged, there are no cross-language numeric API differences to reconcile, the customer can read the generated code, and only the parts that fail need to be reverted. Existing tests, builds and monitoring keep working.

Design of SlimeJava2Java (top priority)

The core is the separation of compute from commit. Existing code is not simply run on several threads.

// 1. Snapshot / Fetch      — pin the required input
// 2. Parallel Compute      — compute per account independently (no DB writes, no output)
// 3. Deterministic Commit  — write to the DB and emit output in the original order

List<IndexedStatement> prepared =
    parallelCompute(accounts, account -> calculateStatement(account));

prepared.sort(byOriginalIndex());

for (IndexedStatement result : prepared) {
    repository.save(result.statement());
    output.write(result.statement());
}

Only the computation is parallelized; side effects are committed in the original order. DB write order, output order, the observed order of exceptions, log order and statement line order are all preserved, while only the heavy computation runs in parallel.

Two kinds of certificate

• Execution
  Certificate For one specific input snapshot, the original sequential version and the optimized version (at parallelism 1 / 2 / 4 / 8) returned the same canonical bytes. A proof that this batch run is identical.
• Transformation
  Certificate For an accepted transformation pattern, static checks that there is no read/write conflict between partitions, that ordering within a partition is preserved, that merge order is fixed, that the numeric contract is fixed, that side effects are isolated into the commit stage and that the observed order of exceptions is preserved. The stronger claim: identical for all inputs satisfying this contract.

★ The claim is not "any Java code can be automatically proven". It is "we prove only the transformations accepted fail-closed".

v1 scope

In scope	Batches independent per customer / account / store / merchant; statement generation; billing and fee calculation; line-item generation; running balances (where money is integral or BigDecimal); daily and monthly aggregation; independent computation after a read-only fetch
Out of scope	Contended updates to the same row; transactions spanning partitions; global mutable state; implicit dependence on clock or randomness; native methods; reflection-dispatched calls; floating-point reductions with unfixed order; non-idempotent calls to external services; processing whose exception order cannot be preserved Out-of-scope code is left exactly as the original sequential code.
Implementation status	Not implemented. The next task is building the Go / No-Go samples (a BigDecimal running balance and one e-commerce batch).

Deliverables

Not just optimized source — the basis for both the speed and the safety.

• Parallelization
  planWhat was parallelized and what was left sequential; partition keys; the dependency graph; what was rejected and why.
• Equivalence
  evidenceOriginal source hash / optimized source hash / input snapshot hash / numeric contract / output hash per degree of parallelism.
• Performance
  reportFetch / compute / merge / commit / GC / parallel overhead measured separately, so the bound is on record.
• Sequential
  fallbackThe original code remains immediately restorable.

Preconditions and limits (as of 2026-08-19)

On 2026-08-17–18 we submitted this work to an independent audit by a separate engine and reproduced every finding ourselves. Claims that did not survive were withdrawn, and the corrections are published along with their history. The current preconditions:

Application work is required	The published figures are for a completed application of the parallel execution path. They are not obtained by recompiling alone. The scope of application is fixed in advance by the judgment report.
Standing of the judgment engine	The premises (total-order-ness of ORDER BY, the money type, resource rules) are backed by measurement, but the implementation has not yet caught up with them. Current operation assumes a human re-checks the judgment; it is not used for automatic remediation, safety certification, or success-fee determination.
Anomalies out of scope	The judgment covers order dependence within a single thread. Lost updates, deadlocks and isolation-level anomalies are out of scope.
Java speed measurements	Mainline Java (Track A) runs sequentially, and 3 of 6 converters cannot be measured structurally. There are zero speedup measurements for Java (C# has 2.81×). Obtaining Java 21 measurements is the highest-priority work.
★ "Zero false acceptances" is not safety for general code	The old entry point was effectively a dedicated signature: compute(seed) → a 2-D float array. Across 102,750 real Python functions, exactly 0 matched. In other words, everything was rejected on shape before semantic judgment was ever reached. That "only the official fixtures pass" is likewise a consequence of those fixtures being convention-conforming kernels — not evidence of safety on general code. What does hold is bit-exactness within convention-conforming kernels (0xe718490618e7f144 agreeing across 6 languages). A general semantic admission layer is the part still to be built. The "provable regions" named in the central contract above currently mean the inside of that convention.
Withdrawn claims	"Zero false-safe verdicts", "sealed records can serve as a billing basis", "f64 addition is associative if values are integral and the total is within 253" and others have been withdrawn. The complete ledger, with reasons, is in the verification record.

★ A product that sells "it does not break" cannot go quiet when its own claims break. Withdrawn claims, audit findings, and the record of defects we built into our own checker are all published in the development record and verification log.

Pricing & licensing (Provisional, 2026-05-18 — example at 10,000 LOC)

Path	LOC	Buy-in / LOC	Buy-in total	Runtime rate	Runtime / year	Support
SlimeNENC (converter)	10,000	US$ 9.95	US$ 99,500	—	—	Full
PSDP for SlimeNENC customer	10,000	US$ 0.00	US$ 0	2%/year	US$ 1,990	Full
PSDP direct (via SIer / partner)	10,000	US$ 1.00	US$ 10,000	20%/year	US$ 2,000	Full (via partner)
PSDP end-user direct (30% OFF)	10,000	US$ 0.70	US$ 7,000	20%/year	US$ 1,400	FAQ only

Across the first three paths, the per-LOC annual runtime cost is designed to converge to the same band; only the one-time buy-in differs, reflecting the value of the SlimeNENC converter tool when bundled. The end-user-direct path is for self-deploying customers (FAQ-only support, no SI engagement — for hands-on help please go through a partner).

Activation method	Ed25519-signed license + 3-hop air-gap activation (for financial institutions).
License server	license.javatel.jp (AWS Lightsail, HSTS / OCSP stapling)
Patent	JP App. 2026-046620 (no contractual renegotiation between paths)

For SIer / partners: partners selling at the direct list price earn a substantial margin on the one-time buy-in, and the same margin applies recurringly to the annual runtime subscription — year after year, for as long as the customer keeps PSDP in production. Concrete tier numbers are part of the partner agreement and shared after registration. See /partners/ for partner enrolment.

Direct-customer Editions (Provisional, 2026-05-18 — subject to change)

Edition	PSDP-managed LOC cap	One-time buy-in	Annual runtime	Notes
Trial	10,000	US$ 0	US$ 0 (14 days)	Full features, non-commercial
Individual	50,000	LOC × $1.00 (cap $50)	LOC × $0.20	Community support, commercial use OK
Corporate	1,000,000	LOC × $1.00	LOC × $0.20	Email support, SLA 99%, audit-chain export
Enterprise	unlimited	LOC × $1.00	LOC × $0.20 (cap $1,000,000/year)	24h SLA 99.9%, 3-hop air-gap activation, finance/medical
OEM	unlimited + relicense	negotiated	negotiated	Source-escrow option, embeddable runtime

“PSDP-managed LOC” = the line count of source files inside the namespaces / packages declared as PSDP-managed in psdp.toml, measured by cloc/tokei against the year-initial git revision. Runtime self-reports the same figure for cross-verification. The above schedule is provisional: caps, minimums, and SLA tiers may be revised before the GA pricing announcement.

Patents

• JP Patent App. 2026-046620 (PSDP core / Phase-Synchronous Deterministic Parallelism)
• JP Patent App. 2026-046625 (phase-sync implementation, safety mechanisms, claims 29-32)
• Additional applications in preparation (SIMD / GPU extensions)

Related products

Try the service (PSDP) → Contact us SlimeNENC family All products