Efficient Geometry

A photonic chip easily holds tens of thousands of devices, each with curved geometry of hundreds of vertices, and test chips sweep device parameters so that hardly any two cells are the same. Laylight is built so that the time to compile a layout grows with its size and nothing else.

What makes it fast

A compiled evaluator. The compiler is written in Rust and evaluates cells directly, with no interpreter in the loop. Every distinct combination of cell parameters is evaluated once and becomes one cell; instances share it, and a regular grid of instances is written as a single array reference.

A geometry engine for layout data. Boolean operations, growing and shrinking run on the integer database grid. Edges are snap-rounded (Hobby's method), so results are exact to the grid and every predicate is computed in exact integer arithmetic: degenerate input such as touching, overlapping or collinear edges needs no tolerance and cannot break the result. Crossings and the grid pixels near each edge are found through a uniform grid of cells about as long as a typical edge; the pixels are then numbered, so that the rest of the work sorts and merges plain integers. The sweep that classifies the result keeps, with every edge it crosses, the winding number just above that edge, which stays valid as the sweep moves on, so each vertex costs a binary search and a local update. Polygons that rounding leaves as they are, such as keyholes, are not traced on their own, and the union of shapes that lie apart, the first step of growing or shrinking them, needs no tracing at all. Growing and shrinking trace the raw offset of the boundary, one ring per input ring, instead of a piece per edge.

All cores for large operations. The compiler and the language server run every stage of a large boolean operation in parallel, including the sweep, which is cut into slabs that each start from the edges crossing their left side, and get exactly the same result as on one thread.

A layout database that reads fast. The GDS reader and the hierarchical layout database behind Laylight, the same ones that power the Laylight viewer in the browser, are written for large files: they parse in a single pass over large reads, and flatten into exactly preallocated buffers with a branch-free inner loop that the compiler vectorizes.

Benchmarks

The benchmarks compare Laylight with gdsfactory, gdstk and KLayout's Python module on the same geometry, in four scenarios. The scripts are in bench/geometry in the repository.

Setup. Apple M3 Max with 128 GB of memory, macOS 26; Laylight built with Rust 1.90 in release mode; Python 3.12 with gdstk 1.0.1, KLayout 0.30.12 and gdsfactory 9.51.0. Every measurement runs in its own process; the median of three runs is reported (one run when it takes longer than 20 s). For Laylight, the time is the whole laylight build command: parsing, checking, evaluating and writing GDS. For the Python libraries it is building the layout and writing GDS, without interpreter start-up and imports. Rings use the same discretization everywhere (a chord error of at most 1 nm), and every output file is read back with KLayout to check that the tools wrote the same cells and comparable numbers of shapes and vertices. Runs are stopped after 10 minutes (shown as > 10 min). In the tables, the fastest time of a row is in bold and the others show how many times slower they are. Laylight runs its large boolean operations on all 16 cores, as it does by default; the Python libraries run on one thread, as they do by default.

Generating a parameter sweep

A test chip with an N × N array of all-pass ring resonators (a 500 nm bus waveguide and a ring), where every device has its own radius and gap, so that every device is a distinct cell. This is the typical workload of a layout generator: many small cells with curved geometry.

Laylight builds and writes the chip 3.5 to 5 times faster than gdstk and 10 to 15 times faster than KLayout's Python API. gdsfactory is slowest and its time grows faster than the number of devices: over two minutes for 40,000 devices, about 325 times longer than Laylight.

Generating a parameter sweep with cladding

The same chip, where every device also gets a cladding: the bus and ring grown by 2 µm with mitered corners. Every device now runs a boolean operation on curved geometry. Laylight writes it as shape [bus, resonator] + 2um as cladding; gdstk uses gdstk.offset, KLayout and gdsfactory Region.sized.

The boolean operation now dominates the work, and Laylight is still the fastest: 3.1 to 3.4 times faster than gdstk, whose offset runs on the Clipper library, and about 13 times faster than KLayout.

Boolean operations on large flat layouts

Two layers of shapes in memory, combined with AND and XOR, and the first layer grown by 100 nm (offset). The rectangles are 1 µm squares on a 1.5 µm pitch with the second layer shifted by half a square, the Manhattan case (up to 11.5 million vertices). The rings have a centerline radius of 5 µm, a width of 500 nm and 324 vertices each, on a 12 µm pitch with the second layer shifted by (3 µm, 2 µm), the curved case (up to 6.5 million vertices). gdsfactory runs its booleans on KLayout regions (through kfactory), which is why its times follow KLayout's.

Laylight is the fastest engine in every case. On Manhattan data it runs 6 to 14 times faster than KLayout's engine (which gdsfactory also uses), the reference for this kind of work, and 18 to 420 times faster than gdstk; gdstk's XOR did not finish within 10 minutes once the result merges into large polygons with many holes. On curved data it is 4.5 to 7.5 times faster than gdstk for AND, where gdstk's Clipper does best, and 8 to 20 times faster than the fastest of the others for XOR and offset. Results are exact on the integer grid in every case.

Reading and flattening a large GDS file

A synthetic 247 MB GDS file modeled on a real chip: 6,201 cells, 15 layers, many small rectangles fanned out through array references and large dense polygons; flattened, 2.36 million shapes with 101 million vertices. The file is read, timed from opening it, and its top cell flattened.

Laylight is the fastest at every step: it reads the file 1.7 times faster than gdstk and 3.3 times faster than KLayout, and flattens it 2.5 times faster than gdstk. Reading and flattening together take under a fifth of a second, less than half of gdstk's time and a seventh of KLayout's. gdsfactory reads through KLayout and then converts the cells, which takes 2 seconds on its own.

Reproducing the results

uv run --no-project --python 3.12 \
    --with gdstk==1.0.1 --with klayout==0.30.12 --with gdsfactory==9.51.0 \
    python bench/geometry/run.py
python bench/geometry/report.py   # the tables on this page