{"push_id":668981654,"size":4,"distinct_size":0,"ref":"refs/heads/RB-1.6","head":"d2d647cfb1ed54fa721ee48866faa0f60005d9d9","before":"f3f5197a82e8017b66d1261887e46b2608e031eb","commits":[{"sha":"0365a1cbeec6be35bf47a355b65d88a88b56c159","author":{"email":"f0a1ce6f80112d72f7276457fd261d671b827567@larrygritz.com","name":"Larry Gritz"},"message":"Dramatically speed up runtime optimization with flat_map\n\nA big part of the runtime optimizer's housekeeping is keeping track of\nwhich symbols alias to which other symbols. For example if you have\n'a=b' it will actually remember that they are the same, so then if you\nhave c=a-b, it will understand this means c==0. Of course, it also\nclears it if you reassign something else to a. And if you get to the end\nof a basic block, it clears them all, since control could flow in from\nsomewhere else with different assignments.  The basics of this was\ntracked by an alias array, length was the number of symbols, each\nelement says which symbol this symbol is aliased to, if any, or -1 if it\ndoesn't alias anything else.  And a common operation is to say \"forget\nall the aliases\", which is really filling the whole array with -1's.\n\nProfiling on some enormous shaders showed that this was (after the\nlatest fix to track_variable_lifetimes) the biggest hotspot in our\nruntime specialization. Especially the clearing operation. But we\nobserve that within any particular basic block, most of the symbols\nwon't be assigned at all.\n\nSo instead of having an array holding indices for all symbols, we just\nmake it a map -- only have an entry if the symbol was aliased to\nsomething. This makes lookup and assignment/reassignment of an alias\nO(log n) instead of O(1), because it's a map search or insertion rather\nthan a simple array lookup. But most of the time, the map only has a few\nentries. This speeds up runtime specialization by 4x.\n\nFurthermore, if a sufficiently new version of Boost is available, we use\nboost::container::flat_map, which is a drop-in replacement for std::map\nthat uses a sorted vector underneath. Lookup with binary search is still\nO(log n), but insertion and deletion becomes O(n), ick in theory, but in\npractice the enhanced memory locality tends to make it a net win for\nmost usage patterns. This reduces another 30%, bring us to a net speed\nincrease of 5x or better overall.","distinct":false,"url":"https://api.github.com/repos/imageworks/OpenShadingLanguage/commits/0365a1cbeec6be35bf47a355b65d88a88b56c159"},{"sha":"197752d472ece2e585945c1ecf0faa5e1284ba2f","author":{"email":"f0a1ce6f80112d72f7276457fd261d671b827567@larrygritz.com","name":"Larry Gritz"},"message":"Track time spent loading shader masters","distinct":false,"url":"https://api.github.com/repos/imageworks/OpenShadingLanguage/commits/197752d472ece2e585945c1ecf0faa5e1284ba2f"},{"sha":"5e4f0f32ae343a6cfa26f747d3fc62b40ac40877","author":{"email":"f0a1ce6f80112d72f7276457fd261d671b827567@larrygritz.com","name":"Larry Gritz"},"message":"Big speedup loading large shaders -- look up symbols with hashmap, not linear search","distinct":false,"url":"https://api.github.com/repos/imageworks/OpenShadingLanguage/commits/5e4f0f32ae343a6cfa26f747d3fc62b40ac40877"},{"sha":"d2d647cfb1ed54fa721ee48866faa0f60005d9d9","author":{"email":"f0a1ce6f80112d72f7276457fd261d671b827567@larrygritz.com","name":"Larry Gritz"},"message":"Critical bug fix -- error in keeping track of which layers have been run.\n\nWhen a shader needs the value of a connected parameter, it runs the\nupstream layer it's connected to, if it hasn't been run already.  But,\nto keep a bzillion of these checks from occurring needlessly, it also\ntries to keep track (when building the LLVM ops) of which ones certainly\nhave already been called, so that it isn't generating code to constantly\ncheck it at runtime. We were very subtly getting this wrong.  It's\ncrucial not to do this for things pulled by init ops. They are\ninherently conditional, and also the m_layers_already_run set hadn't\nbeen cleared yet when they were run! So certain particular constructs of\nlayer connections and init ops could result in it incorrectly skipping\nthe execution of a layer by thinking it had already been run, even\nthough it hadn't.","distinct":false,"url":"https://api.github.com/repos/imageworks/OpenShadingLanguage/commits/d2d647cfb1ed54fa721ee48866faa0f60005d9d9"}]}