http://hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins

Post a reply to this message

Ah yes, if you define the test criteria correctly, you can make anybody 
win. ;-)



Back when the old Amiga was around, it used to amuse me to compare how a 
16 MHz PC running Windoze 3 would crawl along compared to my dad's 4 MHz 
Amiga. Not to mention that the Amiga had vastly superior graphics and 
sound, and a true premptive multitasking operating system, and basically 
a PC couldn't compare to it on any scale.

And then I discovered FractInt and POV-Ray, and the benefit of a 16 MHz 
processor became apparent. ;-)

I still wonder though - what if people wrote code today like they used 
to write it back then? How much more stuff could we get done? Even 
Debian Linux *crawls* along on an Amiga, and everybody says how Linux is 
much more efficient than Windoze. But clearly it's no match for AmigaOS, 
so.....



This one amused me though:

"The lower the level of the code language, the less processing cycles 
are required to get something done."

Obviously this is demonstratably false.

Post a reply to this message

On Mon, 08 Oct 2007 18:32:12 +0100, Orchid XP v7 <voi### [at] devnull> wrote:

>This one amused me though:
>
>"The lower the level of the code language, the less processing cycles 
>are required to get something done."
>
>Obviously this is demonstratably false.

Is it?  Please explain.  Depending on the optimization capabilities of the compiler
(or interpreter), and the capabilities of the programmer, it can definitely be true.

Post a reply to this message

Kyle wrote:
> On Mon, 08 Oct 2007 18:32:12 +0100, Orchid XP v7 <voi### [at] devnull> wrote:
> 
>> This one amused me though:
>>
>> "The lower the level of the code language, the less processing cycles 
>> are required to get something done."
>>
>> Obviously this is demonstratably false.
> 
> Is it?  Please explain.  Depending on the optimization capabilities of the compiler
(or interpreter), and the capabilities of the programmer, it can definitely be true.
> 

That's just it, isn't it? It *can* be true - which implies that it *can* 
be false as well.

I'm not going to argue that it *tends* to be true - I'm just saying that 
it is *not* absolutely true as the statement quoted implies.

Post a reply to this message

Fa3ien wrote:
> http://hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins 

"""
Let's go back to the dawn of personal computing and grab an old 
sentimental favorite, the Apple Macintosh Plus.
"""

Wow, I feel old. :-)  Even if you're going to claim Apple created 
personal computing, you could at least go back to the "dawn" of the 
Apple ][.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Orchid XP v7 wrote:

> "The lower the level of the code language, the less processing cycles 
> are required to get something done."
> 
> Obviously this is demonstratably false.

It is more precise to say that the lower the level of the code language, 
the more closely optimum performance can be achieved on a specific 
hardware platform.

But the payoff for most applications isn't worth the increased 
expenditure of brain calories, which is why I no longer program in 
assembler.

Regards,
John

Post a reply to this message

Darren New wrote:

> Wow, I feel old. :-)  Even if you're going to claim Apple created 
> personal computing, you could at least go back to the "dawn" of the 
> Apple ][.

What surprises me is the assertion that it was "ubiquitus".

I am almost 30 years old and I have *never* ever seen a real live Mac in 
my life...

Post a reply to this message

"Fa3ien" <fab### [at] yourshoesskynetbe> a écrit dans le message de news: 
470a2019$1@news.povray.org...
> http://hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins

From the article:
"Most users use relatively small spreadsheets so we used a 640 filled-cell 
format."
"It can be stated that for the majority of simple office uses, the massive 
advances in technology in the past two decades have brought zero advance in 
productivity".

Now that's research. Here's a few other ones:
- Most people don't have to go faster than 5 km/h, so our donkey vs car 
comparison shows that the massive advance in technology in the past century 
have brought zero advance in transportation.
- Most people don't expect to live past 30, so our voodoo vs medicine 
comparison show that the massive advance in technology in the two past 
centuries have brought zero advance in healthcare.
- Keep your expectations as low as possible and you'll always be happy.

G.

Post a reply to this message

John VanSickle wrote:
> It is more precise to say that the lower the level of the code language, 
> the more closely optimum performance can be achieved on a specific 
> hardware platform.

I think that's only true in theory. As in, "anything a computer can 
calculate, a human can calculate too", except that humans make mistakes 
and get bored and can't think fast enough to actually finish the 
calculation before the fly-by-wire unstable jet aircraft plows into the 
mountainside.

Humans are notoriously bad at guessing where the time in their programs 
go, and notoriously bad at keeping track of things like whether the 
value in R147 is going to be needed before the value in R93 is.

And if a compiler already generates optimum code, you obviously can't 
improve on it.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

On Mon, 08 Oct 2007 14:18:57 +0200, Fa3ien wrote:

> http://hubpages.com/hub/
_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins

Well, they started out by crippling the poor AMD system with 
Vista....They don't seem to say whether they tested with the 32-bit 
version of Vista or the 64-bit version (the latter of which is apparently 
notoriously bad, so much so that HP shipped the 32-bit version on my 64-
bit system).

But lots of bad assumptions in that article, overall...

Jim

Post a reply to this message

Orchid XP v7 a écrit :
> Ah yes, if you define the test criteria correctly, you can make anybody 
> win. ;-)

