Re: Emulated VAX build done!

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> IPC = Inter-*what* Communcation?  Process?  Processor?  Other?
>>> The Pentium 4 had horrible IPC,
>> What is IPC here?  [...]
> Oops... I was using IPC as instructions per clock ;)

Oh!  I don't think I've seen that use before - certainly not to recall
it now - so I wasn't likely to think of that expansion.

> OTOH, modern(-ish) processors can take both paths speculatively, so a
> modern(ish) processor could start the fetch for a branch many cycles
> before the branch is reached, but anything which would make the
> Pentium 4 flush its pipelines and wait for memory would take forever,
> comparatively.

True.  But, once again, that's a reason for the P4 to be slower, not
one for the i7 to be slower.  Still baffling.

>> According to strace, [the emulator on Linux] is not burning syscalls
>> at anything like the rate that would be required if stack
>> trampolines on that OS required a syscall.
> I'm curious about this in part because I'm collecting data about
> speedups due to toolchain optimizations versus slowdowns due to
> vulnerability mitigations, and this might be a good data point.

Well, the whole non-executable stack thing which came in with...NetBSD
2.0, I think it was, was as I understand it motivated by exploit
mitigation desires, but it completely broke nested functions.
Nowadays, nested functions _work_, but at a crippling performance cost
(a syscall, probably once per entering of their enclosing function I
would guess).

Come to think of it, I wonder whether there is one trampoline set up
per nested function, or one per enclosing function.  If the former,
step() in the emulator will be insanely expensive, because it has a LOT
of nested functions, of which at most one is used in most-to-all calls.
I probably should look at finding a way to rewrite those instructions'
implementations without nested functions.

Perhaps the Linux trampoline setup uses an expensive form of memory
barrier; that could explain part of it.  But then, the NetBSD version
would have to do so as well.  Maybe i386 and amd64 differ on that?  I'm
trying to come up with a possible reason for the difference.

>> NetBSD is my mutant 5.2.  [...]
> 5.2 isn't THAT old, particularly considering the kinds of systems you
> run ;)

True.  I run 1.4T on systems where I can, 5.2 on systems where I need
the additional hardware support, and 4.0.1 on some, mostly small,
intermediate systems (like the PCEngines machine that is my DSL
endpoint).

There are exceptions.  For example, I have three peecees, one running
each of those three versions, as devleopment machines for the relevant
OS versions.  (The 5.2 one is the P4 we've been talking about.)

>> Linux is...well, I'm not enough of a Linux sysadmin to know how to
>> describe it precisely.  Here are my first cuts at it:

>> [Pavilion] 79> uname -a
>> Linux Pavilion 5.4.0-144-generic #161-Ubuntu SMP Fri Feb 3 14:49:04 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
> That's practically new!

Yes - especially by my standards.  But, well, it's a work machine.

> How about we try running NetBSD 5.2 on the Ryzen system, and seeing
> how it compares with the Pentium 4?

That would be fine with me.  I'll write to you off-list about that.

> It'd then be interesting to run the same Linux you're running on the
> same system and compare.

It would, it would indeed.  It might also be interesting to compare
NetBSD 5.2 i386 and NetBSD 5.2 amd64 as host OSes.  I think the P4 is
strictly i386, no amd64....

>> The hardware the Linux machine is running on is set up [...]
> I can always run older NetBSD and/or Linux on the Ryzen using nvmm &
> qemu.

Provided they are running such that the hypervisor doesn't meddle in
instruction execution for almost all instructions, it should be an
informative comparison.  Especially if we use the same v12n setup for
each OS.

>>> What other systems will that version 1.4T run on?
>> so it at least _tries_ to run on the 4000/60 you mention.

>> It's likely to take a while [to build a GENERIC kernel]

The GENERIC kernel build, incidentally, is now crunching on the big
mkdep (an mkdep command that's about 9000 characters long).  I don't
have any easy way to tell how far through that command it is.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B