Posted by : Unknown Saturday, June 29, 2013

Abstract
Introduction:
                Adaptive Software and Hardware are the new adaptation technology  terms which helps to get more benefits just by implementing minor modifications for the existing software and hardware architectures.
ADAPTATION DEFINED    
"The processes by which organisms or groups of organisms maintain homeostasis in and among themselves in the face of both short-term environmental fluctuations and long-term changes in the composition and structure of their environments."
ADAPTIVE SOFTWARE
"Adaptive software uses available information about changes in its environment to improve its behavior."
v Five Myths of Traditional Software Development:
·         The myth of the specification:
·         The myth of software maintenance:
·         The myth of the black box:
·         The myth of design choices:
·         The myth of the expert programmer:
v Key Technologies for adaptive software:
·         Dynamic programming languages
·         Agent Technologies
·         Decission Theory
·         Reinforcement Learning
·         Probablistic Networks
ADAPTIVE  HARDWARE
Meaning:
“Adaptive hardware is specially designed to meet the  needs of the present changing technological requirements. “
Currently, the following adaptive hardware is available:
ü  Braille Embosser
ü  Track Ball
ü  Refreshable Braille Display
ü  Sheet-Fed and manually loaded scanners
ü  Head Mouse
CONCLUSION:
To obtain the extreme fruit full results of the existing technologies either the hardware or the software , the adaptive technology can be served as the best solution.
INTRODUCTION:

                Adaptive Software and Hardware are the new adaptation technology  terms which helps to get more benefits just by implementing minor modifications for the existing software and hardware architectures.

ADAPTATION DEFINED

"The processes by which organisms or groups of organisms maintain homeostasis in and among themselves in the face of both short-term environmental fluctuations and long-term changes in the composition and structure   of their environments."

ADAPTIVE SOFTWARE

MEANING:
"Adaptive software uses available information about
changes in its environment to improve its behavior."


The Problem With Software

The problem with software is that it takes too much time and money to develop, and is brittle when used in situations for which it was not explicitly designed. Various software design methodologies address this problem:
  • 1970s: Structured Programming

This makes it feasible to build larger-scale software systems - provided you have a specification of the desired results at the start of the project and the specification rarely changed. A typical application is a database report writing program which reads an input file and produces an output file. We call this an input/output based application.
  • 1980s: Object-Oriented Programming

This makes it easier to reorganize when the specification changes, because functionality is split up into separate classes that are designed to have minimal interaction between them However, each change to the specification (or to the environment) still requires programmer intervention, with a costly redesign/reimplement/rebuild/retest cycle A typical application is a desktop publishing system, where user-initiated events (mouse clicks, menu selections, etc.) trigger computation. We call this a user-initiated event based application.
  • Today: Adaptive Programming
      
It is aimed at the problem of producing applications that can readily adapt in the face of  changing user needs, desires, and environment. Adaptive software explicitly represent the actions that can be taken and the goals that the user is trying to achieve. This makes it possible for the user to change goals without a need to rewrite the program. A typical application is an information filter which searches the Internet or company intranet for information of personal interest to the reader. Note that much of the searching may go on when the user is not even logged in. The application does more on behalf of the user without constant interaction, and the sophistication comes from a splitting of responsibilities between the program and the user. We call this an agent based application.

Of course, there have been other proposed methodologies for improving software. Some address the problem of managing change, but only adaptive programming is about anticipating change and automatically dealing with it within a running program, without need of a programmer.

The Challenge of Complex Environments

Software is expected to do more for us today, in more situations, than we ever expected in the past. This is the challenge of complex environments.

The complexity comes from three dimensions.


First à  There are more users. Now everyone, not just trained professionals, uses software.

 Second à  There are more systems and more interactions among them. A company that once had a homogeneous mainframe now has a wide variety of desktop, server, and mainframe machines, running a wide variety of protocols.

Third à  There are more resources and goals. Programmers are accustomed to trading off time versus space.

Now they also have to worry about bandwidth, security, money, completeness of results, quality of information, resolution of images and audio, and other factors, and they have to make the right trade-offs for a wide variety of users.

Together, these three dimensions make the designer's job harder. The designer can't foresee all the circumstances in which an application will be used, and thus can't always make the right design choices. This can shorten a product's lifetime, because upgrades will be needed for unforeseen situations, and it undermines the end user's confidence that the product will even perform as advertised.


We can summarize the difficulties posed by complex environments with this table:


      Standard Environment

Complex Environment

Certain
Uncertain
All inputs observable
Some inputs hidden
Deterministic
Non-deterministic
Repeatable
Unique
No other players
Other players
Static
Dynamic
Discrete
Continuous
Virtual world
Real world

Five Myths of Traditional Software Development
Traditional software development is based on some principles which are no longer appropriate under this new world of complex environments. It is worth looking at five of these myths.

·        The myth of the specification:
                
