"Toy" computers http://www.conmicro.cx/hercules

From: Christopher Smith <csmith_at_amdocs.com>
Date: Tue Apr 30 10:11:49 2002

> -----Original Message-----
> From: Raymond Moyers [mailto:rmoyers_at_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");
'
 
Received on Tue Apr 30 2002 - 10:11:49 BST