[I am really annoyed hence a provocative title and people will than do
their best to convince me that I am silly; I hope so]

Is it a joke, or just a nightmare? As a side note: I am not using
computers for surfing the net or playing on it. My typical
calculations (radiative transfer through the atmosphere and aerosols)
take 2 weeks on workstations. I am not saying that I am going to use
the ibook for that, but note the following:

ibook: G4 800 MHz, 640 MB RAM, L2 256
laptop: Celeron 1000 MHz, 256 MB RAM, L2 128 K (Linux SuSE 8)
stationary: Pentium PII 450 MHz, 196 MB RAM, L2 512 K, (Linux SuSE 8)

512x512 Matrix-matrix multiplication in C (g++ -O3 bench.c):

- ibook (800 MHz G4), gcc 3.3: 26 sec
- laptop (1000 MHz Celeron), gcc 2.9x: 20 sec
- stationary (450 MHz PII), gcc 2.9x: 20 sec

So, accounting for row indices (in C index runs row after row as
opposed to Fortran):

- ibook (800 MHz G4): 4 sec
- laptop (1000 MHz Celeron): 8.5 sec
- stationary (450 MHz PII): 3.8 sec !!!!!!!!!!!!!!!!!!!!!!!!!

I tried to get some hints on optimizations tailored for the G4 (man
g++), but no luck.

Is it just nepping customers? Or just: am I plain silly. Maybe Lord
hates me.

Okay, I haven't access to a stationary G4 800 MHz processor and 800
MHZ Pentium 3 or 4.

The PII is about 300 years old.

So my ibook is a few days old. If I am lucky I will find an idiot to
whom I can sell it without any financial overhead.

Or what is your stance of the affair? There must be a reason that one
of the third best "supercomputers" consits of G5 processors - right? I
saw a demo of that the other day?

When my decision felt on the ibook I was intrigued by the following
account:

http://www.visionengineer.com/tech/ibook_page3.shtml

Good, it is Fortran but what the hell ...

Fensterbrett

In article <f7afbb21.0403050029.61997563@posting.google.com>,
chain_lube@hotmail.com wrote:

That could have something to do with it.

Cheers,

Bob S

chain_lube@hotmail.com wrote:



One thing this shows: MHz isn't everything. :-)

I suspect gcc has some ia32 optimizations in it that your
test is using (something with MMX or SSE), but it goes
have anything for the PPC's "Altivec" instructions, which
are the moral equivalent.

Can you post bench.c? I have an Athlon, a VIA, a Xeon and
an UltraSPARC I could give it a shot on. That would be everything. :-)

Duke

n Beitrag DZWdnYgvL9NvBNXdRVn-vA@io.com schrieb Duke Robillard unter
duke@NOSPAMio.com am 05.03.2004 16:18 Uhr:


I am well aware that MHZ is not everything. I bought the ibook simply out of
"friendship" to apple and because I like their embracing of Unix and BSD. I
am not a Unix guy, but I felt better when supporting a company, because
sometimes I went sour of all that "open source" zealots. Btw: I am a PhD
student in physics. And Btw: that message is typed and consigned from the
ibook (connecting to the internet was easy, though):



The following has been simply pinched from the language shootout page. I am
not a versed C programmer. I have also a C++ version which relies on the
vector class and the behavior is the same.

NOTE: I use mostly Bigloo for scientific computing. And to my great surprise
the Bigloo code is on the ibook 2 times faster than the same code on the
stationary machine. That is a bit surprising, because the Scheme (bigloo)
compiler produces a.out's which are more or less ANSI C. BUT as I wrote if I
use a simple native C version (see below) then that C version performs much
better on the 450 MHz P2.

Use it as follows:

g++ -faltivec -fast -O3 bench.cpp


I do not think that a pure C version based on gcc instead of g++ (lets say
without "cout" will be faster).

I must honestly say I have never used any matrix matrix multiplication in my
life (at least not conciously), but it gives a quick hint on performance.

NOTE: The version is not correct, because one should transpose the second
array, but that does not matter yet.

==
#include <iostream>
#include <stdlib.h>


using namespace std;

