-----Original Message-----
From: Raymond Moyers [mailto:rmoyers@nop.org]
Well the newer ones are getting better, the new
fridge sized
boxes require a fraction of the cooling the old ones did
I know, but power is somewhat expensive for me anyway ;)
getting small, a IBM 3864 modem was a hefty 30 pounds
or so.
Seen the "I put the nut on a rock, and I hit it with the modem"
text file?
So what i said was correct, the herc emu is emulating
the majority
I didn't mean to say it wasn't. Just that you made it sound like
one could completely replace a 390 with a peesee. If that's the case,
you (rather, the people who own the 390 in question) should have never
used a 390 in the first place.
of all that stuff, dasd,, tapes,, card deck with
an emulated
"reader" the 3174's and the terminals, that campus full of stuff
running virtualized on your PC.
One day I'll actually get around to trying it.
at the time when the press would talk about NT
everywhere when
it was knowwhere, i guess doing their part to create the illusion
of "everyone else, why not you?"
You mean NT finally got somewhere? :)
I don't
know exact numbers, but honestly, the CPU in a modern peesee
isn't the weak spot at all. Generally there's some kind of
bottleneck
> (or five) that needs repaired in the design.
Well a decent modern board is no slouch there either
really
The boards aren't, but the disk I/O on most "consumer" systems is
pretty bad, for instance. It should be possible to get better I/O
out of them, especially if there are (as I hear) AMD boards with
64-bit PCI.
You cant really trash PC I/O anymore, its right up
there
with everything else and surpasses all the old workstations,
Might be a dangerous statement. There have been some pretty
impressive workstations. Add that to the fact that some people
consider a one-year-old machine "old."
I won't argue that peesee hardware hasn't advanced. it's literally
mind-blowing what they've done with it, given the origins of the thing.
I just wish they'd started with a nicer architecture to begin with.
current PC I/O dont compete with a current
mainframe,
but what ever did ?
Well, other current mainframes, of course, possibly -- as you mentioned
-- supercomputers, too.
There has been really large R&D sums spent on
pushing PC
performance. and its starting to show bigtime.
I'm sure. Just imagine what they could have done by pouring all of
that cash into Alpha.
In a way, comparing a mainframe to a PC is like a
coal train to a
dodge viper, sure the viper is faster, but lets see how well it
does hooked to 80 hopper cars full of coal eh ?
I'll go along with that.
> a supercomputer at all. When is
"yesterday" in this context? :)
Well litteraly yesterday, dreamworks, pixar etc is
going all linux
for their stuff and the supercomputers people talk about these
days on the
www.top500.org list are linux clusters.
All? I haven't checked top500 recently, but there were certainly a
few non-clusters in the top 20 last time I looked.
My trouble with clusters is that they're not "tightly coupled" enough
to make them very interesting to me, generally. Sure, they'll solve
problems, but again, I/O is the bottleneck.
Another example, look at
www.ltsp.org, they are
netbooting old
retired PC's used a diskless xterminals and hanging up to 200
of them off a modern machine that the apps run on.
I've considered doing something like that just for fun, and it's
interesting, but as far as being a "cluster," I'm not sure it would
qualify in my book. :) Or did you mean it as an example of something
else?
It saves them bucks, and a machine not bloated down
to a 486 with winblows can hump a good load these days.
Windows is up to 486 performance now? You wouldn't know it to use
windows 2k on the pentium 5xx at work.
Your comment
about mainframes having "stayed small" is
oddly amusing,
Stay small they did, sure the linux kernel tree has
grown with the
They've certainly "gotten small," in hardware. I can't argue that the
software isn't efficient, either.
in-tree driver count and branches for all the
different hardware,
the same tree builds for a sun alpha or s390.
It's not so much the size of the tree that bothers me in general with
Linux, but the size of the finished kernel. I do still use it
occasionally on <on topic> hardware, and it really annoyed me when I
had to start using the bzImage target for make ;)
I don't think it's in the drivers, either, but in the kernel somewhere,
that it's gotten larger. There could be a good reason for it, but I'd
like to see some of the stuff optionally removed so that my kernels can
go back to being a few hundred kbytes uncompressed.
Admittedly, loadable modules help.
but the resultant built kernel has not grown much
over the years,
same for the mainframe, sure it has lots of services hanging around
it but its core also has stayed very trim.
In relation to the memory capacity of the hardware on which it runs,
you're absolutely right. I'd still like to see it trimmed some.
One important object of kernel development is for the
code to
get smaller and faster consistent with the other goals.
Linux, the BSD's and IBM's top line operating systems have
done well here.
I can't name any non-microsoft product that hasn't done ok.
My firewall DNS mail www and other sundres is still
running on an
old 486 EISA machine, and its just as happy running the same
kernel and userspace as the 1000mhz linux box with the
nvidia 3D card, runs fast on slow machines, runs all the faster
on fast machines.
I hope you re-compiled specifically for the CPUs. There are some
optimizations that the compiler could make differently for 486 vs.
Pentium (I assume it's 100Mhz Pentium) that could make a difference
in performance.
The agenda for mickysoft dumbf**kware n co, however,
seems
to be ""cover up any hardware performance gains ( and existing
hardware) with bloat, forcing the market to buy new boxes
and end up with no gain at all.""
Agenda? I don't know about that. I honestly don't care what microshaft
is thinking. The result, though, is as you say.
My main beaf with x86 is register starvation, at
least AMD is doing
something about it.
Ok, this is floating off-topic again, but do you mean in their
64-bit core, or in some 32 bit chip?
c++ for example, eats a register for "this"
and on a register
starved cpu it hurts far more than others that have more
registers, this type of thing is perhaps why some fare well
by compare despite slower clock speeds.
There's always "virtual registers."
Its hard to ignore raw speed however, what the x86
lacks
archtectually its seems to be making it up with brute force.
That's true. I won't argue that it's not effective, but it's the
wrong way to do it ;)
Chris
Christopher Smith, Perl Developer
Amdocs - Champaign, IL
/usr/bin/perl -e '
print((~"\x95\xc4\xe3"^"Just Another Perl
Hacker.")."\x08!\n");
'