Of course, the comparison is unfaire to some extents.  However, it shows
well that, in everyday situations encoutered by many people, not much
has really be gained, and hungry OS's and office apps tend to spoil
the availiable resources.

Fabien.

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> http://hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins

  Why is the article called "86 Mac Plus Vs. 07 AMD DualCore" when it's
comparing the System 6 OS with Windows Vista? It's continuously comparing
how much memory the OSes require, how much memory their applications
require, how much time it requires for the OS to boot, as well as how
much time it require for their applications.
  It's definitely comparing operating systems, not computers. Then why
is it named as a comparison between two computers?

  Want to compare something which regular people would be expected to
want to do with their computers? How about this:

  You own a cheap 5-megapixel digital camera with a 1GB memory card,
and you have taken a couple of dozens of full-resolution photos with it.
Because you are concerned with how the camera itself would compress the
photos as JPG, you have set up the camera to store then in TGA format
instead.
  Now you want to upload these images to the computer, make some adjustments
to them (such as gamma correction, cropping, etc) and save them in JPEG
format. After that you want to select the best ones and put them up in
your webpage. (Naturally you want to check with several browsers that the
webpage looks ok.)

  So, Windows Vista, in a dualcore AMD, vs. Mac Plus. Which one does this
faster?

  Oh, you can't? Oops!

  Even taking one single step from that process: Applying some gamma
correction to a 5-megapixel image. Even if the Mac Plus was able to do
that, which computer would do it faster?

-- 
                                                          - Warp

Post a reply to this message

"Darren New" <dne### [at] sanrrcom> wrote

> Humans are notoriously bad at guessing where the time in their programs
> go, and notoriously bad at keeping track of things like whether the
> value in R147 is going to be needed before the value in R93 is.
>
> And if a compiler already generates optimum code, you obviously can't
> improve on it.

Since *humans* write compilers, your argument is self defeating.

I know what you are *trying* to say. However, no matter how efficient, high
level to low level is a translation layer, and if the application writer is
as proficient as the compiler writer, he can write at the very least the
same quality, often better, direct low level code than that can be achieved
by writing high level code and having it translated by someone else's
compiler, linked to someone else's APIs and libraries. However, in practice,
it's an economical decision, and that's why there are many, many layers of
abstraction between the machine and the application programmer. The
compromise is that modern applications may be a couple of orders of
magnitude more bloated, in both footprint and performance, than that could
be achived with careful low level coding. "Hello World" windows application
in Delphi, for instance, takes several hundered kilobytes. Don't tell me
that an assembler version can not be more optimized.

Post a reply to this message

