Well, guess what, the difference is pretty tiny. I think what happened is this: once upon a time, when maketx was single-threaded, a 25% faster SHA-1 translated directly into an appreciable reduction in runtime. At some point, I switched to computing SHA's in strips (which could be done in parallel on a multi-core machine) and then combining those separate hashes into one. So on any modern machine with several cores, the SHA-1 time has plummeted, since it's so efficiently parallel. In contrast, the reading and writing of the images from disk is inherently serial, and dominates maketx time. I never went back to assess, after parallelizing, whether choice of SHA-1 makes a big difference. Apparently, it doesn't.
So, bottom line, we get essentially nothing out of using the OpenSSL SHA-1 implementation. I see no reason why we shouldn't switch the default to USE_OPENSSL=0 and eliminate it as a dependency. On Mar 5, 2015, at 11:52 PM, Larry Gritz <[email protected]> wrote: > Probably the most important place we use it is in maketx! The headers of > textures contain the SHA-1 of original pixels (and some salt thrown in for > certain options) so that the TextureSystem can recognize textures that are > exact duplicate of each other (this comes up surprisingly often in a > production environment). > > The use of SSL is for performance, aimed strictly at reducing the amount of > time it took to maketx large textures. In timings, it performed better than > our native one, and since OpenSSL was so widely available, I just used its > call rather than do the work to speed ours up. You can disable it with > USE_OPENSSL=0 at build time. There is no harm in doing so, other than > somewhat slower maketx speed. > > I'll redo some timings on large textures and see how much difference it > makes. > > > > On Mar 5, 2015, at 8:59 PM, Shane Ambler <[email protected]> wrote: > >> >> I really hadn't looked at oiio using openssl before, the sha1 from >> openssl being chosen for performance reasons. >> >> Also libOpenImageIO links against libssl and libcrypto which seems >> unnecessary. By comparison git uses sha1 and only links to libcrypto. >> >> As part of the ImageBufAlgo compare - is idiff the only place that the >> sha1 is used within the oiio package? >> >> While I know every machine has some variation of ssl installed, an >> image library isn't a likely candidate for needing ssl which can raise >> questions. Can the built-in sha1 be improved? Is it worth the effort? >> Is there other bsd friendly hashing source code available that could be >> included? >> >> I guess after all the openssl flack has settled down everything using >> ssl is getting a checkup. >> >> > > -- > Larry Gritz > [email protected] > > > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
