Port-vax archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Emulated VAX build done!
>> I expect IPC to be close to irrelevant. (...)
IPC = Inter-*what* Communcation? Process? Processor? Other?
>>> Something is slowing down the Linux machine considerably.
>> The time difference is, thus, [...] about 1.538.
> But even if the Core i7 was 100% throttled [...], the clock
> difference would be 1.625 difference.
> 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.
> 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.)
> You mentioned that the overhead of setting up stack trampolines on
> newer NetBSD, and I have to wonder whether there's some overhead
> issue on whichever version of Linux you're running.
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 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.
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
[Pavilion] 80> ls /etc/*release*
/etc/lsb-release /etc/os-release
[Pavilion] 81> cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.6 LTS"
[Pavilion] 82> cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.6 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.6 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
[Pavilion] 83>
If you can tell me what to do to get more useful information, I'd can
do so.
> Perhaps it'd add a good data point to run an older NetBSD on a newer
> processor to 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 don't have a real KA630 set up to try this on, so [...]
> What other systems will that version 1.4T run on?
I'm not sure. Looking at sys/arch/vax/vxa/locore.c, I see, amonjg
other things,
#if VAX46
case VAX_BTYP_46:
dep_call = &ka46_calls;
strcat(cpu_model, "4000/60");
break;
#endif
so it at least _tries_ to run on the 4000/60 you mention.
The exact kernel I've been using will not work; the block of CPU
support options in that kernel config is
# Here are all different supported CPU types listed.
options "VAX630" # MV II
though I can certainly build one with VAX46 turned on.
sys/arch/vax/conf/GENERIC says
# Here are all different supported CPU types listed.
options "VAX8600"
options "VAX8200"
options "VAX780"
options "VAX750"
options "VAX630" # MV II
options "VAX650" # MV III, 3600, 3800, 3900
options "VAX670" # VAX 4000/300
options "VAX410" # VS 2000
options "VAX43" # VS 3100/76
options "VAX46" # VS 4000/60
options "VAX48" # VS 4000 VLC
options "VAX49" # VS 4000/90
so _someone_ thought it should work. It'd probably make more sense to
build a GENERIC kernel, because the one I've been using is cut back to
just the hardware I emulate, think I'm likely to add, or need to
include for some other reason:
# < UVAXII egrep -v '^#' | egrep -v '^[ ]*$'
...
mainbus0 at root
ibus0 at mainbus0 # All Microvax
uba0 at ibus0 # Qbus adapter
qe0 at uba? csr 0174440 # DEQNA/DELQA
dhu0 at uba? csr 0160440 # DHU-11
qe1 at uba? csr 0174460 # DEQNA/DELQA
uda0 at uba? csr 0172150 # UDA50/RQDX?
uda1 at uba? csr 0160334 # UDA50/RQDX?
mtc0 at uba? csr 0174500 # TMSCP controller
mscpbus* at uda?
ra* at mscpbus? drive ? # MSCP disk
...
(mtc0 is the "some other reason"; it's commented
# We don't want tape, but uda.c is broken, referring to mtc regardless.
because I haven't yet fixed uda.c in that regard.)
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!
/~\ 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
Home |
Main Index |
Thread Index |
Old Index