Warp escribió:
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> http://hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins
> 
>   Why is the article called "86 Mac Plus Vs. 07 AMD DualCore" when it's
> comparing the System 6 OS with Windows Vista? It's continuously comparing
> how much memory the OSes require, how much memory their applications
> require, how much time it requires for the OS to boot, as well as how
> much time it require for their applications.
>   It's definitely comparing operating systems, not computers. Then why
> is it named as a comparison between two computers?
> 
>   Want to compare something which regular people would be expected to
> want to do with their computers? How about this:
> 
>   You own a cheap 5-megapixel digital camera with a 1GB memory card,
> and you have taken a couple of dozens of full-resolution photos with it.
> Because you are concerned with how the camera itself would compress the
> photos as JPG, you have set up the camera to store then in TGA format
> instead.
>   Now you want to upload these images to the computer, make some adjustments
> to them (such as gamma correction, cropping, etc) and save them in JPEG
> format. After that you want to select the best ones and put them up in
> your webpage. (Naturally you want to check with several browsers that the
> webpage looks ok.)
> 
>   So, Windows Vista, in a dualcore AMD, vs. Mac Plus. Which one does this
> faster?
> 
>   Oh, you can't? Oops!
> 
>   Even taking one single step from that process: Applying some gamma
> correction to a 5-megapixel image. Even if the Mac Plus was able to do
> that, which computer would do it faster?
> 

Nice to see everybody missing the point. From a comment: "for a 
*sizeable* number of 'basic everyday' functions the computing paradigm 
has not improved at all in over two decades".

I agree, the title is totally wrong. It's comparing operating systems 
and software bloat, not processors. The point is: the AMD is thousands 
of times faster, yet it doesn't feel a thousand times faster because the 
OS is a thousand times more bloated.

And by the way: It's using Windows XP, not Vista.

Post a reply to this message

Fa3ien wrote:

> Of course, the comparison is unfaire to some extents.  However, it shows
> well that, in everyday situations encoutered by many people, not much
> has really be gained, and hungry OS's and office apps tend to spoil
> the availiable resources.

I tend to agree. It sadens me that nobody seems to bother trying to 
write efficient code any more...

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> The point is: the AMD is thousands 
> of times faster, yet it doesn't feel a thousand times faster because the 
> OS is a thousand times more bloated.

  Try running povray in both systems and then repeat that.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>> The point is: the AMD is thousands 
>> of times faster, yet it doesn't feel a thousand times faster because the 
>> OS is a thousand times more bloated.
> 
>   Try running povray in both systems and then repeat that.

As somebody who has personally tried this: Yeah, the difference is 
pretty noticable. (!)

You know that example scene what shows all the different textures? It 
took about an hour to render on my 20 MHz Amiga (with the FPU add-on) at 
320x240 with no AA. My current machine can render it in mere *seconds* 
at vastly higher settings.

Until I saw this, I thought the MHz numbers on PCs were lying, because 
every PC I ever used was so much "slower" than my Amiga. But running 
POV-Ray proved otherwise...

PS. Is AmigaOS still a supported platform? It used to be... 0;-)

Post a reply to this message

Warp escribió:
> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
>> The point is: the AMD is thousands 
>> of times faster, yet it doesn't feel a thousand times faster because the 
>> OS is a thousand times more bloated.
> 
>   Try running povray in both systems and then repeat that.
> 

Outside "*sizeable* number of 'basic everyday' functions" category.

And we're talking about software bloat here, not hardware performance. 
If you will compare the performance of the same version of POV-Ray in 
different hardware, it's a *totally* different test.

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> >   Try running povray in both systems and then repeat that.

> Outside "*sizeable* number of 'basic everyday' functions" category.

  Ok, fine: Try running a web browser in both systems.

-- 
                                                          - Warp

Post a reply to this message

somebody wrote:
> "Darren New" <dne### [at] sanrrcom> wrote
> 
>> Humans are notoriously bad at guessing where the time in their programs
>> go, and notoriously bad at keeping track of things like whether the
>> value in R147 is going to be needed before the value in R93 is.
>>
>> And if a compiler already generates optimum code, you obviously can't
>> improve on it.
> 
> Since *humans* write compilers, your argument is self defeating.

Only if you assume all humans are equal, and/or your compiler is your 
biggest and most complicated piece of code.

> I know what you are *trying* to say. However, no matter how efficient, high
> level to low level is a translation layer, and if the application writer is
> as proficient as the compiler writer, 

... and if the application writer understands not only the application 
but also the machine details, and if the application is not signficantly 
larger than the compiler ...

 > However, in practice,
