I’m aware of the dangers in general, but do you have any specific example for RawTherapee? I would especially be interested if the flag results in some sub-optimal output (e.g. causes some artifacts).
Also, I should clarify that I’m not recommending to build with -ffast-math by default, I’m only suggesting it as something worth trying to get some extra speed. Personally, I haven’t experienced any issues with RT since I moved to 64 bit, and I’m using -ffast-math on both my machines. But maybe I’m just lucky
I noticed that, and that’s why I set -ffast-math only in RTENGINE_CXX_FLAGS.
I did it out of curiosity at the beginning, but since I didn’t notice anything strange, I left it on…
noted, thanks for the pointer!
@agriggio If you want more speed for free, try building with LTO enabled. Last time I tried it (a year ago or so) it made a difference.
Thanks for the tip. I just tried, but I get a bunch of undefined references when linking (I simply set WITH_LTO=ON, is there anything else needed?)
Yes: In addition to
-DCMAKE_RANLIB=/usr/bin/gcc-ranlib to the cmake line.
Thanks, works now!
Don’t know about Ubuntu, but using Debian 8 or the Debian 9RC any version built on GTK3 is slow. The Gtk2 builds that allow using the system’s own theme in settings, work nice and snappy; no real speed difference between my 2GB RAM laptop and my 16GB RAM tower (obviously exports will be faster on the tower through).
I assume it must be because my debian hasn’t yet propperly adopted gtk3 yet?
I’d be interested in what goes faster, and how much faster it goes please.
goes about half a second faster (with your pp3). Nice considering that it is “for free”, but it won’t change your day…
thanks, & agreed!
Debian stable has a pretty dated version of GTK3, like 3.14 or something. But a new release is just around the corner!
That’s because Ingo has done such a tremendous job optimizing RT! There’s not much room left for LTO but to inline things a bit better.
Sure (and Stefan already mentioned Debian 9RC), but the core processing doesn’t depend on the GUI toolkit, so that’s indeed interesting.
There’s some potential to optimize
Only edges sharpening which currently is quite slow.
I already checked for the bottlenecks and found some.
@floessie Are you interested in another fun optimization session? I would open an Issue then and share my first results.
Can you post content of AboutThisBuild.txt please?
well, let me take this opportunity to thank all the RT developers for their amazing work!
I’ve removed 03 for the final release… I don’t know why - maybe because to keep recommendations from final readme file. My ‘unstable’ branch is compiled with 03. Well, I will add this again to stable branch - expect new compilation in few hours.