double **mkmatrix(int rows, int cols) {
int i, j, count =1;
double **m = (double**)malloc(rows * sizeof(double*));
for (i=0; i<rows; i++) {
m[i] = (double*)malloc(cols*sizeof(double));
for (j=0;j<cols;j++){
m[i][j] = count++;
}
}
return(m);
}

void zeromatrix(int rows, int cols, double **m) {
int i,j;
for (i=0; i<rows;i++)
for (j=0;j<cols;j++)
m[i][j]=0;}


void freematrix(int rows, double **m) {
while (--rows > -1) {free(m[rows]);}
free(m);}

double **mmult(int rows, int cols, double **m1, double **m2, double **m3) {
int i,j,k;
double val;
for (i=0; i<rows;i++){
for (j=0;j<cols;j++){
val = double(0.0);
for (k=0; k<cols; k++){
val += m1[i][k] * m3[j][k];
}
m3[i][j]=val;
}}return(m3);}

int main() {
int i, SIZE=512;

double **m1 = mkmatrix(SIZE, SIZE);
double **m2 = mkmatrix(SIZE, SIZE);
double **mm = mkmatrix(SIZE, SIZE);

mm = mmult(SIZE,SIZE, m1, m2,mm);

//cout << mm[0][0] << endl;

freematrix(SIZE,m1);
freematrix(SIZE,m2);
freematrix(SIZE,mm);
return(0);
}>
==

Enclosed also a C++ version. I haven't written more than 10 C++ programs in
my life; I just wanted to check whether it is possible to "simulate" a bit
Scheme style programming.

==
#include <iostream>
#include <vector>

using namespace std;

vector<vector<double> > mkmatrix(int rows, int cols)
{
double count=double(1.0);
vector<vector<double> > m(rows,cols);
for(int i=0; i<rows; i++)
{
for(int j=0; j<cols; j++)
{
m[i][j]=count;
count += 1.0;
}
}
return(m);
}

vector<double> mkvector(int cols)
{
vector<double> erg;
double val = double(0.0);

for(int i=0; i<cols; i++)
{
erg.push_back(val);
}
return(erg);
}


vector<vector<double> > mmult(int rows, int cols, vector<vector<double> >
m1, vector<vector<double> > m2)
{
double val;
vector<vector<double> > m3(rows,cols);
for(int i=0; i<rows; i++)
{
vector<double> m1i = m1[i];
vector<double> row(cols);

for(int j=0; j<rows; j++)
{
val = double(0.0);
for(int k=0; k<cols; k++)
{
val += m1i[k] * m2[j][k];
}
row[j] = val;
}
m3[i]=row;
}
return(m3);
}

int main()
{
int SIZE=512;

vector<vector<double> > m1 = mkmatrix(SIZE,SIZE);
vector<vector<double> > m2 = mkmatrix(SIZE,SIZE);
vector<vector<double> > mm = mmult(SIZE,SIZE,m1,m2);

cout << mm[0][0] << " " << mm[4][4] << endl;

return(0);
}
==

Fensterbrett

n Beitrag DZWdnYgvL9NvBNXdRVn-vA@io.com schrieb Duke Robillard unter
duke@NOSPAMio.com am 05.03.2004 16:18 Uhr:


I am well aware that MHZ is not everything. I bought the ibook simply out of
"friendship" to apple and because I like their embracing of Unix and BSD. I
am not a Unix guy, but I felt better when supporting a company, because
sometimes I went sour of all that "open source" zealots. Btw: I am a PhD
student in physics. And Btw: that message is typed and consigned from the
ibook (connecting to the internet was easy, though):



The following has been simply pinched from the language shootout page. I am
not a versed C programmer. I have also a C++ version which relies on the
vector class and the behavior is the same.

NOTE: I use mostly Bigloo for scientific computing. And to my great surprise
the Bigloo code is on the ibook 2 times faster than the same code on the
stationary machine. That is a bit surprising, because the Scheme (bigloo)
compiler produce a.out's which are more or less ANSI C. BUT as I wrote if I
use a simple C version (see below) then that C version performs much better
on the 450 MHz P2.

Use it as follows:

g++ -faltivec -fast -O3 bench.cpp


I do not think that a pure C version based on gcc instead of g++ (lets say
without "cout" will be faster).