Traditional software development assumes that the first task is to determine the specification, and all design and development follows after the specification is finalized. More modern approaches stress spiral rapid development methods in which the specification is constantly being refined. The target is really a combination of related components, not a single application.

·        The myth of software maintenance:

                 The word "maintenance" gives the impression that the software has somehow degraded, and needs to be refurbished to its original condition. This is misleading. The bits in a program do not degrade. They remain the same, while the environment around the program changes. So it is really a process of upgrading or evolving to meet the needs of the changing environment. By viewing it as a maintenance problem, one risks making the mistake of trying to preserve the old structure when its time has passed.
·        The myth of the black box:
           
Abstraction plays a crucial role in the development of reliable software. However, treating a process as a black box with an input/output specification ignores the practical problem of resource usage. When a system built out of these black boxes is too big or too slow, there is no way to improve the performance other than to tear the boxes apart. Some work has been done on the idea of Open Implementation, in which modules have one interface for input/output behavior, and another orthogonal interface for performance tweaking. Adaptive software adds to this by making the orthogonal interface a two way system ÷ there is a feedback loop that provides information on the results of the performance tweaking.

·        The myth of design choices:
                
In traditional software development, the designers consider several alternatives to implement each component, and then make choices based on the desired product. The alternatives that were not chosen, along with the rationale for the choice, are then discarded. That means when the environment changes (perhaps a new communications protocol becomes popular, or the user gets a computer that is twice as powerful), one needs to start all over again to see what choices are now the best. Often, the original programmers have moved on, and so their design rationale is lost. The alternative is to capture the design criteria as a formal part of the program, and let the program reconfigure itself, as the environment changes, to optimally satisfy the criteria.
·        The myth of the expert programmer:
           
 Most programmers have pride in their abilities, and feel they can always come up with a good solution, given a suitable specification of the problem. In reality, programmers are only one resource available to a project, and an expensive resource at that. Furthermore, it is impractical to ship a developer with each program (except for very large and expensive custom applications). This suggests that we find a tradeoff where the programmers and designers do what they can do best ÷ formally describe what the program is trying to do. Then the program itself does the calculating and configuring necessary to achieve these goals in the current environment.
Key Technologies for Adaptive Software

Now we know what adaptive software does: it uses information from the environment to improve its behavior over time, as the program gains more experience. And we know why it is difficult to do this: because specifications are incomplete and changing, because the environment is constantly changing, because carefully crafted designs may rely on assumptions that become obsolete, and because there is never as much programmer time as you really need. In this section we survey some of the tools that help us overcome these difficulties.
Here are five of the most important:

  • Dynamic Programming Languages provide a robust framework for writing applications that persist over long lifetimes, and can be updated while they are running.
  • Agent Technology is a point of view that encompasses the idea of acting in accord to a user's preferences.
  • Decision Theory provides the basic terminology to talk about an uncertain world, and about what the preferred outcomes are.
  • Reinforcement Learning gives us a way to learn what sequence of actions to perform, given local results of the worth of individual actions.
  • Probabilistic Networks provide powerful algorithms for computing optimal actions based on whatever is known about the current state of the world.
   Dynamic Programming Languages
Static languages like C require the programmer to make a lot of decisions that nail down the structure of the program and the data it manipulates. Dynamic languages like Dylan and CLOS (Common Lisp Object System) allow these decisions to be delayed, and thus provide a more responsive programming environment in the face of changing specifications. Changes that would be too pervasive to even try in static languages can be easily explored with dynamic languages. Dynamic languages provide the interfaces by which a program can change or extend its performance. For example, in Dylan, a running program can add a method to an existing class without access to the original source code; can define a brand new class or function under program control; can debug another Dylan program, even one running remotely over the web. All this makes it possible to build, re-build and modify complex programs using components. Java is currently the most popular language with dynamic features, although it is not as thoroughly and elegantly dynamic as Dylan and CLOS.
   Agent Technology
There has been a lot of talk about software agents, and not much agreement on what they are. The Oxford English Dictionary entry for "Agent" says: from Latin agere ("to do"),
1. One who acts or exerts power.
2. He ... who produces an effect.
3. Any natural force. (e.g. a chemical agent).
4. One who does the actual work - a deputy, substitute, representative.

So we see that essentially, an agent does something and optionally does it for someone. Of course, all programs are intended to do something for someone. Therefore, in order to make a distinction between "software agent" and just a "program," we stress that software agents should be able to immediately respond to the preferences of their sponsors, and act according to those preferences. In addition, we think of an agent as existing in a complex environment. It can perceive part of the environment, and take some actions, but it does not have complete control over the environment.
In short, we want the agent to do the right thing, where "right thing" is defined by the user or users at that point.


