The Biggest Loser?

The Biggest Loser?

A new season of NBC’s “The Biggest Loser” recently started. Have you seen this show? My wife, Cherie, loves it; she finds it inspirational to watch these folks put them through such a tough ordeal in order to improve their health. I enjoy it as well, though my motives are completely different. There are some pretty large individuals on that show. Somehow watching them makes me feel less self-conscious of my physical shape and fitness, or lack there of. Somehow watching these folks toil makes me feel good about myself as I sit on the couch enjoying a handful of chips!

I do find it interesting how they measure gains or losses week in and week out. If you’ve watched from the beginning, you may have noticed that the current approach used is different than the first season. When the show first started, the contestants were measured purely on the amount of total weight, in pounds, they lost that week. Now, instead, they determine the biggest losers based on percent of weight lost each week. I believe that the decision to do so was to counter the ascertion that by going based purely on pounds that the competition favored those who were already the most overweight, as they would have more to lose.

But, it seems to me that the current approach doesn’t really solve the problem. Yes, it helps. Someone who was 250 pounds that loses 5 pounds now equals someone who was 400 pounds that loses 8. But, someone who is 400 pounds still has a lot more to lose over the long haul.

Let’s consider two theoretical contestants; I’ll call them Bob and Jillian. Let’s assume that they each have an ideal weight of 175 lbs. Let’s assume Jillian starts the competition at 225 lbs and Bob starts at 275 lbs. Imagine that 2/3rds through the competition, they’ve both lost 22% of their body weight. That means that Bob, the heavier of the two, has lost 61 pounds and now weighs 213 lbs. But Jillian, the lighter of the two, has lost 49.5 lbs and now weighs 175.5 lbs. She has nowhere to go from here, while Bob still has room to lose another 38 lbs! But, is that really the person who should be considered to have made the most achievement? Afterall the lighter of the two contestants made it to ideal weight much faster. Isn’t that what really counts?

This same phenomenon creeps up from time to time in the world of physical verification when we talk about scaling. Let’s face it, scaling is hugely important for DRC runtimes these days. If you are designing at 32nm or 28nm with a design with billions of devices, there is simply no way you are going to get reasonable runtimes without it.

As part of the efforts to continue to ensure the fastest total physical verification runtimes, Calibre continues to improve our scaling capability. If you are looking for the best runtimes with calibre for large designs, then hyper remote with remote data servers is the way to go. Hyper remote is a great concept. It actually combines calibre’s strengths in the world of true multi-threading, with our existing distributed processing and hyperscaling concepts. In essence, it allows us to run multi-threaded processes on remote machines. Also, by allowing the remotes to manage their own processes, it allows us to do many more tasks in parallel then traditional hyperscaling, thus improving scaling and cutting runtimes dramatically. Remote data servers allow us to also move memory allocation to be shared across the memory in the remote machines. Doing so greatly reduces the requirements for a “master” machine. The combination allows calibre to gain considerable improvements in both environments with lots of small (2 process node) machines, or in environments with several large servers with many processors. As always, its just part of the standard calibre licensing configuration, and all comes as part of the support dollars spent on your calibre investment.

But, with all that in mind, we still realize that scaling is only a means to an end. The end goal is really fastest turn around times. Sometimes its easiest to lose track of this goal, putting the emphasis not on runtimes but on scaling itself. This can be misleading. Consider the two scaling graphs below.

If you consider these two graphs out of context, it may be easy to conclude that the second graph represents the best solution for physical verification performance, because it seems to scale to more CPUs. But, there are some unstated assumptions made by doing so.

First, scaling is always measured by reference to some starting point. These starting points are not necessarily scaled. Recall our two Biggest Loser contestants, Bob and Jillian. Let’s assume that after 2/3rds through the season, Jillian stopped losing weight, but Bob continued to lose another 20 lbs through the course of the season. You could plot “scaling” as a curve of weight per week. In doing so, you’d clearly see that the heavier contestant’s weight loss ‘scaled’ further. But, could you then conclude that this means that contestant is somehow more fit? Of course not; Jillian weighs less!

The same is true for physical verification and scaling. Let’s consider the same original scaling graphs, but this time, lets plot them not by relative speed-up, but by actual runtimes. In doing so, some new information comes to light that can dramatically change the picture. Now we can see that the first graph’s curve stopped scaling earlier, but actually reached a faster total runtime in the end.

Ah, but you might say ‘the graph on the right still looks best because it is continuing to scale and by extrapolation, it looks as though it will eventually be faster.’ Well that’s a stretch to say the least. Let’s reconsider our contestants. We all know that eventually, each body has its own minimum healthy sustainable weight point. We know where Jillian’s minimum weight is; she already reached it at 175. But, you can’t tell if Bob will continue to lose more weight or if he has already hit his minimum. Quite frankly, any would-be contestant on the show would be well served to binge eat as much as possible prior to coming onto the show, just so they had more weight to lose over the course of the season, and thereby increasing their odds to stay above the dreaded yellow line!

Again, there is a similar analogy in the world of physical verification. Amdahl’s law clearly shows that all scaling solutions eventually reach a point of diminishing returns. In other words, every tool will eventually plateau with more CPUs, or, in some cases, even start to run slower. This basically means that you cannot extrapolate a scaling curve. We illustrate this point by extending the previous scaling curves to more CPUs below – clearly the extrapolation as not a safe bet.

Another commonly related mistake is to make a determination that for a larger design the second solution, that scales further, will be better because the first one stopped scaling too early to get good returns. This assumes that the scaling, and the point where that scaling stops, is consistent for a particular physical verification solution, across any design. I can’t speak for every tool, but for Calibre, that’s clearly not true. Calibre’s scaling will depend on many things: the size of the design, the hierarchy of the design, the number of rules being run, the complexity of the rules being run, the interactions between the rules run, the number of types of hardware used, … In general, we can say that two designs on the same process with similar design styles, but with two different design sizes, will not experience a runtime increase in proportion to the design size. It should be considerably less, given Calibre’s handling of hierarchy and repetition.

For the producers of “The Biggest Loser”, this may all seem like a lot to try to digest. J The point to remember is that scaling is just a means to an end. What are the real goals? For fitness, it is how to get to the ideal target weight the fastest, not how to stretch the amount of time it takes to achieve that out the longest! For physical verification the goals are two-fold: First and foremost is how to get the fastest possible runtimes. The second, less obvious one, should be how to get there with the lowest cost, which generally means with the fewest CPUs and using the least memory and disk resources.

Its for this reason that Calibre is not just optimized for scaling. It would be relatively easy to modify the Calibre architecture such that it scaled further, but to do so would likely increase the total runtime and memory usage. Instead, the focus for Calibre is first on reducing total CPU times through a combination of continued engine improvements and optimizations and by introducing new operations to simplify and speed new process checking requirements. Below is an example of performance improvements due to engine optimization in Calibre over the past year.

With this approach, the total CPU time required to run a job is significantly reduced. This means that when scaling to multiple CPUs, there is less computation that needs to be shared. In otherwords, less hardware is required to get to the ideal performance goals. Or, to go back to our Biggest Loser analogy, it means that Calibre is doing what it needs to to stay fit and trim from the beginning, instead of having to spend weeks on the treadmill with people screaming at you to improve!

More Blog Posts