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

Case: SAMA IM01 $69.99 (Currently inverted)
Case feet: 4x Monosaudio 40x20mm Speaker Isolation Feet Speaker $15.50
PSU: Corsair SF750 750W $116.99
Motherboard: ASUS TUF Gaming B850M-PLUS WiFi AMD AM5 B850 mATX $240.89
Processor: AMD Ryzen 9 9950X3D 16-Core Processor$974.55
Processor cooler: Noctua NH-U12A $119.95
Memory: 1x G.SKILL Trident Z5 Neo Series AMD EXPO 32GB (2 x 16GB) 288-Pin PC RAM DDR5 6000 (PC5 48000) $259.99
SSD: 2x SK hynix Platinum P41 2TB PCIe NVMe Gen4 M.2 $644.46
Fans:
REAR EXHAUST 1x Noctua NF-A9 PWM chromax.Black.swap, Premium Quiet Fan, 4-Pin (92mm, Black) $19.90
CPU TOWARDS EXHAUST 2x Noctua NF-A12x25 PWM chromax.black.swap, Premium Quiet Fan, 4-Pin (120mm, Black) $65.80
BOTTOM INTAKE 2x Noctua NF-A12x25 PWM chromax.black.swap, Premium Quiet Fan, 4-Pin (120mm, Black) $65.80
Video card: Geforce RTX 4080 16GB VENTUS 3X OC $1157.00
Monitor: LG 38GN95B 37.5" 3840x1600

Windows 11 24H2
DOSBox 0.74-3

core = dynamic
cycles = max

SMT ENABLED

D1:
Microseconds one loop: 1.47
Drhystones/sec: 681576
VAX MIPS: 387.92

D2
Microseconds one loop: 1.49
Dhrystones/sec: 669456
VAX MIPS: 381.02

//There really isn't a point in disabling SMT but I'll humor you

SMT DISABLED

D1
1.49
672976
383.03

D2
1.51
661841
376.69

//CCD1 parked

D1
1.53
655067
372.83

D2
1.54
651068
370.56

thanks,
is that with hyper threading on or off?
can you post results with the other option?

thanks,
is there a point in testing with 3d cores vs normal cores?

I9 12900k (Stock Values)

D1 :
Microseconds one loop: 1.54
Drhystones/sec: 647,773
VAX MIPS: 368.68

D2:
Microseconds one loop: 1.58
Drhystones/sec: 632,411
VAX MIPS: 359.94