There are three reasons why this is difficult:
  • You can't always get what you want:
             In a complex environment, you generally can't optimize everything at once. You can't have a program that is 100% accurate, yet uses no resources and runs in no time. So we need a way for the user to say which resources and results are most important, and which ones are less so.
  • You never know what's going to happen:
          Traditional programs are built with Boolean logic, which treats everything as "true" or "false." This is appropriate for the internal working of a digital computer, but out in the real world there are always going to be events about which we are uncertain. For example, it is "likely" that we will be able to establish a given network connection, but we won't know for sure until we try.
  • You're not the only one in the world:
       There are other programs out there which can change the environment, and with which we can cooperate, contract, compete, and communicate.
   Decision Theory

Decision Theory is the combination of utility theory (a way of formally representing a user's preferences) and probability theory (a way of representing uncertainty). Decision Theory is the cornerstone for designing proper adaptive software in an uncertain, changing environment.

It is "the" language for:

  • Describing adaptive software:
                To respond to user preferences and deal with uncertainty, decision theory provides the only mathematically sound formalism to describe what it means to "do the right thing."
  • Building adaptive software:
         In some simple cases, once you've done an analysis of a problem using decision theory, it becomes clear how to implement a solution using traditional methods. But more often we need to use decision-theoretic technology like reinforcement learning or probabilistic. Sometimes, a compilation step can be used, so that the run-time computational demands are minimal.
  • Communicating with agents:
        What should a user say to a software agent? Or what would one software agent say to another? Most importantly, they should be able talk about what they want to happen, and so they need the language of utility theory. But they also may want to talk about what they believe, and that requires probability theory.
   Reinforcement Learning
Reinforcement Learning is a powerful technique to automatically learn a utility function, given only a representation of the possible actions and an immediate reward function - an indication of how well the program is doing on each step. Given enough practice (either in the real world or in a simulated environment), reinforcement learning is guaranteed to converge to an optimal policy. Reinforcement Learning problems could in principle be solved exactly as a system of nonlinear equations, but in practice the problems are much too large for an exact solution, so we rely on an approximation technique based on dynamic programming.
As an example, consider assigning cellular phone calls to channels. You want to use the available channels wisely so that there is no interference and a minimum of dropped calls. Using reinforcement learning, Harlequin invented an algorithm that dynamically adapts to changes in calling patterns, and performs better than all existing published algorithms. Reinforcement learning has been applied to other domains, such as flying an airplane, scheduling elevators, and controlling robots.
   Probabilistic Networks
Probabilistic networks (also known as Bayesian networks, Decision networks, and Influence diagrams) are a way of representing a complex joint probability distribution as a graphical model of nodes (representing random variables) and arcs (representing dependence between variables). There are algorithms for determining the value of any variable, for learning qualitative and quantitative dependencies from data, for quantifying the sensitivity of an answer to uncertainties in the data, and for computing value of information: the worth of acquiring a new piece of information.

 Industries and Applications for Adaptive Software

Here are some real-world applications of adaptive software undertaken by the Adaptive Systems Group at Harlequin:

v Crime Pattern Analysis and Fraud Detection:

Harlequin makes a data visualization tool for fraud and crime analysis called Watson. For mid-size databases, trained users can easily navigate through the various displays to find the patterns they are looking for. However, for larger databases we needed to add data mining techniques to help spot the patterns. As new patterns in the data occur, we provide ways of visualizing them.

v Financial:
A credit card company wanted to be able to track purchase authorization requests, and decide which requests were likely to be from a stolen card, or were likely to be a credit risk. Harlequin supplies the software upon which the authorization system is written. The key for the customer was to have an efficient system capable of processing large volumes of transactions in real time, but still have a flexible system, where changes could be made in minutes, not days, with no need to bring the system down to install upgrades.

v Manufacturing:

 A multinational company faced the problem of needing to continually build new versions of their product to meet new industry standard specifications. Each test run of a new product variation costs about $10,000. Harlequin is actively consulting on this project to bring together all the prior test results and accumulated experience of the organization in one online tool, and to provide sophisticated statistical optimization techniques to recommend an optimal experimental test plan, based on past results and predicted future contingencies.

v Electronic Publishing:

Harlequin's raster imaging processing software for high-end commercial printing is the fastest on the market. But customers are interested in the speed of the total solution, so we are developing a dynamic workflow management system that will optimize the tracking and scheduling of the customer's complete set of job tasks. This requires monitoring the jobs and being able to predict how long each job will take at each processing stage.

v Telecommunications:
           
A telecommunications company wanted to build an experimental switching system for delivering video on demand to the home. This requires strict real-time response (30 frames per second, no matter what), but it also requires flexibility in the software. The customer required that they be able to add new functionality and even redefine existing functions while the switch is running, because it would not be acceptable to interrupt service. Harlequin worked with the customer to meet these requirements using a real-time version of CLOS. The result was a switching system that met all requirements, and was built with only 25 programmers, as compared to the 250 needed on the system it replaced. A corresponding 10-fold improvement was also seen in development costs and engineering change turn-around time.

 Groups Working on Adaptive Software
Harlequin's Adaptive Systems Group brings added value to Harlequin's programming tools, web tools, and postscript printing software, and also offers consulting services for other companies. Some of the projects are shown in the accompanying side bar.
Microsoft's Decision Theory and Adaptive Systems Group was started by several experts in decision theory (David Heckerman, Jack Breese and Eric Horvitz), and was recently renamed to include "Adaptive Systems" in the title. The group contributed the Print Troubleshooter in Windows 95 and the Answer Wizard in Microsoft Office.
The Symposium on Flexible Computation from the AAAI Fall Symposium dealt with "procedures that allow a graceful tradeoff to be made between the quality of results and allocations of costly resources, such as time, memory, or information. Systems employing flexible computation gain the ability to adapt the quality of their response to dynamic changes in requirements."
The Adaptive Intelligent Systems group run by Barbara Hayes-Roth at Stanford is investigating "systems that coordinate perception, reasoning, and action to pursue multiple goals while functioning autonomously in dynamic environments."
The Demeter Group at Northeastern University says that "adaptations of the interactions of components can only be defined in terms of accumulated individual component adaptations. New techniques are starting to provide higher levels of abstractions for adaptability. Software architecting brings system level abstractions. The Adaptive Software family of languages allows this higher abstraction at the programming level."
The Open Implementation project at Xerox PARC provides the basis of the black box metaphor used in this paper. Xerox's Aspect Oriented Programming project goes one step further. "AOP works by allowing programmers to first express each of a system's aspects of concern in a separate and natural form, and then automatically combine those separate descriptions into a final executable form using a tool called an Aspect Weaver™."
The GMD's (German equivalent of NSF) Adaptive Systems Research Group deals with statistical learning and with adaptive robotics.
Some people use "adaptive" for software that helps people with disabilities. Other people use "adaptive" to refer to evolutionary, neural, or biological computation. See the book The Mind, the Brain, and Complex Adaptive Systems, edited by Harold Morowitz and Jerome Singer.


Adaptive Hardware

Meaning:

Adaptive hardware is specially designed to meet the  needs of the present changing technological requirements.

Currently, the following adaptive hardware is available:

ü Braille Embosser
This Braille Printer is primarily used to Braille handouts, and tests for  students with visual impairments.
ü Trackball
This ergonomic trackball is designed especially for computer users with a limited range of motion and those who have some difficulty with motor control.
ü Refreshable Braille Display
For use by students who are Braille-readers, this device translates printed material on a computer screen to Braille output. As the student scans down the page, the Braille display refreshes itself to read out the current line of text.
ü Sheet-Fed and Manually Loaded Scanners
Scanners are primarily used to bring print material into a computer for translation into text that can be read to or by a student. Working in conjunction with Optical Character Recognition software, scanners allow students with Visual Impairments or Learning Disabilities to access information in electronic format.
ü HeadMouse
The HeadMouse sensor replaces the standard desktop computer mouse for people who cannot use their hands. The HeadMouse is a device that translates the movements of a user's head into directly proportional movements of the computer mouse pointer. The HeadMouse will track the user's head with the user located in any comfortable viewing position relative to the computer display.




RECONFIGURING   WIRELESS   PHONES   WITH ADAPTIVE   CHIPS:

                Configurable and reconfigurable chip theory and technology have been around since the 1960’s. The US military was one of the first to use the technology, in it’s radio systems.
            Traditionally, devices need a separate chip to work with each standard, said Paul Master, chief technology officer for adaptive-chip vendor  QuickSilver Technology.
            Meanwhile, as wireless technologies mature, service providers differentiate themselves by offering new features, such as multimedia capabilities.
            Providing each feature typically requires a separate chip or, in essence, multiple circuitry systems physically joined on a piece of silicon. The additional circuitry adds cost, takes up space, increases power usage in mobile devices, and increases product-design time.
            Vendors are dealing with this problem by using an old approach—adaptive(also called reconfigurable)chips-- in a new way.
            With this approach, software can redraw a chip’s physical circuitry on the fly, letting a single processor perform multiple functions. In addition, adaptive computing could increase performance while reducing energy consumption.” This would allow you to easily add new features without a major chip[redesign],” said Allen Nogee, principal analyst for the Wireless Component Technology Service at In Stat/MDR, a market research firm.


à RECONFIGURABLE  TECHNOLOGY:

                For decades, logic chips have largely relied on fixed circuitry, in which all software instructions flow through pathways etched into the silicon during manufacture.
            This inflexible design makes it difficult for the product developers to quickly adapt to changing markets and technology formats. And adapting a traditional chip requires building a mask for etching new circuitry on to the silicon, an expensive process.
               
Proponents say reconfigurable chips address these problems.
               
1)    Inside Adaptive Chips:
                                                In adaptive computing , circuitry typically  can be changed on the fly, as software instructions tell a subset of chip’s hundreds of millions of logic gates to open or close, altering the circuitry’s information pathways. Reconfiguration can occur within as little as  a clock cycle.
            Systems can use various mechanisms to input reconfiguration information. One  is that it features a separate configuration interface that delivers the programmed information—either as raw bits that requires no decoder or high-order commands that need less memory but require one or more decoders—to its appropriate destination on the chip.
            It must be sophisticated enough to control the reconfiguration process directly, without the need to involve additional hardware or software.
