Re: CVS Update@linux-mips.org: linux

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Fri, Jul 08, 2005 at 10:17:05AM +0100, ths@linux-mips.org wrote:

> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ths@ftp.linux-mips.org	05/07/08 10:17:05
> 
> Modified files:
> 	include/asm-mips: checksum.h 
> 
> Log message:
> 	Protect noat assembly with .set push/pop and make it somewhat readable.

It doesn't need protction.

 Ralf

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Fri, 8 Jul 2005, Ralf Baechle wrote:

> > Log message:
> > 	Protect noat assembly with .set push/pop and make it somewhat readable.
> 
> It doesn't need protction.

 Are you absolutely sure future versions of GCC won't default to ".set 
noat" for inline asm?  I am not; in fact the opposite is not unlikely.

  Maciej

Re: CVS Update@linux-mips.org: linux

[Richard Sandiford]

"Maciej W. Rozycki" <macro@linux-mips.org> writes:
> On Fri, 8 Jul 2005, Ralf Baechle wrote:
>> > Log message:
>> > 	Protect noat assembly with .set push/pop and make it somewhat readable.
>> 
>> It doesn't need protction.
>
>  Are you absolutely sure future versions of GCC won't default to ".set 
> noat" for inline asm?

Yes ;)  All hell would break loose otherwise. ;)

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Fri, Jul 08, 2005 at 01:12:55PM +0100, Maciej W. Rozycki wrote:

> > > 	Protect noat assembly with .set push/pop and make it somewhat readable.
> > 
> > It doesn't need protction.
> 
>  Are you absolutely sure future versions of GCC won't default to ".set 
> noat" for inline asm?  I am not; in fact the opposite is not unlikely.

Indeed - but everybody is free to shoot himself into the foot.  With
uzis even.  Does that make it a good idea?

  Ralf

Benchmarking RM9000

[Alex Gonzalez]

Hi,

I am doing some basic benchmarking tests on our RM9000 based platform,
running on just one of the two cores (non-smp kernel).

I would be very interesting in seeing some comparative data as we seem
to experience some performance problems.

Even if no data is available, any comments on this results will also be
appreciated.

Thanks,
Alex

----------------------------------------------------

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
                                                                                                                                                       
TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          360.48  :       9.24  :       3.04
STRING SORT         :           31.23  :      13.95  :       2.16
BITFIELD            :      8.4132e+07  :      14.43  :       3.01
FP EMULATION        :          32.921  :      15.80  :       3.65
FOURIER             :            3383  :       3.85  :       2.16
ASSIGNMENT          :          4.2422  :      16.14  :       4.19
IDEA                :          1543.3  :      23.60  :       7.01
HUFFMAN             :          382.56  :      10.61  :       3.39
NEURAL NET          :          3.7153  :       5.97  :       2.51
LU DECOMPOSITION    :          209.28  :      10.84  :       7.83
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 14.242
FLOATING-POINT INDEX: 6.291
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 :
L2 Cache            :
OS                  : Linux 2.6.12-rc3
C compiler          : gcc version 3.3.5
libc                : libc-2.3.5.so
MEMORY INDEX        : 3.010
INTEGER INDEX       : 4.026
FLOATING-POINT INDEX: 3.489
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

Re: Benchmarking RM9000

[Laurence Darby]

Alex Gonzalez wrote:

> Hi,
> 
> I am doing some basic benchmarking tests on our RM9000 based platform,
> running on just one of the two cores (non-smp kernel).

<snip>

> TEST                : Iterations/sec.  : Old Index   : New Index
>                     :                  : Pentium 90* : AMD K6/233*
> --------------------:------------------:-------------:------------>
> NUMERIC SORT        :          360.48  :       9.24  :       3.04


I'd expect a K6 to be able to do more Iterations per second than a
Pentium 90, not fewer. 


Laurence

Re: Benchmarking RM9000

[Alex Gonzalez]

The performance of our video application is well below our expectations.
We are still doing some profiling work on it, but we are also looking at
other possibilities.

What other benchmarking tool would you recommend?

Currently it's a NFS mounted system, but even if we could use a block
device the access speed wouldn't be more than 1.5 Mbps, so that is a
limitation for the benchmark.

Alex