> it's an economical decision, and that's why there are many, many layers of
> abstraction between the machine and the application programmer.

That's not the only reason for the layers of abstraction. Of course, 
everything's possible *given* enough effort. But if it takes you 20 
years to learn the physics, 20 years to learn the engineering to build 
the machine that does the physics, 20 years to learn how to write the 
code that does the calculation to run the machine that does the physics, 
20 years to learn to write the code that makes the calculations that run 
the machine that does the physics, well, you just ran out of time to 
prove your theories of quantum gravity.

> be achived with careful low level coding. "Hello World" windows application
> in Delphi, for instance, takes several hundered kilobytes. Don't tell me
> that an assembler version can not be more optimized.

Sure. But the fact that small programs are bloated doesn't mean large 
programs can effectively be cut down.

The comments on the web page are pretty amusing too. Nobody seems to 
notice much that large programs don't take up more memory than small 
programs. Features you never use never get loaded and don't occupy memory.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Nicolas Alvarez wrote:
> Outside "*sizeable* number of 'basic everyday' functions" category.

I think the argument is about what is "sizeable". A *sizable* number of 
people plug third-party printers into their machines, read email, surf 
the web, and play with digital photos.

> And we're talking about software bloat here, not hardware performance. 

I think that was Warp's point: The title is wrong.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

On Tue, 09 Oct 2007 18:08:51 +0100, Orchid XP v7 wrote:

> Fa3ien wrote:
> 
>> Of course, the comparison is unfaire to some extents.  However, it
>> shows well that, in everyday situations encoutered by many people, not
>> much has really be gained, and hungry OS's and office apps tend to
>> spoil the availiable resources.
> 
> I tend to agree. It sadens me that nobody seems to bother trying to
> write efficient code any more...

I've been saying that for *years*.  :-)

Jim

Post a reply to this message

On Tue, 09 Oct 2007 18:37:09 -0300, Nicolas Alvarez wrote:

> Outside "*sizeable* number of 'basic everyday' functions" category.

Which logically *could* be defined as "anything that meets the criteria 
that makes the older system look to perform about the same as the modern 
system".

I know what you're saying, that thought just struck me.  By definition, 
it would exclude anything a high-powered computer would use.

So the bottom line *really* is that the average person's use of a PC 
hasn't changed in almost 20 years - and as the machines tend to spend 
most of their time idle, it's a question largely of who's machine is 
idling faster and what benefit that idling provides...

Jim

Post a reply to this message

Warp a écrit :
> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
>> The point is: the AMD is thousands 
>> of times faster, yet it doesn't feel a thousand times faster because the 
>> OS is a thousand times more bloated.
> 
>   Try running povray in both systems and then repeat that.

The article focuses on what is everyday computing for a majority
of people : office applications.

Fabien.

Post a reply to this message

"Fa3ien" <fab### [at] yourshoesskynetbe> a écrit dans le message de news: 
470c6e52$1@news.povray.org...
> The article focuses on what is everyday computing for a majority
> of people : office applications.

And this is where the article is patronising and dumb, because it's 
completely clueless about the way people use office applications in 2007.

G.

Post a reply to this message

Tim Cook wrote:
> but 'everyday computing for a majority of white-collar office workers'. 

No, more like "everyday computing for a majority of white-collar office 
workers 10+ years ago."

Because, you know, nobody nowadays uses shared calendars, 
SalesForce.com, or Microsoft Exchange. Virtual no business serves 
dynamic web pages based on a database. Indeed, most businesses don't 
even have inventory or personnel records in a computerized database at 
all. Nobody would *conceive* of actually having all their customers, 
sales, and scheduled deliveries in electronic format, and it's 
mind-boggling science fiction to think maybe such a database would be 
shared between employees. And banks will never get to the point where 
you could use computers to reconcile your accounting with theirs...

A deeply stupid comparison indeed.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Warp wrote:

>   Ok, fine: Try running a web browser in both systems.

Also done that.

Running IBrowse on my 20 MHz Amiga is... not amusing. If you thought IE 
was slow on a 133 MHz laptop, think again! :-S

