gdstile_web_logo.gif

BENCHMARK

Users of GDSTILE will perform some kind of processing on each tile and eventually re-assemble the tiles into a "new" GDSII file. This is generally done on a layer-by-layer basis. The overall throughput of our users program is limited by how fast GDSTILE can deliver tiled data to the next operation.

throughput.gif

One measure of GDSTILE's performance would be the number of tiles "delivered" per second to subsequent processes. To get a feel for the performance of GDSTILE we assembled some GDSII data from various projects and used GDSTILE to cut each file into 256 x 256 um tiles.


The Benchmark Files

Files Size
(MB)		 Num
Cells		 Num
SREFs		 Num
AREFs		 Num
Polys		 Num
Paths		 Num
Vertices		 Num
Tiles		 Chip
Extents

B006

 804 23.4K 9.2M 75K 1.2M 291K 7.6M 2990 14000 x 14000

B008

 1710 2.8K 11.1M 22K 9.9M 8.9 68M 5508 19000 x 19000

B017

 2175 1.1K 5.6M 1K 2.4M 5M 133M 1406 9600 x 9600

B012

 3981 1700 566K 0 56M 0 280M 2990 14000 x 14000

B013

 4939 1 0 0 55M 9.7M 407M 1068 7000 x 10000

Note: The number of polygons, paths and vertices are the actual count inside of the GDSII file and are not the number you would count after the file was exploded.



The Machines

Role Name CPUs CPU Speed RAM OS 32/64 Priority Threads

Master

 blade750 2 750 MHz 8 GB Solaris 8 64 4 2

Slave

 ultra441 1 400 MHz 512 MB Solaris 8 64 3 1

Slave

 xeon2x 2 2.6 GHz 2 GB Linux (RH9) 32 1 2

Slave

 lev 1 800 MHz 512 MB Linux (RH9) 32 2 1


Page:     1   |   2   |   3   |   [4]   |   5