PC 4GB RAM limit

[Mxsmanic]

If I thought I could make XP look and feel like 2K, I might consider
using it.

Those are simple desktop options. My XP system looks like NT 4.0 for
the most part.

 

[Mxsmanic]

That it's almost universally popular is defacto proof it's not just "a
really stupid way to do things."

Popularity is not necessarily evidence of technical superiority. The
entire x86 architecture is a case in point.

Maybe if you put more effort into understanding why it's done that way it
wouldn't be such a mystery.

No need. It wastes memory.

This is one reason why no amount of address space will ever be enough.
You can accommodate real-world needs with a certain number of bits, but
you cannot compensate for stupidity with any number of bits.

 

[Mxsmanic]

No, it just proves that someone a long time ago thought it was a good idea and
no one has thought otherwise. BTW, there are other ways to do it that doesn't
require using memory addresses, it's just more transparent to the current
processor architecture.

Mainframes have been doing it in other, better ways for nearly half a
century.

 

[Al Dykes]

Mainframes have been doing it in other, better ways for nearly half a
century.

Other ways ? Mainframes invented VM in the 60's, went from 24 bit to
31 bit addressing in the 70's and had multi-gigabyte memory
configurations in the 80s.

 

[Mxsmanic]

Other ways ? Mainframes invented VM in the 60's, went from 24 bit to
31 bit addressing in the 70's and had multi-gigabyte memory
configurations in the 80s.

Mainframes have handled I/O with fully independent I/O controllers for
decades. No dedicated main memory required, and highly efficient I/O.

 

[Phil Weldon]

Compare the cost of one mainframe I/O controller with the cost of 10 desktop
computers.

 

[Mxsmanic]

Compare the cost of one mainframe I/O controller with the cost of 10 desktop
computers.

The mainframe I/O controller costs less to build, but margins in
mainframe hardware land can be as high as 95% or more.

 

[David Maynard]

No, it just proves that someone a long time ago thought it was a good
idea and no one has thought otherwise.

You are presuming this is a 'PC' thing and it's not. Memory mapped I/O has
been around a long time, long before the 'PC'.

BTW, there are other ways to do
it that doesn't require using memory addresses,

Of course there are. But just because an 'alternate' is available doesn't
make it 'better' nor does it prove the current solution is "really stupid."
In fact, it suggests there's likely a good reason why the current method
was picked over the 'alternates'.

it's just more
transparent to the current processor architecture.

Simply not so. The x86 architecture explicitly supports separate I/O space,
as opposed to, for example, the 6800 architecture which had none and touted
"memory mapped I/O" as a 'feature' (while neglecting to mention one could
do it with any processor).

 

[David Maynard]

Sure it can - called Virtual Memory.

Only if it's available.

 

[David Maynard]

Not as RAM.

It's still "available space."

 

[David Maynard]

David Maynard writes:




Not all, but certainly those related to higher maximum speeds.

Oh? You've never seen a higher than 35 MPH speed limit anywhere?

Nobody sells 386 machines any more, and no current software runs on
them.

That doesn't answer the question it just begs it. Not to mention there are
plenty of 386 machines available and good old, non bloated, software to run
on them.

That *was* your complaint, remember?, that the 'current' software, compared
to the earlier software, was just added bloat and did nothing but use up
hardware speed. So the old stuff should be just the ticket.

I prefer a GUI for desktops, anyway. The GUI absorbs a huge
amount of machine capacity, though.

Clearly it's providing something useful for the consumed capacity since you
seem to be adamant about keeping it even in the face of earlier 'non
bloated' alternatives.

 

[David Maynard]

David Maynard writes:




Popularity is not necessarily evidence of technical superiority.

I didn't say anything about technical "superiority." I was dealing with
"really stupid" and there's a huge range in-between the two.

The
entire x86 architecture is a case in point.

I would still maintain that 'popular' precludes "really stupid" and that
'technical superiority', as commonly used by engineers, isn't necessarily
'the best'.

No need. It wastes memory.

No, it uses memory for a purpose, just as anything else does. And just
because the one and only criteria you have, to the exclusion of all else,
is 'memory' doesn't make other considerations "really stupid."

This is one reason why no amount of address space will ever be enough.

The real reason is that increasing processor power and larger memory
capacities allow previously impractical things to be done.

You can accommodate real-world needs with a certain number of bits,

640K is more than anyone could ever need, eh?

but
you cannot compensate for stupidity with any number of bits.

Actually you can, to some degree, with programs that contain knowledge and
capabilities the user does not, but that's an entirely different topic.

 

[David Maynard]

Phil Weldon writes:




The mainframe I/O controller costs less to build, but margins in
mainframe hardware land can be as high as 95% or more.

With 'margin' defined as what?

 