On Fri, 2005-07-08 at 14:01, Ralf Baechle wrote:
> On Fri, Jul 08, 2005 at 01:25:49PM +0100, Alex Gonzalez wrote:
> 
> > I am doing some basic benchmarking tests on our RM9000 based platform,
> > running on just one of the two cores (non-smp kernel).
> > 
> > I would be very interesting in seeing some comparative data as we seem
> > to experience some performance problems.
> 
> What exactly are those performance issues?
> 
> If I recall right how to read bytebench numbers, your Bytebench numbers
> are look roughly ok, at least in first approximation.  That benchmark
> has become uncommon so I don't have any numbers at hand to compare with.
> 
>   Ralf

Re: Benchmarking RM9000

[Ralf Baechle]

On Fri, Jul 08, 2005 at 03:42:29PM +0100, Alex Gonzalez wrote:

> The performance of our video application is well below our expectations.
> We are still doing some profiling work on it, but we are also looking at
> other possibilities.
> 
> What other benchmarking tool would you recommend?
> 
> Currently it's a NFS mounted system, but even if we could use a block
> device the access speed wouldn't be more than 1.5 Mbps, so that is a
> limitation for the benchmark.

As a shot into the dark ...

Make sure you exploit the RM9000's write-gathering capabilities when
writing into the frame buffer.  If the frame buffer happens to be on
a PCI device you're probably performing uncached writes which will
slow down the thing to a crawl.

  Ralf

Re: Benchmarking RM9000

[Alex Gonzalez]

Thanks for all the feedback.

I enclose new results from the lmbench testing.

Answering some suggestions,

I won't use gmplayer as a benchmarking tool. The platform has no
graphics adapter. We're developing a streaming video application in an
embedded platform (no hdd either).

I'll check that the driver is using the write-gather functionality to
move data from/to the ethernet adapter.

As before, I'd appreciate some other results from modern systems to
compare with.

Regards,
Alex

-------------------------------------------------


 
                 L M B E N C H  3 . 0   S U M M A R Y
                 ------------------------------------
                 (Alpha software, do not distribute)
 
Basic system parameters
------------------------------------------------------------------------------
Host                 OS Description              Mhz  tlb  cache  mem   scal
                                                     pages line   par   load
                                                           bytes
--------- ------------- ----------------------- ---- ----- ----- ------ ----
192.168.1 Linux 2.6.12-          mips-linux-gnu  985     4    32 1.4200    1
 
Processor, Processes - times in microseconds - smaller is better
------------------------------------------------------------------------------
Host                 OS  Mhz null null      open slct sig  sig  fork exec sh
                             call  I/O stat clos TCP  inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
192.168.1 Linux 2.6.12-  985 0.19 0.49 4.29 150. 25.4 0.65 3.76 828. 5032 16.K
 
Basic integer operations - times in nanoseconds - smaller is better
-------------------------------------------------------------------
Host                 OS  intgr intgr  intgr  intgr  intgr
                          bit   add    mul    div    mod
--------- ------------- ------ ------ ------ ------ ------
192.168.1 Linux 2.6.12- 1.0200 1.0200 4.1500   43.5   41.5
 
Basic float operations - times in nanoseconds - smaller is better
-----------------------------------------------------------------
Host                 OS  float  float  float  float
                         add    mul    div    bogo
--------- ------------- ------ ------ ------ ------
192.168.1 Linux 2.6.12- 6.0700 6.0700   22.3   41.7
 
Basic double operations - times in nanoseconds - smaller is better
------------------------------------------------------------------
Host                 OS  double double double double
                         add    mul    div    bogo
--------- ------------- ------  ------ ------ ------
192.168.1 Linux 2.6.12- 6.0700 9.1100   37.4   62.0
 
Context switching - times in microseconds - smaller is better
-------------------------------------------------------------------------
Host                 OS  2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
                         ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
--------- ------------- ------ ------ ------ ------ ------ ------- -------
192.168.1 Linux 2.6.12- 0.8400 5.6600 8.2600   22.6  235.2    58.9   242.3
 
*Local* Communication latencies in microseconds - smaller is better
---------------------------------------------------------------------
Host                 OS 2p/0K  Pipe AF     UDP  RPC/   TCP  RPC/ TCP
                        ctxsw       UNIX         UDP         TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
192.168.1 Linux 2.6.12- 0.840 6.775 13.4              38.0       143.
                                                                                                                                                       
File & VM system latencies in microseconds - smaller is better
-------------------------------------------------------------------------------
Host                 OS   0K File      10K File     Mmap    Prot   Page   100fd
                        Create Delete Create Delete Latency Fault  Fault  selct