I must honestly say I have never used any matrix matrix multiplication in my
life (at least not conciously), but it gives a quick hint on performance.

NOTE: The version is not correct, because one should transpose the second
array, but that does not matter yet.

==
#include <iostream>
#include <stdlib.h>


using namespace std;

double **mkmatrix(int rows, int cols) {
int i, j, count =1;
double **m = (double**)malloc(rows * sizeof(double*));
for (i=0; i<rows; i++) {
m[i] = (double*)malloc(cols*sizeof(double));
for (j=0;j<cols;j++){
m[i][j] = count++;
}
}
return(m);
}

void zeromatrix(int rows, int cols, double **m) {
int i,j;
for (i=0; i<rows;i++)
for (j=0;j<cols;j++)
m[i][j]=0;}


void freematrix(int rows, double **m) {
while (--rows > -1) {free(m[rows]);}
free(m);}

double **mmult(int rows, int cols, double **m1, double **m2, double **m3) {
int i,j,k;
double val;
for (i=0; i<rows;i++){
for (j=0;j<cols;j++){
val = double(0.0);
for (k=0; k<cols; k++){
val += m1[i][k] * m3[j][k];
}
m3[i][j]=val;
}}return(m3);}

int main() {
int i, SIZE=512;

double **m1 = mkmatrix(SIZE, SIZE);
double **m2 = mkmatrix(SIZE, SIZE);
double **mm = mkmatrix(SIZE, SIZE);

mm = mmult(SIZE,SIZE, m1, m2,mm);

//cout << mm[0][0] << endl;

freematrix(SIZE,m1);
freematrix(SIZE,m2);
freematrix(SIZE,mm);
return(0);
}>
==

Enclosed also a C++ version. I haven't written more than 10 C++ programs in
my life; I just wanted to check whether it is possible to "simulate" a bit
Scheme style programming.

==
#include <iostream>
#include <vector>

using namespace std;

vector<vector<double> > mkmatrix(int rows, int cols)
{
double count=double(1.0);
vector<vector<double> > m(rows,cols);
for(int i=0; i<rows; i++)
{
for(int j=0; j<cols; j++)
{
m[i][j]=count;
count += 1.0;
}
}
return(m);
}

vector<double> mkvector(int cols)
{
vector<double> erg;
double val = double(0.0);

for(int i=0; i<cols; i++)
{
erg.push_back(val);
}
return(erg);
}


vector<vector<double> > mmult(int rows, int cols, vector<vector<double> >
m1, vector<vector<double> > m2)
{
double val;
vector<vector<double> > m3(rows,cols);
for(int i=0; i<rows; i++)
{
vector<double> m1i = m1[i];
vector<double> row(cols);

for(int j=0; j<rows; j++)
{
val = double(0.0);
for(int k=0; k<cols; k++)
{
val += m1i[k] * m2[j][k];
}
row[j] = val;
}
m3[i]=row;
}
return(m3);
}

int main()
{
int SIZE=512;

vector<vector<double> > m1 = mkmatrix(SIZE,SIZE);
vector<vector<double> > m2 = mkmatrix(SIZE,SIZE);
vector<vector<double> > mm = mmult(SIZE,SIZE,m1,m2);

cout << mm[0][0] << " " << mm[4][4] << endl;

return(0);
}
==

Fensterbrett

Siegfried Gonzi <siegfried.gonzi@stud.uni-graz.at> wrote:

I haven't had the time to look at the code and see what it _actually_
does, but...

The bench.c code, compiled on a 1GHz/512MB Powerbook 17(rev 1) with
OS 10.2.8 GCC version 1175, based on gcc version 3.1 20020420 (prerelease)

Compiled with:

g++ -faltivec -O3 bench.c
(the -fast is not recognized)

Gives these results:

% /usr/bin/time ./a.out
6.17 real 3.83 user 0.18 sys

-Josh
--

Hypnotoad will crush Fiestacat in the November election.

Siegfried Gonzi wrote:

Sorry, I didn't mean to imply you weren't aware of it...I just wanted
to make a cute remark about a subject that comes up here a lot.

My results (gcc -O3 on all of them)

Athlon XP 2000 (1.2 Ghz), Slackware Linux, Kernel 2.4.22:
bash-2.05b$ time ./a.out