[David Maynard]

Al Dykes writes:




Mainframes have handled I/O with fully independent I/O controllers for
decades.

They also cost a ton of money, not to mention their purpose isn't to be a 'PC'.

No dedicated main memory required, and highly efficient I/O.

Good example of the "appropriately inappropriate measurement criteria" though.

Why isn't my car equipped with rocket motors? Space craft have been using
them for decades.

 

[David Maynard]

On Thu, 19 May 2005 06:29:54 -0500, David Maynard




I don't feel it would cost more nor have fewer features.

If one removes cost and features then why do you think they're writing
anything to begin with?

Hey Bob, I want you to rewrite X. Ok, Why? Oh, no reason, just to use up
memory.

Not a very likely scenario.

Cost is somewhat fixed, what the market will bear

That's why new features have to wait till other costs come down, such as
more powerful processors and cheaper memory, or less costly development
processes made possible by more powerful processors and cheaper memory.

someone
buys the application(s) without foreknowledge of the bloat.

As for features, yes I'd be willing to do without the
features that seem to take up hundreds of MB of space, since
an entire office suite can take up under 50MB.

Then use that one. Problem solved.

Sure, but suppose an app has 10% additional features added
over 2 versions but grows by 50%.

Then I'd say it takes a 50% growth to get those 10% more features.

It's obvious you think there should be some 'numerical equivalency' between
your 'features' measure and 'growth' but I have no idea why.

If, for example, getting a 10% improvement in acceleration for my car cost
50% more I'd probably say it wasn't worth it, unless it meant I'd win at Indy.

There just isn't any 'correlation' between 'feature' and 'growth', per see.
It's the value of the feature vs what it costs that matters and, as the
example shows, that depends on the user and the application.

I consider the bloat to be the unnecessary parts by
definition, not merely that it's larger than a former
version was... so it seems our concept of bloat varies.

No, what varies is, as I said, your presumption that there's no reason for
the increase in size so that you call it bloat.

I'm contending there *is* a reason for the size increase and that's why I
put "bloat" in single quotes.

Code generally comes from somewhere. It's acquired/made and
put into the application.

Precisely. And people do not expend that effort for no reason.

But your example has people expending effort making/acquiring bricks and
putting them in the car for no reason.

It doesn't fit.

Could be laziness, incompetence, lack of sleep, deadlines,
or general apathy, among other reasons I can't foresee.

People don't write code, or make bricks, when they're asleep, nor out of
apathy. It tales effort and people don't expend effort for no reason.

Comfortable?
Naw, I feel like a sardine in anything modern, even with the
car is big the dashes these days wrap around, plus the
center divider... I feel as cramped in an SUV as I felt once
in a long-ago friend's ~ '80 Ford Escort. And no, it's not
me that's now bloated. ;-)

Hehe. Well, you picked the wrong car then

Sure, they are better but if you recall my plans for
doughnuts in your back yard, well the front-wheel drive
kinda kills that idea.

You're loosing sight of the point. It was the "appropriately inappropriate
measurement criteria."

You're pretty daring bringing politics into a discussion.
What will the trolls think?

Hehe

Daring? Heck, everyone hates politicians and I made no 'partisan' reference
whatsoever.

Not necessarily true, I actively seek smaller apps that will
fit my needs...

You're still paying for it. Or did for what you have, just as with anything
else.

and still use Office 97 more than the newer
versions even though I've a license for O2K/XP. Seems that
along with the bloat, Excell leaves crap behind in
spreadsheets that can only be removed with '97 verison or
manually editing them which I do hate to do. Probably a
patch somewhere for that, don't care enough to look since
'97 does the job.

I don't drive around in Ferraris either but that's hardly a comment about
the automobile industry in general.

You might be making a leap there about state-of-the-art
coding. Might it be just the opposite, that they're not at
all using state of the art coding and this is why we have
massive bloat?

No. The amount of code, and memory, consumed per 'feature' is the state of
the art. The market place assures that.

That you apparently don't 'agree' with the techniques is another matter,
but then it's easy to be critical when one doesn't have to make the
decisions. Which gets back to the market: it forces the decisions to fit.

Consider how many 1MB-15MB apps are out
there, then what more some of the massive Adobe, Macromedia,
and Microsoft apps do. Even when you choose minimal
installs it insists on dozens of MB. I suppose it's a
matter of choice, I choose to avoid them even with ample
memory and HDD space... but then that may be part of why I
always have plenty of both without having to go to extra
measures to get there. I'm a big fan of only upgrading for
a need, not just to have the latest apps. Could partialy be
because I don't have to fool with warez I suppose, over the
years have accumulated plenty of stuff.

