Re: Emulated VAX build done!

[John Klos <john%klos.com@localhost>]

> IPC = Inter-*what* Communcation?  Process?  Processor?  Other?
>
> > The Pentium 4 had horrible IPC,
>
> What is IPC here?  Since you're speaking of hardware, I can't see it as
> anything but Processor, in which case it's irrelevant - the P4 machine
> is single-CPU.  But you were looking for reasons the *i7* would be
> slow.

Oops... I was using IPC as instructions per clock ;)

> > and even worse ability to branch without huge penalty,
>
> That could very well be relevant.  Control flow within the emulator is
> very much not linear.  (It would be relevant in the other direction,
> though, since, as remarked above, the i7 is the one that's
> comparatively slower than expected.)

Any processor taking a mispredicted branch and going out to memory is 
going to be slow. While bandwidth has improved dramatically from the P4 to 
Core i7, the actual latency to first fetch from DRAM hasn't changed.

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.

> According to strace, it is not burning syscalls at anything like the
> rate that would be required if stack trampolines on that OS required a
> syscall.  (Also, I am inclined to doubt performance would be better
> than on the P4 if it were.  Even that Ryzen 9 3.7GHz you were kind
> enough to give me a guest login on is hard-pressed to compete with the
> P4 when it's having to do a syscall during trampoline setup.
> Admittedly, NetBSD and Linux are very different, but not so different
> that crossing the hardware privilege barrier will be grossly different
> in cost.)

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.

> > I'm really curious about this.  Which versions of NetBSD and Linux
> > are you running?
>
> NetBSD is my mutant 5.2.  If you want to pore over the detailed
> differences between what I'm running and stock 5.2, git clone
> git://git.rodents-montreal.org/Mouse/netbsd-fork/5.2/src (and .../xsrc
> if you want xsrc, though I doubt it's relevant here).  I can also send
> you the commit list and/or diffs between any points of interest if that
> would be preferable for you.

5.2 isn't THAT old, particularly considering the kinds of systems you run ;)

> 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!

> If you can tell me what to do to get more useful information, I'd can
> do so.

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

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

> The hardware the Linux machine is running on is set up to dual-boot a
> very similar 5.2.  Probably not quite identical; I haven't been
> manaical about keeping it updated - I can update it, certainly, but
> that machine exists for work reasons and taking it out of work
> production for over a week is...pretty much a nonstarter at present.
> (I do have another machine that is being groomed to replace it, but it
> is not yet ready.)

I can always run older NetBSD and/or Linux on the Ryzen using nvmm & qemu.

> > 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, though.  I'll get it started; even if it
> turns out there's no use for it, I've got nothing better to do with the
> CPU cycles at the moment, and I can't exactly save them for later use!

Ha ha ha... True. Sure. I can try netbooting it so I won't have to undo 
anything with the current NetBSD 10 install (which is running VERY well).

John