Performance

Vol. 8 No. 9 – September 2010

Performance

Curmudgeon

Facing an Uncertain Past

Excuses, excuses, excuses!

Facing an Uncertain Past

Excuses, excuses, excuses!

Stan Kelly-Bootle, Author

Using my favorite Greek passive-present-neuter participle (I trust you have one, too), I offer a dramatic prolegomenon to this overdue column. To wit, an apology and an explanation for its tardiness. (You'll notice the potentially unending recursion,1 since both column and excuses are late.) The apology is easy: we Brits just say "Jolly sorry, actually,"2 and project a pained sincerity, whether we mean it or not.

In the broader political context, though, I have mixed feeling about the epidemic of generic apologies for past sins committed by my distant ancestors. I'm prepared to be jolly sorry, really, that we burnt the White House in 1814, provided that similar regrets are received on behalf of the damned Yankees who torched and looted York (now Toronto) in 1813. No doubt, with more Googling, I can backtrack all past tit-for-tat sequences (using Feynman's sum over histories?), although the cause-effect chain ultimately hits the prime-cause brick wall with a Big Bang. I haven't wikied Big Bang lately, but guess it's a stub entry demanding  expansions (super-inflationary?) and first-hand, eyewitness citations. Failing these, we are left with an unsatisfactory scapegoat for all our woes: a random quantum fluctuation in vacuo that somehow went badly wrong. Who to blame for that?3

by Stan Kelly-Bootle

Case Study: Multicore Performance

Photoshop Scalability: Keeping It Simple

Clem Cole and Russell Williams discuss Photoshop's long history with parallelism, and what they now see as the main challenge.

Photoshop Scalability: Keeping It Simple

Clem Cole and Russell Williams discuss Photoshop's long history with parallelism, and what they now see as the main challenge.

Over the past two decades, Adobe Photoshop has become the de facto image-editing software for digital photography enthusiasts, artists, and graphic designers worldwide. Part of its widespread appeal has to do with a user interface that makes it fairly straightforward to apply some extremely sophisticated image editing and filtering techniques. Behind that fa├žade, however, stands a lot of complex, computationally demanding code. To improve the performance of these computations, Photoshop's designers became early adopters of parallelism—in the mid-1990s—through efforts to access the extra power offered by the cutting-edge desktop systems of the day that were powered by either two or four processors. At the time, Photoshop was one of the only consumer desktop applications to offer such a capability.

Photoshop's parallelism, born in the era of specialized expansion cards, has managed to scale well for the two- and four-core machines that have emerged over the past decade. As Photoshop's engineers prepare for the eight- and 16-core machines that are coming, however, they have started to encounter more and more scaling problems, primarily a result of the effects of Amdahl's law and memory-bandwidth limitations.

by Clem Cole, Russell Williams

Articles

Tackling Architectural Complexity with Modeling

Component models can help diagnose architectural problems in both new and existing systems.

Tackling Architectural Complexity with Modeling

Component models can help diagnose architectural problems in both new and existing systems.

Kevin Montagne

The ever-increasing might of modern computers has made it possible to solve problems once thought too difficult to tackle. Far too often, however, the systems for these functionally complex problem spaces have overly complicated architectures. In this article I use the term architecture to refer to the overall macro design of a system rather than the details of how the individual parts are implemented. The system architecture is what is behind the scenes of usable functionality, including internal and external communication mechanisms, component boundaries and coupling, and how the system will make use of any underlying infrastructure (databases, networks, etc.). The architecture is the "right" answer to the question: how does this system work?

The question is, what can be done about the challenge to understand--or better yet, prevent--the complexity in systems? Many development methodologies (e.g., Booch1) consider nonfunctional aspects, but too often it stops at the diagram stage. The mantra of "we can address [performance, scalability, etc.] later" can be crippling. Individual components (applications) in a system can typically be iterated, but it is often far more difficult to iterate the architecture because of all the interface and infrastructure implications.

by Kevin Montagne

Thinking Clearly about Performance

Improving the performance of complex software is difficult, but understanding some fundamental principles can make it easier.

Thinking Clearly about Performance

Improving the performance of complex software is difficult, but understanding some fundamental principles can make it easier.

Cary Millsap, Method R Corporation

When I joined Oracle Corporation in 1989, performance—what everyone called "Oracle tuning"—was difficult. Only a few people claimed they could do it very well, and those people commanded high consulting rates. When circumstances thrust me into the "Oracle tuning" arena, I was quite unprepared. Recently, I've been introduced to the world of "MySQL tuning," and the situation seems very similar to what I saw in Oracle more than 20 years ago.

It reminds me a lot of how difficult beginning algebra seemed when I was about 13 years old. At that age, I had to appeal heavily to trial and error to get through. I can remember looking at an equation such as 3x + 4 = 13 and basically stumbling upon the answer, x = 3.

by Cary Millsap