--------- ------------- ------ ------ ------ ------ ------- ----- ------- -----
192.168.1 Linux 2.6.12-                              4926.0 0.622 2.59860  16.6
                                                                                                                                                       
*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------------------------
Host                OS  Pipe AF    TCP  File   Mmap  Bcopy  Bcopy  Mem   Mem
                             UNIX      reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
192.168.1 Linux 2.6.12- 141. 292. 57.2  140.5  224.7   97.1   88.2 224. 155.4
                                                                                                                                                       
Memory latencies in nanoseconds - smaller is better
    (WARNING - may not be correct, check graphs)
------------------------------------------------------------------------------
Host                 OS   Mhz   L1 $   L2 $    Main mem    Rand mem    Guesses
--------- -------------   ---   ----   ----    --------    --------    -------
192.168.1 Linux 2.6.12-   985 3.0750   45.4  109.5       254.9



On Mon, 2005-07-11 at 00:14, Ralf Baechle wrote:
> On Fri, Jul 08, 2005 at 03:42:29PM +0100, Alex Gonzalez wrote:
> 
> > The performance of our video application is well below our expectations.
> > We are still doing some profiling work on it, but we are also looking at
> > other possibilities.
> > 
> > What other benchmarking tool would you recommend?
> > 
> > Currently it's a NFS mounted system, but even if we could use a block
> > device the access speed wouldn't be more than 1.5 Mbps, so that is a
> > limitation for the benchmark.
> 
> As a shot into the dark ...
> 
> Make sure you exploit the RM9000's write-gathering capabilities when
> writing into the frame buffer.  If the frame buffer happens to be on
> a PCI device you're probably performing uncached writes which will
> slow down the thing to a crawl.
> 
>   Ralf

Re: Benchmarking RM9000

[Ralf Rösch]

>As before, I'd appreciate some other results from modern systems to
>compare with.
>
>  
>
Alex, below you can find our LMBENCH 3.0-a4 test results. 
Our machine is a Toshiba TX4937 based system (in the hope "modern enough") running with 
333MHz CPU-Clock and 133 MHz SDRAM-Clock (64bit).
The bench was run on the Debian based mipsel-distribution.
I'm surprised about the big difference in test results compared to your RM9000 system.
I would expect that your system should be much faster and I think there must be
a blocking part (hardware, software)  in your system. 

Regards
  Ralf (Roesch)

                 L M B E N C H  3 . 0   S U M M A R Y

                 ------------------------------------

         (Alpha software, do not distribute)

Basic system parameters
------------------------------------------------------------------------------
Host                 OS Description              Mhz  tlb  cache  mem   scal
                                                     pages line   par   load
                                                           bytes  
--------- ------------- ----------------------- ---- ----- ----- ------ ----
debian-mi  Linux 2.6.12        mipsel-linux-gnu  326     4    32 1.0700    1

Processor, Processes - times in microseconds - smaller is better
------------------------------------------------------------------------------
Host                 OS  Mhz null null      open slct sig  sig  fork exec sh  
                             call  I/O stat clos TCP  inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
debian-mi  Linux 2.6.12  326 0.41 1.22 8.37 9.96 78.1 1.85 7.77 1437 8018 36.K

Basic integer operations - times in nanoseconds - smaller is better
-------------------------------------------------------------------
Host                 OS  intgr intgr  intgr  intgr  intgr  
                          bit   add    mul    div    mod   
--------- ------------- ------ ------ ------ ------ ------ 
debian-mi  Linux 2.6.12 3.0600 0.0500   18.3  122.4  124.8

Basic float operations - times in nanoseconds - smaller is better
-----------------------------------------------------------------
Host                 OS  float  float  float  float
                         add    mul    div    bogo
--------- ------------- ------ ------ ------ ------ 
debian-mi  Linux 2.6.12   15.6   15.1   64.9  126.7

Basic double operations - times in nanoseconds - smaller is better
------------------------------------------------------------------
Host                 OS  double double double double
                         add    mul    div    bogo
--------- ------------- ------  ------ ------ ------ 
debian-mi  Linux 2.6.12   24.7   24.2  106.5  217.8

Context switching - times in microseconds - smaller is better
-------------------------------------------------------------------------
Host                 OS  2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
                         ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
