Proposal to change the default to not use OpenSSL: https://github.com/OpenImageIO/oiio/pull/1086
On Mar 6, 2015, at 10:32 AM, Larry Gritz <[email protected]> wrote: > 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 -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