Post a reply to this message

Tim Cook wrote:

> There's a lot more to office computing, and 
> always has been, than just word processing and spreadsheets.

Not in my office.

(Hell, we're still using M$ Office 97 - because our customers ask us to...)

Post a reply to this message

Darren New wrote:
> ... and if the application writer understands not only the application 
> but also the machine details, and if the application is not signficantly 
> larger than the compiler ...

When I did assembler, I usually had my C compiler generate an assembler 
listing.  I could then pick through the assembly code, and eliminate 
instructions that didn't add value to the function, or replace them with 
shorter or quicker sets of instructions that accomplished the same 
thing.  Maybe my compiler sucked, but I could often reduce a function by 
50% in both size and execution time by whacking code that compilers need 
to put in, but which isn't really required by the algorithm.

I generally did this only for sections of code that got executed a lot 
in a given period of time; otherwise it wasn't worth it.

Regards,
John

Post a reply to this message

Orchid XP v7 wrote:
> Tim Cook wrote:
> 
>> There's a lot more to office computing, and always has been, than just 
>> word processing and spreadsheets.
> 
> Not in my office.

Don't you complain that NT4 doesn't support USB?  And don't you run lab 
equipment and everything as a normal part of your office environment? 
With links to computers in the USA? Or am I misremembering who has that 
job??

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

>>   Ok, fine: Try running a web browser in both systems.
>
> Also done that.
>
> Running IBrowse on my 20 MHz Amiga is... not amusing. If you thought IE 
> was slow on a 133 MHz laptop, think again! :-S

Don't forget that displaying a webpage usually involves a huge number of 
inverse fourier transformations :-)

Post a reply to this message

scott wrote:
>>>   Ok, fine: Try running a web browser in both systems.
>>
>> Also done that.
>>
>> Running IBrowse on my 20 MHz Amiga is... not amusing. If you thought 
>> IE was slow on a 133 MHz laptop, think again! :-S
> 
> Don't forget that displaying a webpage usually involves a huge number of 
> inverse fourier transformations :-)

...wuh?

Post a reply to this message

Darren New wrote:

>>> There's a lot more to office computing, and always has been, than 
>>> just word processing and spreadsheets.
>>
>> Not in my office.
> 
> Don't you complain that NT4 doesn't support USB?

Yes, that's me.

> And don't you run lab 
> equipment and everything as a normal part of your office environment?

No. Our normal *lab* environment. ;-) The *office* just runs Word and 
Access. (And the guys in the lab insist on using Excel a lot...)

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> > Don't forget that displaying a webpage usually involves a huge number of 
> > inverse fourier transformations :-)

> ...wuh?

  I can't believe you don't know what he is referring to.

-- 
                                                          - Warp

Post a reply to this message

"Darren New" <dne### [at] sanrrcom> wrote
> somebody wrote:
> > "Darren New" <dne### [at] sanrrcom> wrote

> >> And if a compiler already generates optimum code, you obviously can't
> >> improve on it.

> > Since *humans* write compilers, your argument is self defeating.

> Only if you assume all humans are equal, and/or your compiler is your
> biggest and most complicated piece of code.

Doesn't matter. Absolute faith in compilers isn't warrented in any case.

> > be achived with careful low level coding. "Hello World" windows
application
> > in Delphi, for instance, takes several hundered kilobytes. Don't tell me
> > that an assembler version can not be more optimized.

> Sure. But the fact that small programs are bloated doesn't mean large
> programs can effectively be cut down.

If you write effectively to mean economically, I agree. Of course one can
not, in that sense, effectively go against the grain. The industry has
chosen a particular path, and all of us pretty much follow it.

> The comments on the web page are pretty amusing too. Nobody seems to
> notice much that large programs don't take up more memory than small
> programs. Features you never use never get loaded and don't occupy memory.

That begs the question of why those features are there to begin with. More
importantly, OS's memory management brings yet another level of layering
into the picture. Ideally, only the application programmer is in a position
to make informed calls about such matters. Compilers, OS, virtual
machines... etc are making decisions without having an "understanding" of
the intent, and are a source of inefficiency. Yet, that's a price we pay for
modern, bloated, multitasking OSs. Add to this AV software that can take up
to half of your raw processing power. I'm not saying we should go back, but
pointing out that much of the performance gained through hardware is
"wasted" through these channels.

