[KLUG Members] GNOME behavior -- initial impressions

[Robert G. Brown]

I played around with the behavior of windows, themes, and so on, and as 
far as I can tell, it doesn't mke any real difference what settings I use;
things render rather well, regardless of the settings.

FYI, this machine has an ATI Mach64 3D RAGE II video card, and 128 MB of
memory. I don't recall offhand how much video memory is on the card, but
it's not large (if someone is curious, I'll look, but IMO the chipset may
be more important than amount of memory, especially if it's small in both 
cases). I wouldn't characterize my use of this machine as particularly
ambitious, so I'm not inclined to worry about performance.

At the moment, after about an hour of fooling around with this install, I'm
pretty happy with it. It looks good, provides me with some things I didn't
have (for a number of reasons too dull to go into here) on the machine it 
replaces, and provides it all with good/excellent response.

OK, now I'll take off the GNOME-novice hat and put on the software developer
hat.  As a user of both AMD and Intel CPU's, I have been pleased with AMD 
products; they are an excellent value proposition. I just built an AMD-based
machine for my oldest daughter, for use at college (if you don't think that's
"mission-critical", you have not heard a college student, sans computer, hold
forth on her requirements).
 
I've spent a lot of time devloping and running applications with lots of float-
ing point intructions (a LOT of numerical analysis, scientific and finacial
computations, etc.), at various levels of optimization. This part of my busi-
ness requires that performance is actually placed FOURTH on the list of prior-
ities, behind reliable, stable solutions, portability, and quality technical
documentation for the programmers that actually use my stuff in applications.
Having said that, I don't want to give anyone the impression that these prior-
ities are taken as a licence to write slow code; they are often the most com-
pute-intensive component of applications, and are held to a rather high per-
formance standard.

Now, I don't want to (and can't, for practical reasons) spend time reading a 
lot about the electrical engineering or archicteure of various processors. What
I have seen in general is that the compiler has as much or more of an effect
on performance as the hardware, and optimization in modern compilers can cover
an awful lot of problems that programmers may introduce, even unknowingly.
Sometimes, coding "dumber" (to a limited degreee) may result in a better per-
forming executable across a wide variety of platforms, given that fairly high 
levels of processor-specific optimizations are available.

Often, compilers can mask good performance that was engineered into the chip 
in the first place, and good optimization can be a critical part ofthe success 
of a chip or chip family. For example, Solaris wouldn't shine without the stuff
Sun has done with their optimizing back-ends and code generation for the SPARC
chips; it's surely possible that the lack of a really good and broadly distri-
buted AMD-native optimizer and code generator have preserved and propaated the
notion that AMD chips lack floating point performance. Do they? I don't know!
I have observed that my applications, coded mostly in C, run rather faster on
Intel hardware, but I hesitate to point the finger of scorn at the chip itself.
What I'm observing is, as a practical matter, a collective phenomena that tends
to drive me toward Intel hardware if performance is a real requirement; I don't
have any economic support for building software in anything less abstract than
C, and lord knows where this stuff will be compiled and run tomorrow.

Intel makes a pretty darn good C compiler for Linux. Recently, I was at lunch
during a conference, and I found myself sitting next to the chairman of ACM
SIGPLAN (Special Interest Group on Programming Languages). His focus was not
on any particular hardware, but since he is doing a good deal of stuff with 
Cygwin and Linux, the bug in his bonnet was the gcc just isn't that good at
some things... and.. guess what? He liked the Intel compiler very much.. why?
about 90% of his stuff is, and will be, hosted on Intel hardware... duh!

Methinks TheBS discusses raw performance as an ultimate good; in reality it 
is tempered by other requirements. Moreover, the "true" performance is modu-
lated by so many factors that it's hard to untangle them all, every time, 
especially where there's little or no motivation to do so. This little work-
station is a good example of that.

                                                         Regards,
                                                         ---> RGB <---