odb: Add ZSTD compression to odb file format

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[oharboe]

Neat! Do you have any numbers on difference in speed for a large .odb file(gigabytes?) and some thoughts as to the heuristic as to when compression should be enabled? Always? For large/small?

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[QuantamHD]

@vvbandeira @maliberty it looks like all the install targets are passing. Can we update the docker images?

[oharboe]

@QuantamHD @maliberty Neat! Do you have any numbers on difference in speed for a large .odb file(gigabytes?) and some thoughts as to the heuristic as to when compression should be enabled? Always? For large/small?

I'm concerned that this is in fact reducing performance of local operation for large .odb files, in which case the policy of when to enable this is not as trivial as always on.

Especially considering that if one is using some sort of compression already, which is happening in Jenkins artifacts and if you use & enable it in Bazel.

An especially important use-case is how quickly e.g. make gui_route runs, because then a human is waiting. For the automated part of the flow where a user is, hopefully, not waiting where the build is taking minutes or hours, is less important.

[maliberty]

@QuantamHD do the images need to be updated in order for the other builds/tests to pass?

[QuantamHD]

@QuantamHD do the images need to be updated in order for the other builds/tests to pass?

Yes

[QuantamHD]

@QuantamHD @maliberty Neat! Do you have any numbers on difference in speed for a large .odb file(gigabytes?) and some thoughts as to the heuristic as to when compression should be enabled? Always? For large/small?

I'm concerned that this is in fact reducing performance of local operation for large .odb files, in which case the policy of when to enable this is not as trivial as always on.

Especially considering that if one is using some sort of compression already, which is happening in Jenkins artifacts and if you use & enable it in Bazel.

An especially important use-case is how quickly e.g. make gui_route runs, because then a human is waiting. For the automated part of the flow where a user is, hopefully, not waiting where the build is taking minutes or hours, is less important.

ZSTD is in the class of realtime compression algos. At 1700GB/s decompress speed it's not going to be a significant bottleneck in any read related workload (A 100GB ODB file will take a long time to import even uncompressed). If you were on a hard disk it's probably a net win. If you're on SSD probably net neutral.

This is likely to be beneficial to users who are on less powerful machines with smaller disks.

[oharboe]

@QuantamHD Makes sense. Can we verify that we are getting the performance that is being promised?

[QuantamHD]

@oharboe do you have any large odb files you could test with. The largest I have easily available to me are 500MB

It should be pretty easy to run time zstd file and time zstd -d file

[oharboe]

@oharboe do you have any large odb files you could test with. The largest I have easily available to me are 500MB

It should be pretty easy to run time zstd file and time zstd -d file

Not readily available. Though I would want to test w the openroad GUI. there is no reason to believe that it should pose an issue, but you know, ... trust, but verify....

[maliberty]

Take a reasonably large odb and do read_db/write_db/read_db on master and your branch and compare each step.

[QuantamHD]

@maliberty @oharboe on JPEG 130nm with the following script. 330MB of ODB. Tests were performed on SSD enabled machine

read_db "/usr/local/google/home/ethanmoon/OpenROAD/test/results/jpeg_sky130hd_route-tcl.db"
write_db "/usr/local/google/home/ethanmoon/OpenROAD/test/results/jpeg_sky130hd_route-tcl.db"

With ZSTD

ethanmoon@ethanmoon:~/OpenROAD/build$ time ./src/openroad -exit /usr/local/google/home/ethanmoon/OpenROAD/test/zstd_time.tcl
OpenROAD v2.0-11087-gc3f4e7813 
This program is licensed under the BSD-3 license. See the LICENSE file for details.
Components of this program may be licensed under more restrictive licenses which must be honored.

real    0m6.463s
user    0m5.293s
sys     0m1.098s

Without ZSTD

ethanmoon@ethanmoon:~/OpenROAD/build$ time ./src/openroad -exit /usr/local/google/home/ethanmoon/OpenROAD/test/zstd_time_standad.tcl 
OpenROAD v2.0-11119-g475910523 
This program is licensed under the BSD-3 license. See the LICENSE file for details.
Components of this program may be licensed under more restrictive licenses which must be honored.

real    0m5.354s
user    0m3.272s
sys     0m1.969s

SSD Benchmark Results