real 0m2.345s
user 0m2.310s
sys 0m0.040s

900 Mhz VIA Ezra, RedHat Linux, Kernel 2.4.20-30.9

$ time ./a.out

real 0m6.851s
user 0m6.590s
sys 0m0.060s

Dual 900Mhz UltraSPARC-III+, Solaris 2.8
$ time ./a.out

real 0m2.71s
user 0m2.67s
sys 0m0.03s

I couldn't run it on the Xeon; it's heavily loaded with real
work right now. :-) I'll check back later. I've also got
a faster Athlon I'll try it on.


So, to sum up:

- Athlon XP 2000 (1.2 Ghz): 2.3 sec
- 900 Mhz VIA Ezra: 6.8 sec
- Dual 900Mhz UltraSPARC-III+: 2.7 sec
- 1GHz Powerbook: 6.2 sec
- ibook (800 MHz G4): 4 sec
- laptop (1000 MHz Celeron): 8.5 sec
- stationary (450 MHz PII): 3.8 sec !!!!!!!!!!!!!!!!!!!!!!!!!


Those are some confusing results there.

It looks like ia32's, and in particular, Athlons, kick PPC butt
on this benchmark. Except for the Celeron. Well, and the VIA,
which is clocked higher than the iBook, but took > 50% longer.

But hmm...why is the ibook faster than the Powerbook? Something's
up.


Duke

Duke Robillard wrote:

Hang on, is it cache size? Each matrix is 3MB...the VIA has a 64KB
Cache, the Athlon has a 256MB cache. I think the old PII had a 512KB
cache, didn't it? External to the CPU, on that card that went into
the slot?

What are the caches on the PPCs?

Duke

Duke Robillard wrote:

Hang on, is it cache size? Each matrix is 3MB...the VIA has a 64KB
Cache, the Athlon has a 256MB cache. I think the old PII had a 512KB
cache, didn't it? External to the CPU, on that card that went into
the slot?

What are the caches on the PPCs?

Duke

Looking at the Panther man pages g++ is gcc.

The reason for the differnece is the compiler. The C code posted
compiled with Metrowerks CodeWarrior 8.0, takes less than 7
seconds to complete once loaded on my 350 MHz G3.

gcc is a SLOW compiler and produces SLOW executables.

The current best compiler is IBMs xlc for Xcode. It typically
produces code of 30 - 250% better performace.

Don't blame the iBook it's an exceptable performer given good
code.

The problems is providing good code.

Siegfried Gonzi <siegfried.gonzi@stud.uni-graz.at> wrote:


This is on a G5 1.6GHz(single), 256MB, with
gcc version 3.3 20030304 (Apple Computer, Inc. build 1495)

The -fast flag seems to be supported now.

Note: on the 10.2.8 Powerbook, a.out was 352440 bytes.

% g++ -faltivec -O3 bench.c
% /usr/bin/time ./a.out
0.92 real 0.79 user 0.01 sys
a.out is 668648 bytes.

% g++ -fast -faltivec -O3 bench.c
% /usr/bin/time ./a.out
0.82 real 0.77 user 0.01 sys
a.out is 668656 bytes.

-Josh
--

Hypnotoad will crush Fiestacat in the November election.

