On Jan 29, 2016 6:20 AM, "Øyvind Kolås" <pip...@gimp.org> wrote: > > GEGL is doing single precision 32bit floating point processing for all > operations, thus should not introduce the type of quantization > problems 8bpc/16bpc pipelines introduce for multiple filters - at the > expense of much higher memory bandwidth - the GEGL tile cache size > (and swap backend) should be tuned if doing benchmarks. If this > benchmark is similar to one done years ago, VIPS was being tested with > a hard-coded 8bpc 3x3 sharpening filter while GEGL was rigged up to > use a composite meta operation pipeline based unsharp mask using > gaussian blur and compositing filters in floating point. These factors > are probably more a cause of slow-down than the startup time loading > all the plug-in shared objects, which still takes more than a second > on my machine per started GEGL process.
Ah so this is interesting. So I feel like rather than removing gegl from that list of benchmarks, it would be better to build more benchmarks, especially ones that call out all the advantages of gegl. E.g. minimal updates, deep pipeline accuracy, etc. It is worth calling out gegls limitations and being honest with them for three reasons. First, they are not fundamental to the design of gegl. Just having a vips backend proves that. Second, a lot of the tricks vips does, gegl really can learn from, and having benchmarks that do not look so good is a great way to call out opportunities for improvement. And third, benchmarks help users make good decisions about whether gegl is a good fit for their needs. Transparency is one of the deeply valuable benefits of open source. In terms of technical projects I feel having this benchmark and the discussion about it inspires: - Gegl could load plugins in a more demand driven way, reducing startup costs. - Gegl could have multiple pipelines optimized for different use cases. - A fast 8 bit pipeline is great for previews or single operation stacks, or when accuracy is not as important for the user. - Better threading, including better I/O pipelining is a great idea to lift from vips. - Anyone can do dynamic compilation nowadays with llvm. Imagine taking the gegl dynamic tree, and compiling it into a single LLVM dynamically compiled function. So if any of the above actually appear in patch sets, then we, at least partially, have this benchmark to thank for motivating that. I can see ways in which any one of the above projects can benefit GIMP as well. And in terms of transparency and user benefit, , the vips developers' benchmark also makes me think that there really should be a set of benchmarks that call out the concrete user benefits for gegl. E.g. higher accuracy, especially for deep pipelines. If these benefits exist it must be possible to measure them, and show how gegl truly beats out everyone else it it's areas of focus. In a very reals sense, vips is doing exactly what they should be. They are saying "if speed for a single image one-and-done operation is what you need vips is your tool, and gegl really isn't." That sounds like an extremely fair statement to me right now, until some of gegls limitations in this area are addressed. And long term, why not? -- Daniel
_______________________________________________ gegl-developer-list mailing list List address: gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
