> 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

> 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

> 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