>>   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