Post a reply to this message

> No. Our normal *lab* environment. ;-) The *office* just runs Word and 
> Access. (And the guys in the lab insist on using Excel a lot...)

And I expect the guys in the office often want to include fancy graphics 
into their Word documents, perhaps just company logos on a letter, or 
photos/diagrams in a report.  All of which rapidly use up memory and which 
would slow down hugely on a very slow machine.

Sure, they could use a plain text editor on an ancient machine with 32K of 
RAM, but it's not going to look very professional.

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message 
news:470e9285@news.povray.org...
> Orchid XP v7 <voi### [at] devnull> wrote:
>> > Don't forget that displaying a webpage usually involves a huge number 
>> > of
>> > inverse fourier transformations :-)
>
>> ...wuh?
>
>  I can't believe you don't know what he is referring to.

JPEGs, I presume.

Post a reply to this message

Brian Elliott wrote:

> JPEGs, I presume.

Oh, yeah. I forgot that normal web pages have images on them...

Post a reply to this message

scott wrote:
>> No. Our normal *lab* environment. ;-) The *office* just runs Word and 
>> Access. (And the guys in the lab insist on using Excel a lot...)
> 
> And I expect the guys in the office often want to include fancy graphics 
> into their Word documents, perhaps just company logos on a letter, or 
> photos/diagrams in a report.

Not really, no.

Just chromatagrams. I gather that they're quite large... (Well, the data 
is almost always very noisy.)

> All of which rapidly use up memory and 
> which would slow down hugely on a very slow machine.
> 
> Sure, they could use a plain text editor on an ancient machine with 32K 
> of RAM, but it's not going to look very professional.

My point is not so much that we should go back to using 32K machines, 
but rather that we should go back to the days of programs only using 
more than 32K if they *need* it for something. ;-)

Post a reply to this message

somebody wrote:
> Doesn't matter. Absolute faith in compilers isn't warrented in any case.

Nah. Nothing absolute about it.

> That begs the question of why those features are there to begin with.

Firstly, it doesn't.  "Begs the question" doesn't mean what you think it 
does. ;-)

Secondly, while it's true that 90% of the time you use only 10% of the 
features, it's a different 10% for everyone. Which leads to some rather 
dumb arguments on this list too about compatibility and such.

> importantly, OS's memory management brings yet another level of layering
> into the picture. 

Well, yeah, that's kind of what I was talking about.

> Ideally, only the application programmer is in a position
> to make informed calls about such matters.

I'll disagree. I think many programs are in the middle - too high-level 
to be hand-coded efficiently, but too low-level to let software improve 
on what the programmer asked for.

Consider, for example, an SQL interpreter that can look at the balance 
of values in the tables being joined and decide, on a day by day basis, 
the order in which to join them. Sure, obviously, someone coded this 
behavior, but it wasn't the application programmer.

 > Compilers, OS, virtual
> machines... etc are making decisions without having an "understanding" of
> the intent, and are a source of inefficiency.

Partly, yes, but you can also, for example, save memory and disk I/O by 
using shared libraries that the application programmer can't possibly 
predict at compile time whether they'll already be cached in memory or 
sharable with another application, for example.

> modern, bloated, multitasking OSs. 

Not nearly as much care is taken with modern OSes, I'll grant. It used 
to be the OS would lay out on disk your files, accomidating rotational 
latency and even how long it took to process the interrupt for the next 
sector to be loaded. Nowadays, you can't even figure out how many actual 
cylinders the disk has.

> Add to this AV software that can take up to half of your raw processing power. 

Well, yes.

And using languages like C means you need address translation and memory 
protection on your hardware in order to support multi-user machines, 
which is also a drain on speed.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

> Not really, no.
>
> Just chromatagrams. I gather that they're quite large... (Well, the data 
> is almost always very noisy.)

Exactly, almost every company has their requirements for something more than 
just plain text.  Whether it's specialist scientific diagrams, photos, fancy 
graphics or whatever.  Not many companies just produce reports and things in 
plain-text.

