krcroft wrote:

I ran some tests and the two are roughly identical, within the noise of my system.

I was referring to pre-release builds. Specifically this build. It didn't seem too optimal.

1LD_PRELOAD=./libpng12.so ./dosbox --version
2DOSBox version v0.75.0-pre-220-g78cc6

Tested on the same kernel with mitigations=off.

krcroft wrote:

3. Lock your processor at its maximum frequency […]
Show full quote

3. Lock your processor at its maximum frequency

Copy code to clipboard

1echo performance | sudo tee /sys/devices/system/cpu/cpufreq/policy*/scaling_governor
2echo 100 | sudo tee /sys/devices/system/cpu/intel_pstate/min_perf_pct

I do it like this.

1cpupower frequency-set -g performance

My processor is westmere microarchitecture does not use intel_pstate.

The first result is dosbox-staging pre-build, the second is mine.
DHRY1ND: 106.4 | 119.43
PCBench: 69.7 | 77.2
Quake 320x200, 800x600 demo1: 95.7 27.0 | 110.1 33.0

Who uses libpng-1.2 in 2019 yet?

Edit:
Of course, such a comparison is not entirely fair. Pre-release build has no task to be optimized for specific benchmarks, or whether processor types are created for a completely different purpose. Although it may work better "-mtune=generic".

"The first result is dosbox-staging pre-build, the second is mine."

We know how the dosbox-staging dynamic release binary is compiled via the .github/workflows/linux.yml file in its source tree. It's a basic -O3 build meant to be universally compatible.

But we still need details about your build: how, exactly, can we reproduce it? ie:
- source SVN? staging?
- with jmarsh's latest reported adjustment? - 64-bit dynamic_x86 (patch)
- compiler version (GCC 9, Clang 8, etc.. )
- exact CFLAGS, CXXFLAGS, LDFLAGS
- Are you using scripts/build.sh in the staging source? (if so, what is your launch line?)

How does your build or comparison relate to this thread (are you applying jmarsh's latest adjustment)?

If you're building the same sources with FLAGS=A versus FLAGS=B, then yes, building with stronger optimizations usually produces that effect. Which is interesting to report, but probably should move this to the dosbox-staging thread or create an issue on the GitHub page.

@latalante thank you for testing our version 😀

I think this thread should be kept on topic of jmarsh's patch; I imported it to dosbox-staging for easy reference and cherry-picking and to make it easier to create apples-to-apples comparison in the future:

• 919514 (branch vogons/dyn-x86-carrypatch-1, rebased on top master to utilize CI)
• 026d41 (branch vogons/dyn-x86-carrypatch-r4298, rebased on top of the latest SVN trunk)

Automatic snapshot builds from dosbox-staging are designed to be running out-of-the-box on a wide range of Linux distributions, so they are not good candidates for comparison against builds created on users' machines. And yeah, old libpng12 is part of that - Ubuntu 16.04 LTS and distributions derived from it might be missing libpng15, libpng16, or both. libpng12 should be available for *all* Linux distributions (if that's not right, report a bug in dosbox-staging, please). Hope it clears it up 😀. [edit] libpng12 situation is more complicated than I anticipated #84

@dreamer, @krcroft Yes, I used an jmarsh's additional patch. Only he does not affect the results in mp3 encoding with the help of lame and in lua (alioth-benchmarksgame). I didn't post these results. The difference was equally clear.

I enjoy this huge improvement in 64-bit performance (great work). Yes, I will follow further progress (I am looking forward to using full virtualization).

As for libpng12, (I built it in 2 minutes, that's not a problem), and now I noticed that it is in the Archliux repository.