Sparc Performance Problems--Thank You

Don A. Kreinbrink dak at super.org
Thu Aug 9 23:10:31 AEST 1990


Thanks to all who responded to my request for help concerning what I
thought to be strange behavior on my Sparc station.  The origins of this
question date back to a couple of months ago when Duncan Buell brought to
my attention that his upgrade to a sparcstation resulted in slower and
inconsistent execution of a small "benchmark" program he had.  The
responses I received pointed to possible reasons for this behavior:

1) I was compiling without optimization.  With a small program consisting
   basically of multiplies and divides with no i/o and little interdependency
   of variables the optimization basically results in very little actual
   computation being done.  In this situation the speed up is enormous.
   Without optimization, the absence of multiply/divide instructions in a
   Sparc architecture exacts a price in this type of program.

2) Some mention was made of the fact that using the dynamic libc in this
   type of program could result in slower execution.  There was some
   disagreement over this but I found that by using the -Bstatic option the
   timing results were faster on average, and more importantly, more
   consistent.  

In closing, my programming experience is still rather limited and I will
not pretend to totally understand the real causes of the problem.  Through
experimentation I would guess that a combination of both of the above had
some effect in my situation.  Duncan Buell sends along a thank you below.

***

Thank you to those who responded to my/Don Kreinbrink's question as to why
the Sun 4 gave such radically different timings on my "benchmark" program.
I was certainly aware that this wasn't a thorough benchmark and that the
absence of the multiply and divide instructions in the RISC chip would
have an influence; what surprised me was the anomaly of radically
different timings on what should have been the same program.

Knowledge being power, I will be able to avoid the problem in the future.

   Duncan Buell



More information about the Comp.sys.sun mailing list