2)    Enabling Technology: SRAM

Recent advances in high-speed  static RAM have enabled many of the adaptive-chip improvements.
These advances in SRAM permit the technology to store considerable to store more data then in the past.
SRAM provides adaptive chips with enough memory to hold information  about potential circuitry reconfigurations so that the adaptation can take place..

àDIFFERENT APPROACHES:
               
                The three main different approaches to adaptive-chip technology are:

    ** QuickSilver:
]
With QuickSilver’s adaptive-computing-machine technology, the operating      system uses software instructions to change the circuitry for the task at hand.

** PipeRench: 

Carnegie Mellon’s Pipe-Rench adaptive chip changes circuitry via hardware-based instructions, not via the OS, explained Schmit.


** Intel:  

Intel’s approach establishes sets of circuitry patterns on a chip. Each set is designed to handle the same general types of functions. Each can then be reprogrammed to handle different but similar operations. For example, a circuitry set designed to function as a filtering accelerator could be reprogrammed to perform tasks such as digital filter equalization. This process is easier than reprogrammable circuitry to handle completely different tasks.

Other Advantages:
 
v  In a given configuration, an adaptive chip becomes a processor dedicated to a specific task, which makes it faster than a general-purpose microprocessor.
v  Since adaptive chips use only that part of the circuitry necessary for a task, they are more energy efficient.
v  The chips can shut off various components when not in  use, they experience less energy leakage.
v  Products using adaptive chips, which can be modified simply by changing the programming, could also have quicker design cycles than those using conventional fixed-circuit chips.
v  Adaptive systems eliminate many system elements by combining their functionality on a single piece of silicon , they simplify systems and take up less space.

