[KLUG Members] GNOME behavior -- initial impressions

[Matty]

On Fri, 2002-11-29 at 16:26, Robert G. Brown wrote:
> 
> 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 

Yikes! I only have one hat :)

> 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 <---
> 
> _______________________________________________
> Members mailing list
> Members@kalamazoolinux.org
>