Good catch! Sent from my iPad
On Jan 10, 2013, at 9:17 AM, Jerry Huxtable <je...@thefoundry.co.uk> wrote: > Well, I hadn't bothered to read the rest of the discussion to see how it was > used :-) > > I'll have to take your float* and raise you an ampersand though: > > float* pixels = &frame[(y * width) + x]; > > > On 10 Jan 2013, at 17:13, "Steve Booth" <st...@boothsoft.com> wrote: > >> Jerry, >> >> Depends on how good your compiler optimization is, but an even faster way >> would be: >> >> float* pixels = frame[(y * width) + x]; >> >> float pixel = *pixels++; >> >> for the entire line – I.e. skip over the multiplication step. >> >> Steve >> >> >> From: nuke-dev-boun...@support.thefoundry.co.uk >> [mailto:nuke-dev-boun...@support.thefoundry.co.uk] On Behalf Of Jerry >> Huxtable >> Sent: Thursday, January 10, 2013 8:29 AM >> To: Nuke plug-in development discussion >> Subject: Re: [Nuke-dev] Dynamically creating a tile >> >> One thing is that if you're compiling for debugging, the compiler probably >> won't be inlining operator[] which makes it much slower than a raw array >> access, so instead of doing: >> >> float pixel = frame[(y * width) + x]; >> >> it might be better to do >> >> float* pixels = &frame[0]; >> ... >> float pixel = pixels(y * width) + x]; >> >> Jerry >> >> On 10 Jan 2013, at 16:13, Bruno Nicoletti <br...@thefoundry.co.uk> wrote: >> >> >> Some interesting discussion on this in topic in Stack Overflow. >> >> >> http://stackoverflow.com/questions/381621/using-arrays-or-stdvectors-in-c-whats-the-performance-gap >> >> >> http://stackoverflow.com/questions/3664272/stdvector-is-so-much-slower-than-plain-arrays >> >> depending on how you used them, they are just as fast as raw pointers. >> >> We try and to avoid exposing raw pointers to get around all the memory >> management issues that they bring up. If we do use them, we wrap them up >> nicely so that programmers don't do the raw allocations. >> >> I'd do your example as.... >> std::vector<float> frame(width * height); >> >> and index just the same with... >> float pixel = frame[(y * width) + x]; >> >> b >> >> >> On Thu, Jan 10, 2013 at 2:52 PM, Steve Booth <st...@boothsoft.com> wrote: >> The tradeoff is simple: convienance vs speed. There are lots of nice >> features in C++, like the std library, and using them can save us >> implementation time and insure reliability. Unfortunately, they are almost >> always less efficient than a more machine-centric approach. We teach them >> in College as the 'correct and approved' way to do things. >> >> Here, however, we live in the real world, where saving a few microseconds in >> an operation can literally determine if you meet your deadline, or look for >> a new gig. >> >> There is absolutely nothing wrong with malloc. You just need to understand >> the risks and how to use it properly. >> >> Steve >> >> >> Sent from my iPad >> >> On Jan 10, 2013, at 2:05 AM, Mike Vasiljevs <m...@emotion3d.tv> wrote: >> >> > >> > >> > Am 09/01/2013 21:19, schrieb Steve Booth: >> >> You are correct that a vector<vector<float>> is a pretty inefficient way >> >> to >> >> store an array of pixels -- a vector of pointers of to pointers to floats. >> >> By far, the fastest way to store an array is in contiguous memory >> >> locations. >> > You could still use vector to store continuous memory. Every time there is >> > see a normal pointer + malloc I raise the eyebrows :/ >> > >> > >> > >> > >> >> If, for example, your frame is 'width' by 'height' pixels, then all you >> >> need >> >> to do is malloc a float array, as in: >> >> >> >> float* frame = malloc(width * height * sizeof(float)); >> >> >> >> To access the x'th column of the y'th row, it's very simple: >> >> >> >> float pixel = frame[(y * width) + x]; >> >> >> >> That's the fastest way to access a frame. You can fill it in the first >> >> call >> >> to 'engine', and then pull lines out as needed in subsequent engine calls. >> >> >> >> Steve >> >> >> >> -----Original Message----- >> >> From: nuke-dev-boun...@support.thefoundry.co.uk >> >> [mailto:nuke-dev-boun...@support.thefoundry.co.uk] On Behalf Of Stephen >> >> Newbold >> >> Sent: Wednesday, January 09, 2013 12:03 PM >> >> To: Nuke plug-in development discussion >> >> Subject: Re: [Nuke-dev] Dynamically creating a tile >> >> >> >> I should probably mention that the Op is accessing this vector for every >> >> pixel, so and speed increase however little could add up. >> >> >> >> Stephen Newbold wrote: >> >>> Is there any way of creating a tile filled with data generated within >> >>> the plugin opposed to an input? And if so, is there any benefit to >> >>> doing this? At present my Op is randomly accessing a vector< >> >>> vector<float> > which I'm guessing isn't so fast! I was wondering >> >>> whether the same data in 'tile form' would be a lot more optimised. >> >>> >> >>> Cheers, >> >>> Steve >> >>> >> >> >> >> -- >> >> Stephen Newbold >> >> Compositing Lead - Film >> >> MPC >> >> 127 Wardour Street >> >> Soho, London, W1F 0NL >> >> Main - + 44 (0) 20 7434 3100 >> >> www.moving-picture.com >> >> >> >> _______________________________________________ >> >> Nuke-dev mailing list >> >> Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev >> >> >> >> _______________________________________________ >> >> Nuke-dev mailing list >> >> Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev >> >> >> > >> > _______________________________________________ >> > Nuke-dev mailing list >> > Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev >> _______________________________________________ >> Nuke-dev mailing list >> Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev >> >> >> >> -- >> Bruno Nicoletti, Founder and Head of Technology >> The Foundry >> Email: br...@thefoundry.co.uk >> Skype: brunonicoletti >> Tel: +44 (0)20 7968 6828 - Fax: +44 (0)20 7930 8906 >> Web: www.thefoundry.co.uk >> The Foundry Visionmongers Ltd. >> Registered in England and Wales No: 4642027 >> _______________________________________________ >> Nuke-dev mailing list >> Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev >> >> _______________________________________________ >> Nuke-dev mailing list >> Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev > > _______________________________________________ > Nuke-dev mailing list > Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
_______________________________________________ Nuke-dev mailing list Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
