I see, thanks for the detailed answers. That leads me to more questions (sorry!) :

1. Can DOSBox and say the fastest domestic PC currently available, emulate the most demanding DOS game (whatever that is) at full speed? With all of the games options, such as draw distance and screen resolution, set to best/max? And would the same be true for the most demanding DOS non-game, such as a ray-tracing program or whatever it would be?

2. If all x86/x64 CPUs can still execute 16bit code, then why can't Windows' 64bit versions run 16bit programs? And does Linux and other OSes refuse to run 16bit code too, if the OS is 64bit?

Kerr Avon wrote:

I see, thanks for the detailed answers. That leads me to more questions (sorry!) :

1. Can DOSBox and say the fastest domestic PC currently available, emulate the most demanding DOS game (whatever that is) at full speed? With all of the games options, such as draw distance and screen resolution, set to best/max? And would the same be true for the most demanding DOS non-game, such as a ray-tracing program or whatever it would be?

Even QEmu using virtualisation cannot.

Kerr Avon wrote:

2. If all x86/x64 CPUs can still execute 16bit code, then why can't Windows' 64bit versions run 16bit programs? And does Linux and other OSes refuse to run 16bit code too, if the OS is 64bit?

Like that was the only thing they no longer support...

Kerr Avon wrote:

1. Can DOSBox and say the fastest domestic PC currently available, emulate the most demanding DOS game (whatever that is) at full speed? With all of the games options, such as draw distance and screen resolution, set to best/max? And would the same be true for the most demanding DOS non-game, such as a ray-tracing program or whatever it would be?

Well, I would say that the time for native DOS machine has stopped. No one is going the create brand new DOS games/apps that are going to harness all the prowess of today's CPU/GPU. New machines continue to improve in performance even though the era of Moore's Law was gone. Given enough time, DOSBox and other emulation technologies will eventually catch up. If Moore's Law were still alive or a breakthrough in material science that re-ignites its glory days at presence, then things could move faster. In raw CPU throughput, I would say hardware assisted virtualization on today's CPUs already outperforms the best of Intel 440BX platform can afford.

Kerr Avon wrote:

If all x86/x64 CPUs can still execute 16bit code, then why can't Windows' 64bit versions run 16bit programs? And does Linux and other OSes refuse to run 16bit code too, if the OS is 64bit?

1. Because in 64-bit long mode the V86 extension that NTVDM (the subsystem that is used to support both 16-bit DOS and Windows programs) uses in 32-bit Windows is not supported so MS would have had to rewrite NTVDM. MS did not want to do this. But you can still install 32-bit Windows 10 that still supports 16-bit programs natively (except programs using DOS graphic modes) on newest 64-bit systems. So this is an operating system restriction. Anyway there is an alternative solution to run 16-bit DOS programs on 64-bit Windows:
https://github.com/leecher1337/ntvdmx64
NTVDM on windows 10 x64

And also there are various solutions to run 16-bit Windows programs. E.g:
https://github.com/otya128/winevdm
Winevdm

2. On one hand Linux was 32-bit from the beginning so no 16-bit legacy, on the other hand even if there had been a 16-bit Linux era because of the source code based distribution model supporting legacy 16-bit binaries would not have been necessary. If your question concerned 16-bit DOS/Windows programs, Linux never was able to run them natively.

Falcosoft wrote:

1. Because in 64-bit long mode the V86 extension that NTVDM (the subsystem that is used to support both 16-bit DOS and Windows p […]
Show full quote

Kerr Avon wrote:

If all x86/x64 CPUs can still execute 16bit code, then why can't Windows' 64bit versions run 16bit programs? And does Linux and other OSes refuse to run 16bit code too, if the OS is 64bit?

1. Because in 64-bit long mode the V86 extension that NTVDM (the subsystem that is used to support both 16-bit DOS and Windows programs) uses in 32-bit Windows is not supported so MS would have had to rewrite NTVDM. MS did not want to do this. But you can still install 32-bit Windows 10 that still supports 16-bit programs natively (except programs using DOS graphic modes) on newest 64-bit systems. So this is an operating system restriction. Anyway there is an alternative solution to run 16-bit DOS programs on 64-bit Windows:
https://github.com/leecher1337/ntvdmx64
NTVDM on windows 10 x64

And also there are various solutions to run 16-bit Windows programs. E.g:
https://github.com/otya128/winevdm
Winevdm

2. On one hand Linux was 32-bit from the beginning so no 16-bit legacy, on the other hand even if there had been a 16-bit Linux era because of the source code based distribution model supporting legacy 16-bit binaries would not have been necessary. If your question concerned 16-bit DOS/Windows programs, Linux never was able to run them natively.

But in 64-bit mode 16-bit descriptors still work? So 16-bit Windows programs might still be able to be implemented?

Are Ryzen numbers still needed? Just noticed this thread, I can post some stock Ryzen 2600 results tonight.

Ryzen 5xxx numbers would be interesting

Ryzen 5600x

Kubuntu, DOSBox-SVN r4440 64-bit, dynamic core, cycles max 105%

1D1:
2Microseconds 1 loop: 1.66
3Dhrystones / second: 601504
4VAX MIPS rating: 342.35
5
6D2:
7Microseconds 1 loop: 1.65
8Dhrystones / second: 607211
9VAX MIPS rating: 345.60

Windows 10, DOSBox-0.74-3 32-bit, dynamic core, cycles max 105%

1D1:
2Microseconds 1 loop: 1.94
3Dhrystones / second: 515298
4VAX MIPS rating: 293.28
5
6D2:
7Microseconds 1 loop: 1.96
8Dhrystones / second: 511182
9VAX MIPS rating: 290.94