[oharboe]

@QuantamHD Thanks for the testing!

My conclusion: I think disabled by default would be a good policy.

I see no network transfer savings with this change as compression is already used in Jenkins and Bazel.

For interactive GUI performance, the disk savings are not worth the 20% increase in IO time.

As for saving disk space, I think that this mainly could come from skipping intermediate storage of all the stages. Each of floorplan, place, cts, route, final have multiple .odb files.

Something I have been considering to add to my wafer thin Bazel layer on ORFS is to collapse stages. Currently, the wafer thin Bazel layer on top of ORFS does create artifacts for all steps within a stage like floorplan, there us only one .odb artifact for floorplan. https://github.com/hdl/bazel_rules_hdl/pull/225

I would enable intermediate artifacts(.odb files) from floorplan through route during development and only keep final gds/abstracts once designs and macros mature. This would be set up in BUILD.bazel.

Unfortunately, symbolic links dont work with make.

[maliberty]

@QuantamHD how is the load time affected? This shows just the write performance.

[oharboe]

@maliberty @QuantamHD I think I'm underestimating the negative performance impact of zstd on reading.

Reading is important for OpenROAD GUI performance and there is room for optimization. Let's say we had a 30% improvement in load performance, zstd would then add 0.2/0.7=30% a increase in load times.

I believe that load times is going to be optimized more in the future as OpenROAD works on bigger designs in architectural exploration.

[oharboe]

Using an 11gbyte .odb file. If one projects a bit into the future where reading and writing is optimized a bit, then it's not a stretch to say that compression doubles loading/writing time based upon some quick measurements below.

I think that if this is merged, then by default, compression should be off for those files which are read by the OpenROAD GUI. Humans, not computers wait for the loading time...

To me the valuable size compressions come not from disk savings locally, but from transmission/artifact reduction, which requires reduction in compressed .odb files #4241

For transmission/artifact size for system like Bazel, compression is handled outside of OpenROAD already.

$ cat read.tcl
read_db bazel-bin/build/results/asap7/BoomTile/base/3_place.odb
$ cat write.tcl
read_db bazel-bin/build/results/asap7/BoomTile/base/3_place.odb
write_db foo.odb
$ cat readcompressed.tcl 
read_db foo.odb

$ time openroad -exit read.tcl
real    0m35,011s
user    0m29,187s
sys 0m5,635s
$ time openroad -exit write.tcl
real    1m34,847s
user    1m29,616s
sys 0m5,188s
$ time openroad -exit readcompressed.tcl
real    0m51,747s
user    0m48,201s
sys 0m3,540s

Uncompressed write.tcl:

$ time openroad -exit write.tcl
real    1m16,555s
user    1m3,675s
sys 0m11,938s

[maliberty]

Can we try with the equivalent of --fast=4 from the table?

[QuantamHD]

@oharboe @maliberty TBH I'm pretty meh about this change at this point.

@oharboe While I do agree with you about the loading times I'm guessing you're not factoring in the actual first frame time. The GUI usually takes longer to render than the db load proportionally. At least that's my experience.

[oharboe]

@oharboe @maliberty TBH I'm pretty meh about this change at this point.

@oharboe While I do agree with you about the loading times I'm guessing you're not factoring in the actual first frame time. The GUI usually takes longer to render than the db load proportionally. At least that's my experience.

Indeed. Good point.

Still, Jenkins will compress artifacts and so can Bazel.

Another way to save .odb file sizes on disk is to delete all the interim ORFS .odb files within the floorplan, place, cts and route stages, which is effectively what I do in my wafer thin Bazel layer on top of ORFS.

For Bazel, the biggest disk space concern in my limited experience, is that artifacts are not automatically dropped from the local cache in an LRU scheme... I googled a bit and ended up rm -rf ~/.cache/bazel... This is more of a usability concern though. Bazel wants me to do something, but I don't know what it expects of me as a user. Set an option? Manually manage the local Bazel cache? Docker has the same usability problem w.r.t. stale images. Bazel & Docker are the two major things apps that will fill up my disk without me intending to or being quite aware that I am :-)

[maliberty]

The GUI has to populate rtrees at startup and that takes a while.

Do you want to proceed as an option or just close this?

[maliberty]

reopen if still interested