> My point is not so much that we should go back to using 32K machines, but 
> rather that we should go back to the days of programs only using more than 
> 32K if they *need* it for something. ;-)

If I load up a blank Word or Excel document, it uses 0.5% of my physical 
RAM... I can cope with that as being essentially "zero"...

What I'm struggling to cope with at the moment is my CFD simulation that 
keeps running out of RAM :-)

Post a reply to this message

scott wrote:

> Exactly, almost every company has their requirements for something more 
> than just plain text.  Whether it's specialist scientific diagrams, 
> photos, fancy graphics or whatever.  Not many companies just produce 
> reports and things in plain-text.

My point here is not "word processors shouldn't allow you to include 
graphics". My point is "running a word processor should not require 
several hundred MB of RAM" [unless you're actually loading something large].

>> My point is not so much that we should go back to using 32K machines, 
>> but rather that we should go back to the days of programs only using 
>> more than 32K if they *need* it for something. ;-)
> 
> If I load up a blank Word or Excel document, it uses 0.5% of my physical 
> RAM... I can cope with that as being essentially "zero"...
> 
> What I'm struggling to cope with at the moment is my CFD simulation that 
> keeps running out of RAM :-)

What I'm struggling with is that opening Firefox takes about 25 seconds 
because first the OS has to page enough stuff out to disk to make space 
to load the program image into physical RAM.

Seriously. It sounds like nothing, but do you have any idea how 
*annoying* it is when it takes 10 seconds to switch between windows? My 
lowly Amiga with 2 MB of RAM could do all that *instantaneously* 20 
years ago... WTF?

Post a reply to this message

On Tue, 16 Oct 2007 18:33:51 +0100, Orchid XP v7 wrote:


>> Exactly, almost every company has their requirements for something more
>> than just plain text.  Whether it's specialist scientific diagrams,
>> photos, fancy graphics or whatever.  Not many companies just produce
>> reports and things in plain-text.
> 
> My point here is not "word processors shouldn't allow you to include
> graphics". My point is "running a word processor should not require
> several hundred MB of RAM" [unless you're actually loading something
> large].

FWIW, I agree; further, though, if you are loading something large, a 
word processor is often times the wrong application to be using for it.

For example, developing course materials for training, the group I 
started in nearly 5 years ago all used MS Word with master documents.  
Horrible, horrible idea - when Word didn't crash, it was painfully slow, 
even with 2 GB of memory in the machines (Running 2KPro or XP).

Using the right tool for the job is very important.

Jim

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> What I'm struggling with is that opening Firefox takes about 25 seconds 
> because first the OS has to page enough stuff out to disk to make space 
> to load the program image into physical RAM.

  Strange OS you have. I have never experienced that in normal usage.
The only situation I have experienced that is when a buggy software
(sometimes my own, during its development) goes wild and starts eating
memory like mad (because of a bug), causing the OS to swap everything.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Orchid XP v7 <voi### [at] devnull> wrote:
>> What I'm struggling with is that opening Firefox takes about 25 seconds 
>> because first the OS has to page enough stuff out to disk to make space 
>> to load the program image into physical RAM.
> 
>   Strange OS you have. I have never experienced that in normal usage.
> The only situation I have experienced that is when a buggy software
> (sometimes my own, during its development) goes wild and starts eating
> memory like mad (because of a bug), causing the OS to swap everything.

M$ Windows NT, 128 MB RAM.

Add more RAM and Firefox works just great. (The PC I'm sitting at now 
has 3 GB and Firefox starts almost instantly.)

Post a reply to this message

> My point here is not "word processors shouldn't allow you to include 
> graphics". My point is "running a word processor should not require 
> several hundred MB of RAM" [unless you're actually loading something 
> large].

They don't!  If I open a blank Word document, that's 10 MB.  Even if I open 
one of our spec documents that is 79 pages long with diagrams on most pages 
and company logos etc, Word uses up 33 MB.  It's not exactly causing even a 
slight impact on the 2048 MB I have.  Of course if I tried to import lots of 
multi-mega-pixel photos on every page it might start to use more RAM, but 
that is expected.

