Sure, I understand what you're saying. The example is only bundled that way because I didn't want to send a huge multi-channel exr file. But if you were to write out each generator to a file, plus a multi-channel exr at the end of all the Copy nodes, and then redo those trees with actual inputs, the results are pretty much the same.
At least, that's what I used in my original test. Sorry the example was half baked. Does that make sense? On Tue, Sep 6, 2011 at 6:32 PM, Deke Kincaid <[email protected]> wrote: > Hi Ivan > > The thing is in your slower one in red of your example your first > copying/shuffling everything to another channel before merging them from > their respective channels. The fast one there isn't any shuffling around of > channels first. Your going in the opposite direction(shuffling to other > channels instead of to rgba). The act of actually moving channels around is > what causes the hit no matter which direction your going. > > To make the test equal you would need to use generators that allow you to > create in a specific channel. The Checkerboard and Colorbars in your > example doesn't have this ability. > > -deke > > On Mon, Sep 5, 2011 at 23:06, Ivan Busquets <[email protected]>wrote: > >> Hi, >> >> Found the script I sent a while back as an example of picking layers in >> merges using up more resources. >> Just tried it in 6.3, and I still get similar results. >> >> Script attached for reference. Try viewing/rendering each of the two >> groups while keeping an eye on memory usage of your Nuke process. >> >> Cheers, >> Ivan >> >> >> >> On Mon, Sep 5, 2011 at 11:42 AM, Ivan Busquets <[email protected]>wrote: >> >>> Another thing is it sounds like you are shuffling out the channels to the >>>> rgb before you merge them. This also does quite a hit in speed. It is far >>>> faster to merge and pick the channels you need rather then shuffling them >>>> out first. >>>> >>> >>> That's interesting. My experience has usually been quite the opposite. I >>> find the same operations done in Merges after shuffling to rgb are faster, >>> and definitely use less resources, than picking the relevant layers inside >>> the Merge nodes. >>> >>> Back in v5, I sent a script to support as an example of this behavior, >>> more specifically how using layers within the Merge nodes caused memory >>> usage to go through the roof (and not respect the memory limit in the >>> preferences). At the time, this was logged as a memory leak bug. I don't >>> think this was ever resolved, but to be fair this is probably less of an >>> issue nowadays with higher-specced workstations. >>> >>> Hearing that you find it faster to pick layers in a merge node than >>> shuffling & merging makes me very curious, though. I wonder if, given enough >>> memory (so it's not depleted by the mentioned leak/overhead), some scripts >>> may indeed run faster that way. Do you have any examples? >>> >>> And going back to the original topic, my experience with multi-channel >>> exr files is: >>> >>> - Separate exr sequences for each aov/layer is faster than a single >>> multi-channel exr, yes. As you mentioned, exr stores additional >>> channels/layers in an interleaved fashion, so the reader has to step through >>> all of them before going to the next scanline, even if you're not using them >>> all. Even if you read each layer separately and copy them all into layers in >>> your script (so you get the equivalent of a multi-channel exr), this is >>> still faster than using a multi-channel exr file. >>> >>> - When merging different layers coming from the same stream, I find >>> performance to be better when shuffling layers to rgba and keeping merges to >>> operate on rgba. (although this is the opposite of what Deke said, so your >>> mileage may vary) >>> >>> Cheers, >>> Ivan >>> >>> On Thu, Sep 1, 2011 at 1:55 PM, Deke Kincaid <[email protected]>wrote: >>> >>>> Exr files are interleaved. So when you look at some scanlines, you need >>>> to read in every single channel in the EXR from those scanlines even if you >>>> only need one of them. So if you have a multichannel file with 40 channels >>>> but you only use rgba and one or two matte channels, then your going to >>>> incur a large hit. >>>> >>>> Another thing is it sounds like you are shuffling out the channels to >>>> the rgb before you merge them. This also does quite a hit in speed. It is >>>> far faster to merge and pick the channels you need rather then shuffling >>>> them out first. >>>> >>>> -deke >>>> >>>> On Thu, Sep 1, 2011 at 12:37, Ryan O'Phelan <[email protected]>wrote: >>>> >>>>> Recently I've been trying to evaluate the load of nuke renders on our >>>>> file server, and ran a few tests comparing multichannel vs. >>>>> non-multichannel >>>>> reads, and my initial test results were opposite of what I was expecting. >>>>> My tests showed that multichannel comps rendered about 20-25% slower, >>>>> and made about 25% more load on the server in terms of disk reads. I was >>>>> expecting the opposite, since there are fewer files being called with >>>>> multichannel reads. >>>>> >>>>> For what it's worth, all reads were zip1 compressed EXRs and I tested >>>>> real comps, as well as extremely simplified comps where the multichannel >>>>> files were branched and then fed into a contact sheet. I was monitoring >>>>> performance using the performance monitor on the file server using only 20 >>>>> nodes and with almost nobody using the server. >>>>> >>>>> Can anyone explain this? Or am I wrong and need to redo these tests? >>>>> >>>>> Thanks, >>>>> Ryan >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Nuke-users mailing list >>>>> [email protected], http://forums.thefoundry.co.uk/ >>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Nuke-users mailing list >>>> [email protected], http://forums.thefoundry.co.uk/ >>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>>> >>> >>> >> >> _______________________________________________ >> Nuke-users mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> > > > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
