it seems, I am the one who is “on” for performance issues
I saw Aurelian’s post time ago, challenging, that users may demand too easily performance updates without recognizing the incredible amount of work necessary to improve something, which in the worst case is unspecific…
Currently what moves me is maybe spread over several issues on github. The one motivates me tonight to write about, is this one:
- I use gentoo and keep it up to date by cron-scripts with not many but quite some development packages installed.
- The major compile optimizations are, it is “RELEASE”, I assume (no debug code implemented) and in my /etc/make.conf I have the following:
CFLAGS="-march=nocona -O2 -mtune=generic -mssse3 -mfpmath=sse -pipe"
Not that aggressive
- I actually don’t know, how dt compiles with its build.sh and how to smartly implement tweaks, which are not lost after a new git pull
- Recently I upgrade from an old core i7 to a core i9 9900k and firstly had a big WOW! on dt 2.6.2 but that somehow got reverted a bit, when I start using dt-27, so that brings me on it.
- As @Claes sometimes can reproduce my issues on his Ryzon, I get the feeling, the performance issue might be more visible on the faster machines, as they are supposed to be lag-free where others (please don’t take it arrogant) may add another 0.2s to any already existing waiting time. So maybe it is not cycle time but fix absolute times… Sorry professionals, if that sound silly, I try my best to describe what I experience…
- please see, what I report in aforementioned issue about the findings on nvidia-smi
Still I have some strange multiplication of module entries in history stack, just because I touch the same module several times. That might be related, it might be not. However, it reminds me on another issue #2420 I reported time ago which unfortunately is closed, even I could see from Bruce’s video, that it still can occur.
I love dt and hope with this I can be a little part of making it further better…