4.79X post-Loch Ness performance loss in histlp.sac
|Created on||May 13, 2010 20:20|
|Attachments||crud.sac, crud.b11, crud.prelochness, xcrud.prelochness|
Created an attachment (id=710) Dan's pre-Loch Ness -b13 output This is the most egregious of the remaining performance loss problems introduced at Loch Ness. apex/histlp/histlp.sac now executes about 5X slower than pre-Loch Ness. The Loop_0 functions before and after look nearly identical, except for these two lines: _pinl_3552__wlbsc_2356_sc_e = _idx_sel_( _ivesplit_5497, _isaa_4840_r_2); _pinl_3553__wlbsc_2357_sc_bound = [ _pinl_3552__wlbsc_2356_sc_e ]; ivesplit_5497 is 0, but the Loop_0 function header doesn't see that; it sees it as an AKS int. Similarly, _isaa_4840_r_2 is a parameter, but it is int, and _pinl_3553__wlbsc_2357_sc_bound becomes that parameter in the recursive call. So, the two lines are, effectively, a no-op. The picture is made a bit murkier by the fact that _pinl_3553__wlbsc_2357_sc_bound is also one of the results of Loop_0. I can see how LIR might have trouble pulling these lines out of the loop function. If we can't fancy up LIR enough to do the job, perhaps we can do an UNWLBSC traversal somewhere around the end of Phase 11. This, however, would not work in the current code, because _ivesplit_5497 is not AKV.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information