You're doing what I challenged mxsmanic to do: use the older software. And
that's a perfectly fine choice as long as it suits your needs, but it says
nothing about 'bad coding'.

 

[David Maynard]

I, for one, usually prefer simpler programs which are properly
controllable. The general Unix philosophy of connecting simple
things with scripts and pipes is far more flexible, understandable,
and controllable. Not to mention more accurate.

Perhaps true except for the 'understandable' part. It's a heck of a lot
easier for the general purpose user to operate with GUIs, pre-canned
configurations, and wizards in semi familiar English contexts than it is to
learn a gaggle of separate commands and their peculiar syntax.

Of course, the most flexible and controllable computer is one with no
software at all. You can then make it do whatever you want without
constraint from things like what someone else's vision of a proper O.S. is.

Be even more flexible and controllable if you made your own computer right
down to custom ICs.

 

[David Maynard]

What you feel may not be true (assuming you are thinking of large programs
and operating systems.) There is a very good economic reason programs and
operating systems are get larger. In 1966 computer time (for a
mid-top-range computer) cost $200 US per hour. In 1966, programmer time
(for a mid-top-range computer) cost $4 US per hour. Programs were very
small, and a lot of people time was spent specifically to make those
programs small. Speed was sacrificed for small size. The size and shape
(features) of software was constrained by programming cost vs. computer
facility time, memory storage size, mass storage size, processing speed, and
mass storage speed. Every single one of these factors has changed
dramatically.

That is all just SO true. Programmers used to go through incredible efforts
just to squeeze things into severely limited resources. And it made sense
when a Kbyte of RAM ran into the thousands of dollars but, as you aptly
point out, what's the point in reverse? Spending thousands in code
optimization rewrites just to 'save' a few pennies of space?

Not to mention you wouldn't 'save' the pennies because no one could afford
the program to being with.

Completely new capabilities have arisen. Almost all processing used to be
in 'batch mode'; real time interaction wasn't necessary. Many systems did
not even have interrupts. Displays were rows of lights, or at most, a 30
cps teletype. Magnetic tape storage was very low in density, 800, 1600, or
(gasp) 3200 bits per inch, 8 or 9 tracks; 1 INCH long data blocks, 1/2 INCH
interblock gap. Not a whole lot of code is necessary for such low densities
and I/O speed.

If you REALLY want smaller code, then what do you want to give up?
If you REALLY want smaller code, then why not have applications that only
have the capabilities YOU use?
If you REALLY want smaller code, then why not write your own applications,
or hire system analysts and programmers (and testing and quality control
personel)?

Is it better to have capabilities you MIGHT need, or to save 1 Gbyte hard
drive storage (at a cost of $1 US)? Capabilities you don't need at the
present are probably in use by others, and might be needed by you in the
future.

Try making a list of the capabilities you are willing to forego, and then
compare against similar lists by other users.
Examples
1. I'd be quite willing to forego grammar checking in 'Word'.
2. I'd be quite willing to forego working on spreadsheets within
'Word'.
3. I'd really, really like to lose many capabilites in Adobe Reader.
4. I am NOT willing to forego viewing html in email and websites.
But
1. Some users may actually think 'Word' grammar checking is useful.
2. Some users may feel that manipulating spreadsheets within 'Word'
boosts productivity.
3. Well, Adobe Reader is free, so ...
4. Some users seem quite happy with text only.

The two sample lists above bring up still another important point. Once
there were thousands of computer users and thousands of very specific, well
defined uses. Now, the majority of the population, middle school or above,
in each industrial country is a user, each with a general list of flexible
tasks.

Well put.

That's a necessary part of the economies of scale equation.

 

[David Maynard]

Don't forget the other extreme the head-per-track magnetic drum,

Yeah. That's what I was referring to with "heads all over the place."

the
multi-disk, single head RAMDAC from IBM circa 1964

There were all sorts of interesting things. I just didn't run into all of
them

The 30 incher was strange not just from the size but because it looked like
a home hobbyist took a chunk of aluminum, cut it round, and stuck it on
motor. No fancy air controlled environment, no 'tight tolerances', etc.
Rather primitive.

 

[Phil Weldon]

Just a note; the Hubble Space Telescope uses 80486 CPUs. Wonder how much it
cost to write THAT set of tight code?

..
..

That doesn't answer the question it just begs it. Not to mention there are
plenty of 386 machines available and good old, non bloated, software to
run on them.

,
,

 

[Phil Weldon]

I left out a word - should have read "Don't forget the other extreme FROM
the head-per-track...
The head-per-track I worked with was the RCA Spectra 70-47; 256 KBytes main
memory (1 Microsecond cycle time for a 4 byte word0 and an 8 Mbyte
head-per-track drum as a page file (my alpha Spyder could park in the
shipping case.)