Global placement taking hours

[oharboe]

I'm building MegaBoom and global placement takes hours. Is this a known issue where it is known what is needed to mitigate the slowdown?

[NesterovSolve] Iter: 460 overflow: 0.205059 HPWL: 19290468260
[INFO GPL-0100] worst slack -3.76e-07
[INFO GPL-0103] Weighted 176557 nets.
[INFO GPL-0075] Routability numCall: 1 inflationIterCnt: 1 bloatIterCnt: 0
[long pause]

Suspend and resume a few times shows this stack-trace:

grt::GlobalRouter::mergeSegments(std::vector<grt::Pin, std::allocator<grt::Pin>> const&, std::vector<grt::GSegment, std::allocator<grt::GSegment>>&) (@grt::GlobalRouter::mergeSegments(std::vector<grt::Pin, std::allocator<grt::Pin>> const&, std::vector<grt::GSegment, std::allocator<grt::GSegment>>&):296)
grt::GlobalRouter::findRouting(std::vector<grt::Net*, std::allocator<grt::Net*>>&, int, int) (@grt::GlobalRouter::findRouting(std::vector<grt::Net*, std::allocator<grt::Net*>>&, int, int):140)
grt::GlobalRouter::globalRoute(bool, bool, bool) (@grt::GlobalRouter::globalRoute(bool, bool, bool):121)
gpl::RouteBase::getGlobalRouterResult() (@gpl::RouteBase::getGlobalRouterResult():22)
gpl::RouteBase::routability() (@gpl::RouteBase::routability():54)
gpl::NesterovPlace::doNesterovPlace(int) (@gpl::NesterovPlace::doNesterovPlace(int):924)
_wrap_replace_nesterov_place_cmd (@_wrap_replace_nesterov_place_cmd:17)
TclNRRunCallbacks (@TclNRRunCallbacks:37)
___lldb_unnamed_symbol1497 (@___lldb_unnamed_symbol1497:339)
Tcl_EvalEx (@Tcl_EvalEx:9)
Tcl_Eval (@Tcl_Eval:11)
sta::sourceTclFile(char const*, bool, bool, Tcl_Interp*) (@sta::sourceTclFile(char const*, bool, bool, Tcl_Interp*):32)
ord::tclAppInit(Tcl_Interp*) (@ord::tclAppInit(Tcl_Interp*):131)
Tcl_MainEx (@Tcl_MainEx:111)
main (@main:727)
__libc_start_call_main (@__libc_start_call_main:29)
__libc_start_main_impl (@__libc_start_main@@GLIBC_2.34:44)
_start (@_start:15)

A tiny method...

OpenROAD/src/grt/src/GlobalRouter.cpp

Line 2126 in 8840467

void GlobalRouter::mergeSegments(const std::vector<Pin>& pins, GRoute& route)

Naiively rewriting to avoid O(n^2) #4627

[maliberty]

Is this a known issue where it is known what is needed to mitigate the slowdown?

Routability, which calls grt, can take a while but I don't know of a specific mitigation. You might try vtune for performance profiling.

[oharboe]

Stab in the dark #4627. Based on single suspend in debugger....

[oharboe]

#4627 is possibly a bit faster, 2.5%... I would have to run several tests to get some robust data, but the improvement is so small it's not worth it.

Before:

3_3_place_gp 7576

After:

3_3_place_gp 7318