Dynamically  Tuning  Processor  Resources with Adaptive  Processing

          “Using adaptive processing to dynamically tune major microprocessor resources, developers can achieve greater energy efficiency with reasonable hardware and software overhead with undue performance loss”.

The adaptive processing approach to improving microprocessor energy efficiency dynamically tunes major microprocessor resources—such as caches and hardware queues—during execution to better match varying application needs.1,2This tuning usu-ally involves reducing the size of a resource when its full capabilities are not needed, then restoring the disabled portions when they are needed again. Dynamically tailoring processor resources in active use contrasts sharply with techniques that simply turn off entire sections of a processor when they become idle. Presenting the application with the required amount of hardware—and nothing more—throughout its execution can achieve a potentially significant reduction in energy consumption. The challenges facing adaptive processing lie in achieving this greater efficiency with reasonable hardware and software overhead, and doing so without incurring undue performance loss.
.


ADAPTIVE PROCESSING ELEMENTS

To prevent the costs of adaptive processing from rivaling its energy advantages, the feedback and control mechanisms must be kept simple and the adaptive hardware overhead must be nominal.

·       Adaptive hardware structures

Chip designers organize adaptive hardware so that they can rapidly change its complexity, usually a function of its size or width, to fit current application needs. Modern processor designs feature easily adaptable modular structures, such as caches and issue queues.
Although the system always enables the bottom increment of eight entries, it enables the upper increments’ con-tent-addressable memory and random-access memory arrays on demand, according to the application’s needs . Transmission gates isolate the CAM and RAM bit lines, while simple gates achieve this function for the taglines.
The designer also partitions the wake-up and selection logic sections, the latter by simply gating the select tree at the appropriate level depending on the number of enabled increments. The system adapts modular hardware structures and uses simple feedback and control to reduce hardware overhead.
coarse level of adaptation, Alper Buyuk to sunogluand colleagues discovered that using such an adaptive structure in a high-end processor would not affect clock frequency.4The gate count and energy overhead each increased by less than 3 percent. The DRI-cache can disable individual cache sets, thereby maintaining constant associativity. To enable or disable the set, the DRI-cache uses anextra high-threshold-voltage transistor for each row of RAM cells—which corresponds to one cache set.
The transistor is placed between the cells’ nor-mal ground for an individual set and the actual ground.  A  logic high on the transistor gate signal enables this set. Otherwise, the set is disabled, which significantly reduces its leakage current and dynamic power. Despite this relatively fine-grained voltage-gating approach, the DRI-cache’s area and speed overhead are less than 8 percent. Disabling a set reduces its leakage current by 97 percent, but the contents are lost. A recently proposed alterna-tive6disables part of the cache by dynamically switching to a lower voltage, thereby retaining cache contents while achieving about the same reduction in leakage power.