Joshua Hesse <jhesse@bigred.unl.edu> wrote:
FWIW, I ftp'd the a.out compiled on the G5/10.3 computer to the G4 PB.
Note: The Powerbook has a 256KB L2 AND 1MB L3
Here's the result of running that binary:
(I ran this several times, since that's the proper way to do it)

% /usr/bin/time ./a.out
5.69 real 3.37 user 0.09 sys
% /usr/bin/time ./a.out
5.55 real 3.09 user 0.07 sys
% /usr/bin/time ./a.out
5.38 real 3.57 user 0.09 sys
% /usr/bin/time ./a.out
5.34 real 3.62 user 0.12 sys
% /usr/bin/time ./a.out
5.69 real 2.95 user 0.07 sys

So, g++ 3.3 definitly produces a faster binary than 3.1, nothing is being
compiled that isn't G4 incompatable.

Now to run this same binary on a 20-inch iMac G4 1.25GHz, 256MB, 256KB L2
OS 10.3.2:

$ /usr/bin/time ./a.out
4.84 real 2.79 user 0.02 sys
$ /usr/bin/time ./a.out
3.75 real 2.86 user 0.05 sys
$ /usr/bin/time ./a.out
3.67 real 2.81 user 0.03 sys
$ /usr/bin/time ./a.out
5.31 real 2.79 user 0.05 sys

-Josh

--

Hypnotoad will crush Fiestacat in the November election.

Whoops. I forgot I was running a screensaver as the desktop
on the powerbook.

With the screensaver running:
% /usr/bin/time ./a.out
6.27 real 3.45 user 0.25 sys
% /usr/bin/time ./a.out
5.87 real 3.58 user 0.18 sys
% /usr/bin/time ./a.out
6.19 real 3.47 user 0.14 sys

Without the screensaver:
% /usr/bin/time ./a.out
3.99 real 3.32 user 0.07 sys
% /usr/bin/time ./a.out
3.95 real 3.28 user 0.07 sys
% /usr/bin/time ./a.out
3.88 real 3.34 user 0.08 sys
% /usr/bin/time ./a.out
3.87 real 3.34 user 0.05 sys


-Josh

--

Hypnotoad will crush Fiestacat in the November election.

In article <BC6E60C9.35C%siegfried.gonzi@stud.uni-graz.at>, Siegfried Gonzi
wrote:
This is especially true for laptops. A laptop running at a given processor
speed is usually slower than a desktop using the same processor at the same
speed, because there is more to system speed than just processor speed.

In a laptop, the designers are much more concerned about power consumption
than in a desktop, and also are very concerned about heat production, and so
many things might be slower than they would be on a desktop, in order to
reduce power consumption and heat production. Indirectly, there is also
concern over weight and size. Weight and size do not directly affect speed,
but keeping weight and size down can make it harder to cool things, leading
to an even greater need to reduce heat production.

Laptops typically have slower RAM, slower buses, smaller caches, and slower
disks. Also, their processors often are NOT the same as the desktop
processors. They are often special low-power versions.

In the PC world, you can get laptops that are very close to desktop systems
in performance (heck, Alienware even sells a gaming laptop, designed for
high-end gaming--one of the most demanding performance situations you can
put a PC in), but take a look at those laptops: they are very heavy and have
short batter life. Essentially, they are desktop systems crammed into a
large laptop form factor.

If you pick a PC laptop that is small and light and has long batter life,
like the iBooks on the Apple side, you'll find that performance is less than
that of desktop machines, too.

--
--Tim Smith

in Beitrag U8udnd5Yt42JT9XdRVn-hA@io.com schrieb Duke Robillard unter
duke@NOSPAMio.com wrote:

Oh brother thank you. I am happy that I made the post; it seems things are
better than I thought.

I also assume it is the cache. But wait wasn't it that the old G3 ibooks had
512KB L2 cache? On the other side the Celeron has only 128 L2:

- ibook G4: 256k L2 (compare: old G3 ibook 512 L2)
- celeron laptop: 128k L2
- stationary machine: 512k L2

It is up to Apple to tell us why they sell the new ibook G4 with a smaller,
though faster level 2 cache. Didn't they think that a greater cache is
often required and that only tiny micro benchmarks without big an array
profit from smaller and faster caches.

Huge arrays are common. For example I have some colleagues who are involved
into high resolution solar imaging and their CCD arrays are 2024 x 2024
pixels and they use then such big arrays for FFTs or wavelets.

Why the stationary machine is that fast is out of my imagination. I also
made the test on a 1024x1024 array and the timings when compared to the
ibook timings had the same ratio.

The stationary machine is really old, because it was bought a few years ago.
Last year our sys-admin (at my institute department) increased the RAM from
128 to 196 MB. The hards disc has a capacity of 8 GB. Half of that is
reserved for Windows NT. But I never used NT on that machine because I
installed SuSE Linux (the sys admin thinks I am insane; but I am happy that
in our institute people and reasearchers may use what fits them best).

As a side note: The Bigloo version on the ibook takes 8sec for the 512x512
multiplication. That is what I have expected, because for large arrays
Bigloo produces code which is in the "2 times slower" than C range (see also
comp.lang.scheme and my thread about the Coyote Gulch benchmark where it is
demonstrated that Bigloo its floating point performance is on par with C,
though).

As I said the ibook (my hand coded native) C version lies around 4 seconds.
The stationary machine takes 3.8 seconds too (that has been tested and
confirmed many times by me) /but/ the Bigloo version on that machine takes
15seconds as opposed to the 8seconds on the ibooks. As you see on the ibook
Bigloo performs much better than what can be infered by the C ratio. On the
Celeron laptop the ratio is even better for the ibook, because there the
Bigloo version takes 24seconds.

Okay, I will not pitch on the last result, because it is good that Bigloo is
good on the ibook. However, I will not use the ibook for hard core
calculations, but I am used to make off-line calculations and preparation
files which in turn gets fed into the Sun workstations.

Thanks again for your results. You know: the gossip that I am likely going
to trade in my ibook was just rhetoric and only an insane guy would do it.
When I was younger I had a 100 MHz Performa 5300 Macintosh and a
second-hand Macintosh Performa 100MHz 603e powerbook. At that time I was an
undegraduate student and had no need for extensive calculations. In the
meantime I am a researcher and underpaid PhD student and my needs have
shifted. I used the two old Macs mainly for LaTeX and programming in the
functional programming language "Clean" and even paid the Shareware fee for
Macintosh LaTeX. [I do not understand why everybody believes that software
must be free/gratis].

But I have never forgotten the lovely Mac, though, I had a 3 year
side-step with my Celeron laptop. I hope I will one day reach a senior
postdoc position where I will be able to buy also a stationary Macintosh. In
the meantime I try to adapt my Gnome as Macintosh like as possible.

Regards,
Fensterbrett

Joshua Hesse wrote:

Excellent...that makes it close to
the 800 Mhz G4 iBook, as it should be.

Duke

Not Important wrote:


I now believe this is true. I just tried the test on the Sun
UltraSPARC I used before, but with Sun's compiler as well as
GCC. The differences in compilers is huge

$ time ./a.out.sun

real 0m1.39s
user 0m1.37s
sys 0m0.01s

$ time ./a.out.gcc

real 0m2.72s
user 0m2.68s
sys 0m0.03s


I also tried it without specifying the -O3, and that's another
huge difference.


$ time ./a.out.sun.noopt

real 0m6.16s
user 0m6.15s
sys 0m0.01s
$ time ./a.out.gcc.noopt

real 0m6.22s
user 0m6.20s
sys 0m0.02s


This little benchmark appears to be one of the old-ball programs
where the compiler optimization is vitally important.

Duke

With this code, the -faltivec flag does nothing.

% g++ -faltivec -O3 bench.c
% /usr/bin/time ./a.out
4.47 real 3.49 user 0.05 sys
% g++ -O3 bench.c
% /usr/bin/time ./a.out
4.65 real 3.46 user 0.05 sys
% g++ bench.c
% /usr/bin/time ./a.out
12.84 real 10.33 user 0.10 sys

From the g++ man page:

-faltivec
Enable the AltiVec language extensions, as defined in Motorola's
AltiVec PIM. This includes the recognition of "vector" and "pixel"
as (context-dependent) keywords, the definition of built-in func-
tions such as "vec_add", and other extensions. Note that unlike
the option -maltivec, the extensions do not require the inclusion
of any special header files. (APPLE ONLY)

So for the flag to be of any use, you would need to recode the routine.

-Josh
--

Hypnotoad will crush Fiestacat in the November election.

Duke Robillard <duke@nospamio.com> wrote:

The number that we are really concerned about is the 'user' time, since
the 'real' is more dependent on processor load. user is the amount of
processor time the program actually uses. real is the amount of time
it takes for the program to execute.

-Josh


--

Hypnotoad will crush Fiestacat in the November election.

"Tim Smith" <reply_in_group@mouse-potato.com> wrote in
ng52c.20537$yZ1.15990@newsread2.news.pas.earthlink .net on 3/5/04 1:18 PM:

You have got to be wrong. The primary stat to look at in any system is CPU
speed. All else is secondary. That is how we know Macs are more expensive
than PC's. If you shatter this idea, you shatter the one strand of hope the
Win fans have left to hold on to...

oh well... in reality you are right... of course.