On Sunday May 24 2015 20:00:46 Ryan Schmidt wrote: >No, sorry, I missed that you have this requirement. Why do you need libjpeg >instead of libjpeg-turbo?
I do not necessarily require to keep libjpeg instead of an alternative; more exactly, I want to keep it around in addition to whatever it's replaced with. >If we do keep a port for libjpeg after replacing jpeg with libjpeg-turbo, I >would probably make it for version 8 instead of 9. If we need it, I imagine >I'll create a new port libjpeg (as opposed to the existing jpeg port which >will be marked replaced_by libjpeg-turbo) and make it install into a >nonstandard prefix so that any who need it can get to it but so that it won't >be used automatically. Which is almost exactly what the port:jpeg version I uploaded does, and what I consider doing with it if I'm going to have to roll my own at some point in the future. >> but I think I won't. I'm just not convinced that recent/fast machines will >> see any measurable gain from the whole exercise. > >...which exercise? Of replacing port:jpeg with an alternative, which is going to represent a significant amount of work (however you measure it). I think you should do a couple of good, representative real-world benchmarks and see what remains of the 2-4x performance gain that results from synthetic benchmarks. Or maybe I should say resulted: I have no idea how fresh those results are, and how baseline libjpeg performance evolved with the advances compiler optimisation has made since. There was a rather explicit advice on the Qt interest ML recently to let auto-vectorisation handle optimisation in a related (can't remember the exact) domain of application. With modern CPUs, the performance bottleneck might simply be elsewhere than and/or not only in the steps that libjpeg-turbo can accelerate. I have learnt the hard way that except in very specific cases it usually doesn't pay to invest a lot of effort to speed up a single step in a chained computing process, unless you can show that the process is constrained by that particular step (and that there are no comparable constraints elsewhere). And as I said, my first impression is that we are not in that situation - just as with video it almost always pays *much* more to reduce the video dimensions rather than use a fancy or hand-optimised version of a codec. Thinking about it seems to confirm that impression. Supposing that libjpeg-turbo also provides faster encoding, one could expect a real-world gain in compressing large images with a very high loss-factor : in that case you'd reduce the time spent purely on compressing, and the result would be so small that its size was never an obstacle in the first place. >Yeah, I just read that yesterday... There was also some concern that software >compiled with mozjpeg would not be compatible with libjpeg-turbo, but I think >that's outdated information and that it's not a problem anymore since mozjpeg >3, though I'll try to confirm that. That would not make it possible to alternate between the 2 alternatives, but not otherwise be an issue. >But if we don't let the user choose between libjpeg-turbo and mozjpeg, how >then is a user who wants to use mozjpeg going to do that? Imagine I want to >compress a bunch of images using ImageMagick, and I want them to be as small >as possible, and I don't care if it takes longer to encode them. That's what >mozjpeg is for. I had envisioned that in this situation, I would >force-deactivate libjpeg-turbo, activate mozjpeg, and then use ImageMagick as >planned. Then when I was done I would deactivate mozjpeg and re-activate >libjpeg-turbo. Though thinking about it now, I guess for that use case it >wouldn't really matter if ImageMagick declared its dependency on >path:lib/libjpeg.dylib:libjpeg-turbo or just port:libjpeg-turbo; either way, >libjpeg-turbo will have to be forcibly deactivated. Yes, because MacPorts doesn't include a mechanism in which a port can declare that it provides an alternative to another port, which could then be used to allow the user to activate the one instead of the other (which would probably mean that the `port activate` syntax accept an optional "instead of <port>" argument). If there are no incompatibilities, you may be able to use port_select too. Wouldn't that'd be a bit like installing both libjpeg-turbo and mozjpeg through a single port, with a mechanism (script) to switch the library used? And even if (some) software would no longer work, you'd still get the commandline mozjpeg utilities that can be used (via an additional step) to get that extra compression. R. _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
