Cool VL Viewer forum

I often compile my own version of the viewer from source, when it is released. Lately I have been experimenting with the --lto flag, such as: ./buildlinux.sh --tune --usesystemlibs --lto. With today's release of 1.28.0.2 the build fails with:Upon inspecting ../llcommon/lldictionary.h it seems that it might be missing an LL_INLINE on line 77?
I added the macro to that line and rebuilt with success, but I admit I do not know exactly what that macro does or if it is appropriate on that method. The viewer seems to operate normally, though I haven't exhaustively tested.

I do not recommend using link time optimizations for the viewer, because they will cause de-inlining of important (read: speed critical) methods, especially the ones dealing with SSE2-optimized maths (such as LLQuad, LLVector4a, LLMatrix4a) and the result will be a slower viewer.

The error you get is typically such a de-inlining (even though this one won't be speed-critical), and probably a compiler bug; to work around it, simply remove LL_INLINE, but again, I do not recommend at all LTO...

Thanks Henri. I was only experimenting to determine if there was any noticeable difference for my builds. So far, no apparent difference in frame rate, etc. The viewer is just as 'speedy' for me, with or without link time opt. But I will take note and just build without from now on.

Believe me, I did make serious benchmarking, and the loss, even if marginal (1-2%) is measurable... The compilers do a very good job at optimizing bad code almost to the best, but good code is usually not as fast when such invasive (and clueless) optimization options are switched on.

I also confirm your gcc version is buggy, for I just compiled successfully v1.28.0.2 with gcc v9.3 and LTO enabled...

Ah, OK. So something busted in gcc version 10.1.1 20200507 (Red Hat 10.1.1-1) (GCC) then.

Not unusual (every gcc version got bugs), but more common in versions with a small minor (vN.0, vN.1)...

And... clang v9.0.1 just compiled the viewer successfully as well with LTO enabled.

Good to know on clang, though Fedora 32 has moved to 10.0.0, so I'll just avoid LTO.

I guess I just keep searching for the elusive 'magic' that will make my rig perform better. I keep thinking with these specs:that I should just have better experience than I do.

There is no magic, I'm afraid... Use the tune option for the build: it will compile with AVX (if your CPU supports it) or the best supported SSE (2, 3, 4) on your system. It will also enable the -march=native option, and with some luck, your gcc version will do a better job at tuning the code generation for your CPU. But do not expect more than 1 or 2% of gain in frame rates...

For SL, the weak part of your system is the CPU. Your graphics card is an overkill (SL shaders are very light), but the render pipeline being purely mono-thread in SL viewers, the bottleneck is at your CPU mono-core performance level. Currently (things might change with Zen3... time will tell), Intel CPUs shine in this category (mono-core perfs).

I have been using --tune for a long while now and why I compile for myself. When I started using that, I did notice a small gain and I enjoy the 'hobbyist' aspect of self-building.Might be time to give in and return to Intel. I have liked AMD for many years, but they do have their weaknesses. Thanks again, Henri. Appreciate all your hard work.

Or just wait for Zen 3... Should be around by the end of this year.