Subject: Re: shocking speed performance!
To: None <kim@pvv.ntnu.no>
From: Paul Wain <paul.wain@liberate.com>
List: port-arm32
Date: 05/20/1999 00:40:49
--------------02AD028ACC1D03CB05A67FED
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
You know I feel this is a lot unfair, espically on Mark.
I have never had any problems with any of my machines, be it a RiscPC,
A7000, Acorn NC or Shark, getting NetBSD working and/or compiling. I know
I didnt have SCSI based machines, or machines with anything but Ant
ethernet cards (with the exception of the Shark),or strange set ups, but
at one time I had a lot of machines running.
And appart from the startup time of Netscape 3.x/4.x on the RiscPC 700, I
can never really say performance sucked (okay there were some issues with
DEC on the compiler when we were doing shared libraries but even so that
was one off initialization code)....
And a dual processor P400 running a SMP kernel is going to out perform a
233Mhz SA110 on pretty much anything (with maybe the exception of hand
written pipelined code that is designed to sit in the L1 cache of a
single processor but how many of us have that).
In terms of general 'integer' computing power however, I dont really
think GCC or NetBSD/arm32 or anything is that bad.
Of course if you want me to go about the architectural inadequancies of
the Celeron, feel free to email me personally or any of the non-i386
mailing list (or hey even the i386 ones).
As for the "barely working" nature of NetBSD/arm32, I can assure you that
a lot of us do NOT feel that way, and those that might have, have worked
long and hard to help fix it.
Sorry, 2 rant of the week over.
Paul
kim@pvv.ntnu.no wrote:
> > Can anyone explain to me why the Strongarm takes so much
> > longer than the Pentium to run this code? Surely it should
> > run in the same range, if not faster. By the way, the
> > Pentium II 266 version was only compiled with the -m486
> > option, so no special PII optimization was used...
>
> It is because of the pitiful pessimizer of GCC.
>
> I encountered the same problem when I worked with partial
> differential equations with finite difference methods.
>
> The StrongARM has a beautiful pipelined structure, which makes
> it possible to execute an instruction every clockcycle, even when
> the instruction takes several clockcycles, such as memory access
> and multiplication. To achieve this high speed, one can let the
> processor do other instructions while the slower instructions
> complete.
>
> GCC makes the worst out of this. It typically puts instructions
> depending on the slow instructions immediately after the slow
> instructions in the code, even when it is not necessary.
>
> It has always been that way, and I guess it will continue to be like
> that, just like NetBSD ARM32 always has been barely working and quite
> uncompilable. I am now the happily owner of a Linux twin Celeron
> system. The reason I still read this maillist is that my unsubscribe
> request did not work.
>
> Kim0
--
.----------------------------------------------------------------------.
| Paul Wain || Tel: +1 650 631 GOAT (4628) |
| Network Computer Inc. || Web: http://www.nc.com/ |
| Redwood Shores, CA 94040 || |
`----------------------------------------------------------------------'
--------------02AD028ACC1D03CB05A67FED
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
You know I feel this is a <b>lot</b> unfair, espically on Mark.
<p>I have <b>never</b> had any problems with any of my machines, be it
a RiscPC, A7000, Acorn NC or Shark, getting NetBSD working and/or compiling.
I know I didnt have SCSI based machines, or machines with anything but
Ant ethernet cards (with the exception of the Shark),or strange set ups,
but at one time I had a <b>lot</b> of machines running.
<p>And <i>appart from the startup time</i> of Netscape 3.x/4.x on the RiscPC
700, I can never really say performance sucked (okay there were some issues
with DEC on the compiler when we were doing shared libraries but even so
that was one off initialization code)....
<p>And a dual processor P400 running a SMP kernel is going to out perform
a 233Mhz SA110 on pretty much anything (with maybe the exception of hand
written pipelined code that is designed to sit in the L1 cache of a single
processor but how many of us have that).
<p>In terms of general 'integer' computing power however, I dont really
think GCC or NetBSD/arm32 or anything is <b>that</b> bad.
<p>Of course if you want me to go about the architectural inadequancies
of the Celeron, feel free to email me personally or any of the non-i386
mailing list (or hey even the i386 ones).
<p>As for the "barely working" nature of NetBSD/arm32, I can assure you
that a lot of us do <b><i>NOT</i></b> feel that way, and those that might
have, have worked long and hard to help fix it.
<p>Sorry, 2 rant of the week over.
<p>Paul
<br>
<p>kim@pvv.ntnu.no wrote:
<blockquote TYPE=CITE>> Can anyone explain to me why the Strongarm takes
so much
<br>> longer than the Pentium to run this code? Surely it should
<br>> run in the same range, if not faster. By the way, the
<br>> Pentium II 266 version was only compiled with the -m486
<br>> option, so no special PII optimization was used...
<p>It is because of the pitiful pessimizer of GCC.
<p>I encountered the same problem when I worked with partial
<br>differential equations with finite difference methods.
<p>The StrongARM has a beautiful pipelined structure, which makes
<br>it possible to execute an instruction every clockcycle, even when
<br>the instruction takes several clockcycles, such as memory access
<br>and multiplication. To achieve this high speed, one can let the
<br>processor do other instructions while the slower instructions
<br>complete.
<p>GCC makes the worst out of this. It typically puts instructions
<br>depending on the slow instructions immediately after the slow
<br>instructions in the code, even when it is not necessary.
<p>It has always been that way, and I guess it will continue to be like
<br>that, just like NetBSD ARM32 always has been barely working and quite
<br>uncompilable. I am now the happily owner of a Linux twin Celeron
<br>system. The reason I still read this maillist is that my unsubscribe
<br>request did not work.
<p>Kim0</blockquote>
--
<br>.----------------------------------------------------------------------.
<br>| Paul Wain
|| Tel: +1 650 631 GOAT (4628) |
<br>| Network Computer Inc.
|| Web: <a href="http://www.nc.com/">http://www.nc.com/</a>
|
<br>| Redwood Shores, CA 94040
||
|
<br>`----------------------------------------------------------------------'
<br> </html>
--------------02AD028ACC1D03CB05A67FED--