Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi-threading #8

Open
heitzmann opened this issue Oct 14, 2020 · 3 comments
Open

Multi-threading #8

heitzmann opened this issue Oct 14, 2020 · 3 comments
Labels
enhancement New feature or request

Comments

@heitzmann
Copy link
Owner

It should be possible to increase the performance of Cell.to_gds using multi-threading. The generation of polygonal boundaries from FlexPath and RobustPath and fracturing all polygons (including the results from paths) could all be done in parallel. Furthermore, the left and right sides of the polygonal boundaries from paths are independent and could also be created in parallel.

There is a possible problem with increased memory use if multiple paths are created in parallel. In this case, we could give the user an option to run single-threaded or, even better, try to auto-detect the issue and limit the number of threads.

@heitzmann heitzmann added the enhancement New feature or request label Oct 14, 2020
@tvt173
Copy link

tvt173 commented Aug 4, 2021

curious what a typical breakdown is on the time for computational tasks at write time you list here like fracturing, etc. vs IO. do you know? if they are same order of magnitude, you may be able to get a good first cut at this by making just the IO part asynchronous. it will also tell you your potential gain if you multithread the computational part.

@heitzmann
Copy link
Owner Author

I believe writing to the disk is the slowest part by far, typically. Fracturing operations are not that expensive in general, and path conversions (when needed) can be slow for complex paths.

The tricky part is defining “typical”. Our research group works mostly on optical device design, so our layouts are usually very small, albeit with irregular shapes. My guess is a typical photonics layout would have lots of curved paths/shapes that should require fracturing, but a microelectronics might be mostly rectangles and simple paths. In those cases, IO is probably the bottleneck. But there are many exceptions, for example, a lage photonic crystal area or the inversion of a large layout would have incredibly large and complex polygons, in which fracturing would start showing up in a time breakdown.

The main problem is that if we're limited by the hardware write speed, issuing parallel writes to the same hardware will decrease performance, instead of increasing.

@rocallahan
Copy link

issuing parallel writes to the same hardware will decrease performance, instead of increasing.

With SSDs this is not necessarily true; it is possible to write in parallel very efficiently. However it's not trivial, e.g. you might have to use direct I/O and block-sized writes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants