It looks like you're new here. If you want to get involved, click one of these buttons!
I used google/efabless mpw-one/slot-001/gds to compare xor runtimes between four different klayout executables.
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.
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.