Solaris and Linux system information.

Hey,

I have a program that takes more time on a solaris machine than on a linux machine. So I guess the best way to know whats going on is to compare the two systems ? CPU and Memory ? Is there any other parameter that I should look at ?

So on the linux box I ran:

And on the Solaris:

So I guess the fact that the CPU on linux box is 2.80GHz and on solaris box is 900 MHz made the difference ? lets assume that the system load on both the machines was the same.

What other commands can I use to get system information to diagnose these kind of problems.

Ive heard of intel processors but what is that sparcv9 processor on my solaris box? Is it only used on solaris machines ?

Also, on my linux box:

Processor and Machine is i686, but hardware platform is i386. Whats the difference ?

Thanks in advance for any kind of input

The three main resources are

(a) CPU, the performance of this will depends on clockspeed, memory, cache, number, whether program supports multiple processors

(b) IO, input/output such as disks, different disks take different time

(c) network resources, although you could put this under IO

One thing to look at is while your program is running, how much idle time is being taken during waits for IO?

If you had spare machines of the same spec you could also try linux on sparc or solaris on x86 to compare.

can you run it through a profiler on both systems? I am curious to see where the major time difference is.

Thanks Porter and frank for your replies !

frank_rizzo, do you mean use something like gprof ?

yes. I would also be curious to see the output of

truss -c your_program >/dev/null

on each system

I think that you need to compare hardware on the structure and micron level.

Xeon Woodcrest Preys On Opteron | Tom's Hardware
ftp://download.intel.com/design/Xeon/guides/25039702.pdf.

Then build an idea about how UNIX systems are put together. (well put together)

Unix File System - Wikipedia, the free encyclopedia
UNIX: System Design

Only then you can really give Solaris two thumbs up for Sparc/AMD hardware, and the same for Linux on x86, but not vice versa.

My personal history installing Linux Red Hat on Sparc ( and others like me who tried) is being disappointed at the lack of Linux drivers for SUN hardware. SUN still holds many of the Hardware design architecture proprietary. Thus giving you hard time with retrieval and display of data from and to I/O devices.

Great Raptor display cards, RPC units, SUN sound cards, and most importantly, the Oil fields equipment like quake sensors, ultra sound devices, and chemical analysis devices, fail to work with Linux, While SUN has given Solaris full armies of software drivers and applications for them.

Example; A few months ago an architecture firm requested me to check the possibility of migrating from SUN to Linux on their production line. They had pressure measuring devices that presses concrete cubes at 15, 28, 45, 60 days, until it cracks, giving the green or red light for a highway or a bridge to open or rebuild. I installed Linux on one of the hot swap drives, to find that Linux probed the massive hydraulic machines and installed them as a Xerox printers . Calling the manufacturer Siemens� for hours and days to get the design of the circuit boards and internal OS data resulted in a dead end, as they have signed a deal with SUN to keep those kinds of machines internals proprietary. The suggestion to use the SUN CD driver that came with the machine as a platform to hack a new driver was not welcome at all, due to legal ramifications.

I think it depends on your industry.

If you are an ISP, Telecom, Education, Stock market & Financial, CAD Design (innovation of the individual is the core of the industry) go with Linux on x86.

If you are Oil, Chemicals, Conveyor belt, Health care labs, construction measurements (the machine is the industry's back bone) go with Solaris on Sparc/AMD.

Still, this is a humble personal point of view. I might be wrong.

Hi.

These kinds of comparisons can be difficult. I think both hardware and software need to be considered.

Not necessarily, let us look a bit more.

You are comparing a 64-bit native RISC system, the SPARCV9, to a most-likely-32-bit CISC system, the Intel Xeon. Typically, a RISC system does not need the high clock speed of CISC. Is the Xeon Linux 32-bit or 64-bit?

I have used boxes that have that Intel Xeon CPU (2.8 GHz), and the predecessor of the SPARCV9, an Ultra-2 (but with 200 MHz clock).

Did you do the preparation of the program? At one time (in the 1990s) when I was comparing machines, we would often get codes that ran on IBM 3090s, and they didn't run too quickly on a Cray-2. When we looked in detail at the code, there were lots of double precision declarations, the 3090 being 32-bit machines. The Crays were 64-bit. Once we had made the adjustment, the code almost always ran faster on the Cray.

The options chosen for compilation can make a lot of difference. Compilers that are proprietary might produce faster code than others. Are the supporting libraries the same or equivalent? Looking for the best algorithm is the best use of time when optimizing.

As porter mentioned, one aspect is IO. For IO-bound jobs, you need good disks, as well as good hardware to get the data to and from the disks. Do you have the same facilities on both boxes? The designers of the Xeon box I mentioned earlier incorporated a really fast FSB, which helps the balance of large-scale application programs -- they often do some computing, then a lot of IO, then compute, IO, etc., in cycles.

I think you are on the right track -- clock rates, all the specs, etc., are not the issue. It's how your program runs that will determine the best machine -- for this one application. However, I recommend that you spend some time making sure that the playing field is at least approximately level. If you are going to run other programs, then you will need a representative sample of those runs for a comparison. For example, the ETA-10 series were really good for vector-class problems, but not very good for scalar codes. Ask yourself: what is the mix that I will be using?

Best wishes, keep us posted ... cheers, drl