--------- ------------- ------ ------ ------ ------ ------ ------- -------
debian-mi  Linux 2.6.12 1.1100   29.8   28.4   71.2   18.6    70.2    24.5

*Local* Communication latencies in microseconds - smaller is better
---------------------------------------------------------------------
Host                 OS 2p/0K  Pipe AF     UDP  RPC/   TCP  RPC/ TCP
                        ctxsw       UNIX         UDP         TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
debian-mi  Linux 2.6.12 1.110  16.4 35.3  73.8 205.7 146.8 313.1 560.

File & VM system latencies in microseconds - smaller is better
-------------------------------------------------------------------------------
Host                 OS   0K File      10K File     Mmap    Prot   Page   100fd
                        Create Delete Create Delete Latency Fault  Fault  selct
--------- ------------- ------ ------ ------ ------ ------- ----- ------- -----
debian-mi  Linux 2.6.12  252.1  349.2  753.6  536.2   69.0K 1.830 5.18150  44.3

*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------------------------
Host                OS  Pipe AF    TCP  File   Mmap  Bcopy  Bcopy  Mem   Mem
                             UNIX      reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
debian-mi  Linux 2.6.12 41.0 42.0 36.5   55.7  166.1   89.8   89.0 166. 153.4

Memory latencies in nanoseconds - smaller is better
    (WARNING - may not be correct, check graphs)
------------------------------------------------------------------------------
Host                 OS   Mhz   L1 $   L2 $    Main mem    Rand mem    Guesses
--------- -------------   ---   ----   ----    --------    --------    -------
debian-mi  Linux 2.6.12   326 6.3470  125.0  127.1       302.4    No L2 cache?

Re: Benchmarking RM9000

[Laurence Darby]

Alex Gonzalez wrote:

> The performance of our video application is well below our
> expectations. We are still doing some profiling work on it, but we
> are also looking at other possibilities.
> 
> What other benchmarking tool would you recommend?


There's lmbench, available only from 
http://ftp.debian.org/debian/pool/non-free/l/lmbench/lmbench_2.0-patch2.orig.tar.gz
(the debian package itself doesn't work, and its main ftp site seems to
be down)

glxgears is nice and simple for 3d bmarks.

mplayer may be useful with its -benchmark option. Its docs, though
mostly x86 specific, are still interesting for video performance
issues.


Laurence

Re: Benchmarking RM9000

[Dominik 'Rathann' Mierzejewski]

On Mon, Jul 11, 2005 at 12:09:59PM +0100, Laurence Darby wrote:
> Alex Gonzalez wrote:
> 
> > The performance of our video application is well below our
> > expectations. We are still doing some profiling work on it, but we
> > are also looking at other possibilities.
> > 
> > What other benchmarking tool would you recommend?
[...] 
> mplayer may be useful with its -benchmark option. Its docs, though
> mostly x86 specific, are still interesting for video performance
> issues.

If you do use mplayer, please send all useful feedback to
mplayer-users at mplayerhq.hu, too, please.

We (MPlayer team) are always interested in mplayer operation on other
architectures.

Regards,
R.

-- 
Dominik 'Rathann' Mierzejewski <rathann*at*icm.edu.pl>
Interdisciplinary Centre for Mathematical and Computational Modelling
Warsaw University  |  http://www.icm.edu.pl  |  tel. +48 (22) 5540810

Re: Benchmarking RM9000

[Alex Gonzalez]

My understanding of these numbers is that they all refer to the target
under test.

So for that specific test, the target is 9.24 times quicker than a base
Pentium 90 and 3.04 times quicker than a AMD K6.

That makes the AMD three times quicker than the Pentium 90.

But then, I might have been trying to make sense of the numbers as it is
not clear enough in the documentation.

Alex

On Fri, 2005-07-08 at 14:54, Laurence Darby wrote:
> Alex Gonzalez wrote:
> 
> > Hi,
> > 
> > I am doing some basic benchmarking tests on our RM9000 based platform,
> > running on just one of the two cores (non-smp kernel).
> 
> <snip>
> 
> > TEST                : Iterations/sec.  : Old Index   : New Index
> >                     :                  : Pentium 90* : AMD K6/233*
> > --------------------:------------------:-------------:------------>
> > NUMERIC SORT        :          360.48  :       9.24  :       3.04
> 
> 
> I'd expect a K6 to be able to do more Iterations per second than a
> Pentium 90, not fewer. 
> 
> 
> Laurence