klayout xor runtimes on i5 3750 Win10, VirtualBox Centos7 vs M1 Mac x86 via Rosetta, M1 Mac native

edited January 21 in General

Hi Folks,

I used google/efabless mpw-one/slot-001/gds to compare xor runtimes between four different klayout executables.

https://foss-eda-tools.googlesource.com/third_party/shuttle/mpw-one/slot-001/+/refs/tags/mpw-one-final
Watch out, it's a ~3GB tar.xz file, but one can extract just the two gds to xor from it.

klayout caravel.gds.gz -s caravel.old.gds.gz

Since "old" is an empty shell, this is mostly an "or" of a routed std cell area, generating lot's of results.
More of a tiled xor stress test, not quite the "typical" ECO xor. Memories and IO are identical, no fill.

"Tools->XOR Tool" with 500um tile, using 4 CPU, "heal result shapes", "Send output to" "other layout".
klayout xor is using nearly 400% cpu in all configurations, uses ~10GB of memory.
Runtimes reported by "File->Log Viewer" set to "detailed", all times are wall times.

2012 i5 Win10: 457s
2012 i5 VirtualBox CentOS 7: 1350s

2021 M1 x86: 260s
2021 M1 native: 197s

Does anybody have an idea on why VirtualBox CentOS 7 is so much slower than Win10 on the same machine ?
I didn't expect virtualization to cause a 3x runtime hit for a cpu bound task.

I'm also interested in other datapoints, especially on native linux or more recent x86 machines.

Stefan

M1 native "strmxor -l -d=11 -n=4 -p=500 caravel.gds.gz caravel.old.gds.gz xor.oas" reports 330s for xor.
And that's despite the fact that it doesn't have the option to "heal result shapes".
M1 native klayout "without heal result shapes" reports 180s for xor.
I'm puzzled why strmxor is be slower than klayout for the same task.

Comments

  • Stefan, where did you get a Klayout build for M1 Mac?
    Or did you build it yourself?
    (I do not see M1 build on Klayout Download page).

  • edited February 1

    If you don't want to build it yourself, just use the x86 dmg files, they work just fine.

    On Mac, once you have Xcode command line tools and homebrew qt, ruby, python installed,
    thanks to Kazzz's macbuild scripts, building KLayout yourself is as easy as:

    build4mac.py -r HB27 -p HB38 -q Qt5Brew -m '--jobs=8'

    If you want to use Qt6Brew, as of now, you have to add the following line to klayout/src/klayout.pri
    QMAKE_RESOURCE_FLAGS += -threshold 1000000

    You can use makeDMG4mac.py to create an install dmg.
    I didn't use that, have a look at klayout/macbuild/ReadMe.md.

    There are some unit tests that coredump and very few fail due to result sorting issues.
    Matthias is aware of these, but too short on time and lacking hardware to have sorted these out yet.

    cd qt5Brew.build.macos-Monterey-release-Rhb27Phb38.macQAT
    ../macbuild/macQAT.py -r -x 'laySessionTests:1,laySessionTests:2,rbaTests:imgObject,tlXMLParserTests:1,tlXMLParserTests:5,tlXMLParserTests:6'

    Besides the failing unit tests, native M1 klayout works just fine for my use cases.

  • Thank you, Stefan!

Sign In or Register to comment.