Benchmark with Logical Layer OperationsMarch 28, 2017 For this benchmark we attempted to provide some timing data for a client who wishes to merge multiple single layer GDSII files into a single file, then perform some logical layer operations and then clip out windows from the "derived" layer. Creating the Single Layer GDSII Files We start with a multi-layer 1.4 GByte GDSII file, caw_test1.gds, and extract 3 single layer files (using GDSFILT):
We then merge 6.GDS, 17.GDS and 30.GDS into a single file called cawtest1_mod.gds using the Overlay program. This file will have data on 3 layers. Layer Logical Operations For this benchmark we are supposing that our client has asked us to perform the following layer operations prior to extracting a large number of clips: 6 [OR] 17 = TEMP TEMP [MINUS] 30 = 100 The [OR] operation can be done in two ways. The fastest with no computation is to simply change all of the layer attributes in both input layers to a single layer attribute. No unionization between overlapping polygons is performed. Why? Because the next operation, [MINUS], requires a UNION operation so doing one now would be redundant .The Hardware The machine used to run this benchmark:
CPU Intel Core i7-3930K @3.2GHz The ClipExtract Command Line
Timing We ran the benchmark over and over with different thread allocations. The two main computational operations are Explosion (Extract) and Boolean. The Explosion involves identifying and extracting all the polygons that cross a given clipping window. The Boolean performs the layer logical operations and clipping. By changing the allocation between exploder threads and Boolean threads we can find the optimal distribution.
It is clear that for this particular GDSII file (and window size) we are best off allocating as many threads to the Exploder as possible. That is likely because the number of polygons extracted in each window is small enough that a single Boolean thread handles it quite quickly. We are "extraction" limited in this example. Polygon Window Counts The balance between exploder threads and Boolean threads depends, to some extent, on how many polygons/vertices are present in the extracted window. The table below summarizes the counts.
The ratio of polygons to vertices is much higher for the output because the MINUS operation results in many small holes in the output polygons which produces higher vertex counts per polygon. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Benchmark 2In order to measure the effect of file size and to test on a different computer we ran the following benchmark on 3 files:
The Hardware The machine used to run this benchmark:
CPU Intel Core i7-4770K @3.5GHz Timing
Flat vs. Hierarchical Input DataDepending on the data source, the input to ClipExtract may be essentially flat. This might result from data in a given layer processed through some sort of OPC (Optical Proximity Corrrection) routine. In order to determine whether large flat files are problematic, we took the hierarchical data we used in the first Benchmark and exploded it so that data in each layer is flat. caw_test1_mod.gds Hierarchical Layers 6,17,30 144 MB
caw_test1_mod.gds Flat Layers 6,17,30 6040 MB
Observations The time needed to extract and Booleanize the 1000 windows is unchanged no matter whether the input data is hierarchical or flat. However the loading time ( a one time occurence) is greatly increased as is the memory footprint. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||