How do you get mainframe performance on an embedded budget? Just learn the secrets of the mainframe gurus and apply them in your own designs. Architectural decisions define the ultimate feasible performance of any product. This article covers features that can help you improve your system’s performance.
Performance Monitoring and Tuning
2005-04-20 Hardware 8 Comments
It doesn’t make any difference how fast your hardware is if your software is slow. We just fixed a problem with a Java application that was stating files continuously, using up memory and CPU while doing it (including idle time). Stopping that activity dramatically improved the application’s performance.
This is an example of how performance tuning should be accomplished, not just yelling at the system or network administrator to “make it faster”.
Who am I to disagree with some ultra code nerd from IBM? I will have to say that 3 out of 5 times speed is slowed by poor code, or an idiot administrator who hasn’t deployed correctly or has bottlenecks all over the network.
I concur. It’s about damn time companies start throughly slimming down/optimizing software performance. They’re going to have to do it one way or the other anyway since we’re going into the multi-core era. I can only see positive things from this move. 🙂
Any System adminstrator worth his salt can avoid 95% of performance problems by doing his/her research on what the environment is going to be used for and to build it using best practices. I agree 95% of the time is due to poor codeing on the application owners part. I have seen a 16×32 Superdome brought to its knees by a single redbrick or brio query used to query a flat file. They were too lazy to rewrite the query from an enviroment they were upgraded from (a 4 way Alpha machine). End result we did our job as SA’s to provide a properly configured environment(our crap didn’t stink)and they were forced to do some re-writes.
I never had to trace an instruction at the cpu cycle level. Guess that’s for people with “real” tech jobs, not web developers like me. Profiling is all we need. Interesting article none the less.
I always thought of the osXXX crew’s yardstick of performance as, “if my printout is done by the time I get to the basement it’s fast”. Thanks for the insight and interesting viewpoint.
Not a peep about simulators and emulators. They have certain advantages–you need not modify either the hardware design or the software design; but the drawback is that you need to have an accurate model of the performance of the actual hardware, which for complex CPUs means modeling the pipeline, out of order execution, and multiple dispatch. But for embedded processors a decent instruction-level simulator can give you all the detailed performance information that you need. Also, the smallest embedded designs often do not have the die area for performance monitoring circuitry. Also, such logic may introduce timing problems that make it hard to reach the target clockspeed of the chip, essentially leading to a slower clocked development sample, or adjustments in other parts of an embedded design….
Simulation is important for embedded systems!