·       Feedback and control system

Because adaptive processing reduces the effective size of hardware structures, some increase in execution cycles is almost inevitable. Thus, the feed-back and control system seeks to maximize the savings in energy while limiting any performance loss below a specified level.
This involves three major functions: monitoring the adaptive hard-ware, triggering a decision, and making the decision.

Ø Monitoring.

To guide reconfiguration decisions, the monitoring system gathers statistics that infer the effectiveness of the adaptive hardware structures the processor is controlling or that help identify program phase changes. The system can gather these statistics in hardware each cycle, or it can use sampling to reduce monitoring overhead. Dmitry Ponomarev and colleagues7proposed an adaptive-issue queue that records the number of valid queue entries at the end of a sample period and averages them over a longer interval period. The system uses this average value to determine when to downsize the queue. Simultaneously, an overflow counter tracks the number of cycles whose dispatch is blocked due to a full queue. The system uses this result to guide upsizing decisions.

.Daniele Folegnani and Antonio Gonzalez use program parallelism statistics, rather than issue queue usage, to guide reconfiguration decisions.8Specifically, if the processor rarely issues instructions from the back of the queue—that portion of the queue that holds the most recent instructions—the system assumes the queue to be larger than necessary and downsizes it. The system also periodically up sizes the queue at regular intervals to limit performance loss.
Researchers commonly use cache miss rate to guide cache configuration decisions. The DRI-cache, for example, measures the average miss rate over a set operation interval to determine whether to change the cache size. As miss rate information may already be available in microprocessor performance counters, the system can essentially acquire this statistic for free.
Compiler-based profiling offers an alternative to hardware monitoring. With this approach, developers either instrument the application and run it on the target machine to collect statistics, or they run it on a detailed simulator to gather the statistics. Michael Huang and his colleagues use the simulator approach to collect statistics about the execution length of subroutines for phase detection.
The application behavior observed during the profiling run must be representative of the behavior encountered in production. Because this assumption may not hold for many general-purpose applications, and inexpensive hardware counters are readily available in modern microprocessors or can be added with modest overhead, hardware-based monitoring is more frequently used in adaptive processing.

Ø Triggering.

 A microprocessor can use several approaches to trigger a reconfiguration decision. The first approach reacts to particular characteristics of the monitored statistics. For example, Ponomarev’s adaptive-issue queue scheme upsizes the queue when the average number of valid queue entries over the interval period is low enough that
a smaller configuration could have held the aver-age number of instructions. The system can easily determine this condition from the sampled aver-age occupancy statistics, the queue’s current size, and the possible queue configurations. To prevent non negligible performance loss, the system upsizes the queue immediately when the overflow counter exceeds a preset threshold.
Another approach detects phase changes to trig-ger reconfiguration decisions. Balasubramonian’s adaptive memory hierarchy10compares cache miss rates and the branch counts of the last two intervals. If the system detects a significant change in either, it assumes that a phase change has occurred. Ashutosh S. Dhodapkar and James E. Smith11improve on this approach by triggering a phasechange in response to differences in working-set signatures—compact approximations that represent the set of distinct memory elements accessed over a given period. A significant difference in working-set signatures constitutes a phase change. Still another approach triggers a resource upsizing only when a large enough increase in performance would be expected. This technique can be used to upsize an adaptive-issue queue.12A larger instruction window permits the stall time of instructions waiting in the window to be overlapped with the execution of additional ready instructions in the larger window. However, if this overlap time is not sufficiently large, upsizing the queue will provide little performance benefit. The system estimates the overlap time and uses it to trigger upsizing decisions. Huang and colleagues proposed positional adap-tation,9which uses the program structure to identify major program phases. Specifically, as the “Managing Multiple Low-Power
 Adaptation Techniques: The Positional Approach” sidebar describes, this approach uses either compile-time or runtime profiling to select an appropriate con-figuration for long-running subroutines. In the static approach, a profiling run measures the total execution time and the average execution time per invocation of each subroutine. Developers identify phases as subroutines with values for those quantities that exceed preset thresholds, then they instrument the entry and exit points of these routines to trigger a reconfiguration decision.

Ø Making a decision.

Once a trigger event occurs, the system must select the adaptive configuration to use over the next operational period. If the number of configuration options is small, the system can use a simple trial-and-error approach: It can try each configuration over consecutive intervals and select the best-performing configuration. Balasubramonian’s adaptive memory hierarchy uses this exploration approach.
A second approach uses the monitored statistics to make a decision. Ponomarev’s adaptive-issue queue chooses a new configuration based on the difference between the current number of queue entries and the sampled average of valid entries over the interval period. If this difference is large, the system can downsize the queue more aggressively.
These approaches operate from the underlying assumption that current behavior indicates future behavior.  If the behavioral change rate rivals that of the evaluation period, significant error can occur. Decision prediction attempts to circumvent this issue by using past configuration information to predict the best-performing option.  Dhodapkar andSmith11save their working-set signatures in RAM, along with configuration information. When the current signature closely matches a signature stored in RAM, the system looks up the configuration and immediately uses it. Similarly, in Huang’s positional scheme, for every code section, once the best con-figuration is determined, it is remembered and applied to all future executions of that code section.