> Seriously. It sounds like nothing, but do you have any idea how *annoying* 
> it is when it takes 10 seconds to switch between windows? My lowly Amiga 
> with 2 MB of RAM could do all that *instantaneously* 20 years ago... WTF?

But what happened on your Amiga when you tried to use 2.5 MB of RAM when you 
only had 2 installed?  Seriously, if you are going to regularly try to use 
more RAM than you have installed then you must expect page-file swapping - 
and it's not fast.  You can set the page-file size to zero in Windows, then 
it will behave more like your Amiga used to.

Post a reply to this message

scott wrote:
>> My point here is not "word processors shouldn't allow you to include 
>> graphics". My point is "running a word processor should not require 
>> several hundred MB of RAM" [unless you're actually loading something 
>> large].
> 
> They don't!  If I open a blank Word document, that's 10 MB.

...which begs the question, "what are you using 10 MB for?"

There used to be word processors that would run inside less than 60 KB 
of RAM. Sure, nobody could argue they had the same features. And sure, I 
can see how adding lots more features would require quite a bit more 
RAM. But 10,000 KB? That's not "quite a bit more". That's 170 *times* 
more! What's it *doing* with it??

>> Seriously. It sounds like nothing, but do you have any idea how 
>> *annoying* it is when it takes 10 seconds to switch between windows? 
>> My lowly Amiga with 2 MB of RAM could do all that *instantaneously* 20 
>> years ago... WTF?
> 
> But what happened on your Amiga when you tried to use 2.5 MB of RAM when 
> you only had 2 installed?  Seriously, if you are going to regularly try 
> to use more RAM than you have installed then you must expect page-file 
> swapping - and it's not fast.  You can set the page-file size to zero in 
> Windows, then it will behave more like your Amiga used to.

...the point being that software for the Amiga was designed to not 
*require* more than 2 MB in the first place. (Because if it did, you 
just massively reduced your potential market.) Back then, software only 
used memory if it was absolutely, unavoidably necessary. Which is kind 
of my point...



(To actually answer your question, if you ask AmigaOS for 2.5 MB of RAM 
when only 2 MB of physical RAM exists, you get a message that amounts to 
"no, go away". One of the ways they kept the Amiga cheap was by not 
including the hardware necessary for implementing virtual memory...)

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> > They don't!  If I open a blank Word document, that's 10 MB.

> ...which begs the question, "what are you using 10 MB for?"

  Using the available memory in modern computers for eyecandy and useful
stuff as well (such as spellchecking, etc). Also WYSIWYG tends to consume
some memory.

  In some cases "eyecandy" is actually not useless, as it can make things
clearer and easier and more intuitive to use.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Orchid XP v7 <voi### [at] devnull> wrote:
>>> They don't!  If I open a blank Word document, that's 10 MB.
> 
>> ...which begs the question, "what are you using 10 MB for?"
> 
>   Using the available memory in modern computers for eyecandy and useful
> stuff as well (such as spellchecking, etc). Also WYSIWYG tends to consume
> some memory.

Hmm. Word's default dictionary might be 9 MB or so. (And it must load 
that if it does the "spell as you type" thing.) That leaves the rest as 
a larger executable (to implement more functionality) and a little more 
space... for... who knows?

>   In some cases "eyecandy" is actually not useless, as it can make things
> clearer and easier and more intuitive to use.

I won't argue with that. One could describe any GUI as "candy" (since, 
after all, it's perfectly *possible* to operate a computer that doesn't 
even have a graphics cability - and this requires vastly less memory), 
yet it clearly makes [almost] everything much easier.

Post a reply to this message

Orchid XP v7 wrote:
> ....which begs the question, "what are you using 10 MB for?"

It doesn't beg the question. It raises the question. </peeve>

> What's it *doing* with it??

All the COM stuff, perhaps?  Exporting the functionality of Word so you 
don't have to write your own mail merge and spell checker for every program?

> One of the ways they kept the Amiga cheap was by not 
> including the hardware necessary for implementing virtual memory...)

The CPU didn't even support it, just like pre-386 days.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message