GRACE: A Cross-Layer Adaptation Framework for Saving Energy

Adaptation techniques are commonly used for reducing energy in each layer of the system—hardware, network, operating system, and applications. Reaping the full benefits of a sys-tem with multiple adaptive layers requires a careful coordination of these adaptations. The Illinois GRACE project—Global Resource Adaptation through Cooperation—has developed across-layer adaptation framework to reduce energy while pre-serving desirable application quality for mobile devices running soft real-time multimedia applications.
A cross-layer adaptive system must balance two conflicting demands: adaptation scope and temporal granularity. For example, a global adaptation scope is desirable, but it can be expensive and so must be infrequent. Adapting infrequently, however, risks an inadequate response to intervening changes.
To balance this conflict, GRACE adopts a hierarchical approach,  performing expensive global adaptations occasion-ally and inexpensive limited-scope adaptations constantly. This combination can achieve most of the benefits of frequent global adaptation with lower overhead. As Figure A shows, GRACE supports three levels of adaptation, exploiting the natural frame boundaries in periodic real-time multimedia applications:
• Global adaptation   considers all applications and system layers together but only occurs on large changes in system activity, such as application entry or exit.
Per-application adaptation   considers one application at a time and is invoked every frame, adapting all system layers to that application’s current demands.
• Internal adaptation   adapts only a single system layer, possibly considering several applications simultaneously, and is invoked several times per application frame—per net-work packet, for example.
All adaptation levels are tightly coupled, ensuring that the limited scope adaptations respect the resource allocation decisions made through global coordination. Further, all adaptation levels use carefully defined interfaces so that no application or system layer needs to expose its internals to other parts of the system. The initial GRACE-1 prototype1combines global application and CPU adaptations and internal scheduler and CPU adaptations, providing an increase in battery lifetime of 33 to 66 per-cent over previous systems. Separately, a combination of CPU and application adaptation at the per-application level2achievesenergy savings of up to 20 percent and 72 percent, respectively, compared to either adaptation alone. Other experiments show the benefit of hierarchical adaptation within a single layer;3theaddition of internal adaptation gave an energy reduction of  up to 19 percent over a per-application CPU adaptation alone.
We are currently integrating these components along with an adaptive network layer to form a complete coordinated adaptive system.

------------------------------------------------------------------------------------------------------------
To date, many adaptive processing techniques have focused exclusively on reducing dynamic power. In future process technologies, we expect that leakage power will rival dynamic power in magnitude—and adaptive techniques will be positioned to address both. For example, an adaptive processing system can apply voltage-gating directly to the issue queues, reorder buffer, and register files because the system ensures disabled partitions are empty before turning them off. This technique can also be applied to the L1 I-cache, while an approach such as drowsy caches6can be used in the L1 D-cache and L2 cache to preserve their state. Adaptive processors require a modest amount of additional  transistors. Further, because adaptation occurs only in response to infrequent trigger events, the decision logic can be placed into a low-leakage state until a trigger event occurs. These characteristics make adaptive processing a promising approach for saving both dynamic and leakage energy in future CMOS technologies.

ADAPTIVE SOFTWARE AND HARDWARE IMPLEMENTATIONS:


The following are the implementations of the adaptive software and hardware implementations:

ü Adeos
Adeos stands for Adaptive Domain Environment for Operating Systems. It is a Hardware Abstraction Layer between the Operating System and the Hardware
The purpose of Adeos is to provide a flexible environment for sharing hardware resources among multiple operating systems, or among multiple instances of a single OS.
To this end, Adeos enables multiple prioritized domains to exist simultaneously on the same hardware. The Adeos nanokernel has been successfully inserted beneath the Linux kernel, opening a full range of new possibilities, notably in the fields of SMP clustering, patchless kernel debugging and real-time systems for GNU/Linux.
What makes Adeos different from other Hardware Abstraction Layers is that can be loaded as a Linux module to allow another OS to run along with it. In fact Adeos was developed in the context of RTAI to modularize it and to separate the HAL from the RT kernel.

ü Device driver
A device driver, or a software driver is a specific type of computer software, typically developed to allow interaction with hardware devices. Typically this constitutes an interface for communicating with the device, through the specific computer bus or communications subsystem that the hardware is connected to, providing commands to and/or receiving data from the device, and on the other end, the requisite interfaces to the operating system and software applications. Often called a driver for short, it is a specialized hardware dependent computer program which is also operating system specific that enables another program, typically an operating system or applications software package or computer program running under the operating system kernel, to interact transparently with a hardware device, and usually provides the requisite interrupt handling required for any necessary asynchronous time-dependent hardware interfacing needs.
§  Device driver philosophy
The key design goal of device drivers is abstraction. Every model of hardware (even within the same class of device) is different. Newer models also are released by manufacturers that provide more reliable or better performance and these newer models are often controlled differently.
Computers and their operating systems cannot be expected to know how to control every device, both now and in the future. To solve this problem, OSes essentially dictate how every type of device should be controlled. The function of the device driver is then to translate these OS mandated function calls into device specific calls. In theory a new device, which is controlled in a new manner, should function correctly if a suitable driver is available. This new driver will ensure that the device appears to operate as usual from the operating systems' point of view.
Depending on the specific computer architecture, drivers can be 8-bit, 16-bit, 32-bit, and more recently, 64-bit. This corresponds directly to the architecture of the operating system for which those drivers were developed. For example, in 16-bit Windows 3.11, most drivers were 16-bits, while most drivers for 32-bit Windows XP are 32-bit. More recently, specific 64-bit Linux and Windows versions have required hardware vendors to provide newer 64-bit drivers for their devices.
[edit]

§  Device driver development
Writing a device driver is considered a challenge in most cases, as it requires an in-depth understanding of how a given platform functions, both at the hardware and the software level. Because many device drivers execute in kernel mode, software bugs often have much more damaging effects to the system. This is in contrast to most types of user-level software running under modern operating systems, which can be stopped without greatly affecting the rest of the system. Even drivers executing in user mode can crash a system if the device being controlled is erroneously programmed. These factors make it more difficult and dangerous to diagnose problems.
All of this means that the engineers most likely to write device drivers come from the companies that develop the hardware. This is because they have more complete access to information about the design of their hardware than most outsiders. Moreover, it was traditionally considered in the hardware manufacturer's interest to guarantee that their clients would be able to use their hardware in an optimum way. However, in recent years non-vendors too have written numerous device drivers, mainly for use under free operating systems. In such cases, co-operation on behalf of the vendor is still important, however, as reverse engineering is much more difficult with hardware than it is with software, meaning it may take a long time to learn to operate hardware that has an unknown interface.
In Windows, Microsoft is attempting to address the issues of system instability by poorly written device drivers by creating a new framework for driver development known as Windows Driver Foundation (WDF). This includes UMDF User Mode Driver Framework that encourages development of certain types of drivers - primarily those that implement a message-based protocol for communicating with their devices - as user mode drivers. If such drivers malfunction they will not cause system instability. The KMDF Kernel Mode Driver Framework model continues to allow development of kernel-mode device drivers, but attempts to provide standard implementations of functions that are well known to cause problems, including cancellation of I/O operations, power management, and plug and play device support.

§  Device driver applications
Because of the diversity of modern hardware and operating systems, many ways exist in which drivers can be used. Drivers are used for interfacing with:
·        Printers
·        Video adapters
·        Network cards
·        Sound cards
·        Local buses of various sorts - in particular, for bus mastering on modern systems
·        Low-bandwidth I/O buses of various sorts (for pointing devices such as mice, keyboards, USB, etc.)
·        computer storage devices such as hard disk, CD-ROM and floppy disk buses (ATA, SATA, SCSI)
·        Implementing support for different file systems
·        Implementing support for image scanners and digital cameras
Common levels of abstraction for device drivers are:
·        On the hardware side:
·        Interfacing directly
·        Using some higher-level interface (e.g. Video BIOS)
·        Using another lower-level device driver (e.g. file system drivers using disk drivers)
·        Simulating work with hardware, while doing something entirely different
·        On the software side:
·        Allowing the operating system direct access to hardware resources
·        Implementing only primitives
·        Implementing an interface for non-driver software (e.g. TWAIN)
·        Implementing a language, sometimes quite high-level, e.g. PostScript
Choosing and installing the correct device drivers for given hardware is often a key component of computer system configuration.

§  Virtual device drivers
A particular variant of device drivers are virtual device drivers. They are used in virtualization environments, for example when an MS-DOS program is run on a Microsoft Windows computer or when a guest operating system is run inside e.g. VMware. Instead of enabling the guest operating system to dialog with hardware, virtual device drivers take the opposite role and emulate a piece of hardware, so that the guest operating system and its drivers running inside a virtual machine can have the illusion of accessing real hardware. Attempts by the guest operating system to access the hardware are routed to the virtual device driver in the host operating system as e.g. function calls. The virtual device driver can also send simulated processor-level events like interrupts into the virtual machine.


§  Open drivers
·        Printers
·        Scanners

Conclusion:

          To obtain the extreme fruit full results of the existing technologies either the hardware or the software , the adaptive technology can be served as the best solution.

Leave a Reply

Subscribe to Posts | Subscribe to Comments

Blog Archive

- Copyright © Seminar Sparkz Inc -- Powered by Semianr Sparkz Inc - Designed by Shaik Chand -