Posts Tagged ‘theory’

Micro: Types of Inefficiency — X, Allocative, Dynamic, Social, Productive, Pareto, and Distributive

‘X’ inefficiency is a concept that was originally associated specifically with management inefficiencies, but can also be applied more widely.

X inefficiency occurs when the output of firms is not the greatest it could be. It is likely to arise when firms operate in highly uncompetitive markets where there is no incentive for managers to maximize output.

Allocative inefficiency occurs when the consumer does not pay aefficient price.

An efficient price is one that just covers the costs of production incurred in supplying the good or service.

Allocative efficiency occurs when the firm’s price, P, equals the extra (marginalcost of supplyMC. This is efficient because the revenue received is just enough to ensure that all the resources used in the making of a product are sufficiently rewarded to encourage them to continue supplying.

Dynamic inefficiency occurs when firms have no incentive to become technologically progressive. This is associated with a lack of innovation, which leads to higher production costs, inferior products, and less choice for consumers.

There are two ways in which firms can innovate:

  1. New production methods, such as when applying new technology to an existing process.
  2. New products, which are a feature of markets with highly competitive firms, such as those in the consumer electronics.

Innovation, researchand development are expensive and risky, so firms will expect a fair level of profits in return. However, because the price mechanism may not generate profits for the supply of public and merit goodsthere is often an absence of dynamic efficiency in these markets.

Social inefficiency occurs when the price mechanism does not take into account all the costs and benefits associated with economic exchange.

The price mechanism will only take into account private costs and benefits arising directly from production and consumption, not the external costs and benefits incurred by thirdparties.

Social costs refer to the total costs borne by society as a result of an economic transaction, and include private costs plus external costs. Social benefits are the private benefits plus external benefits resulting from a transaction.

A transaction is socially efficient if it takes into account costs and benefits associated with the transaction – that is, the social costs and benefits.

Productive inefficiency occurs when a firm is not producing at its lowest unit cost. Unit cost is the average cost of production, which is found by dividing total costs of production by the number of units produced.

It is possible that in markets where there is little competition, the output of firms will be low, and average costs will be relatively high. This is likely to occur if a few firms, or just one, dominate the market, as in the case of oligopoly and monopoly.

Pareto inefficiency is associated with economist Vilfredo Pareto, and occurs when an economy is not operating on the edge of its PPF and is, therefore, not fully exploiting its scarce resources.

This means that the economy is producing less than the maximum possible output of goods and services, from its resources.

Distributive inefficiency occurs when goods and services are not received by those who have the greatest need for them. Abba Lerner first proposed the idea of distributive efficiency in his 1944 book The Economics of Control.

Breakpoints and other Debug Events

There are 3 major types of events you encounter when debugging:

  1. Breakpoints
  2. Memory violations (!!)
  3. Exceptions
buffer overflow, for example,  is probably the most well-known for of memory violation and is both a notorious headache for end-users of buggy software and a breath of fresh air for reverse engineers.
     There are 3 types of breakpoints of interest:
  1. Software Breakpoints
  2. Hardware Breakpoints
  3. Memory Breakpoints
Soft breakpoints are used specifically to halt the CPU and are the most common type of breakpoint. Soft breakpoints are sing-byte instructions that stop execution of the debugger process. In RStudio you can set a soft breakpoint simply by clicking on the left margin of a particular line or function (or by choosing “Rerun with Debugger” in the error traceback dialog). Soft breakpoints can be persistent if they remain after the CPU has executed its tasks or one-shot if they are cleared out. Soft breakpoints are associated with the interrupt 3 (INT3) event.

Using assembly language, to process a soft breakpoint the single byte instruction must be converted into an operation code (a.k.a. an opcode).

In x86 Assembly language an instruction looks like:
which tells the CPU to move the value stored in the EBX register to the EAX register. In native opcode, this would just be:
A common analogy is that x86 Assembly language is to individual opcodes what DNS is to IP addresses. Memorizing thousands of opcodes is impractical, whereas assembly language is much more manageable.

Hardware breakpoints, associated with the INT1 event, are useful when a small number of breakpoints are needed and the software can’t be modified. When registers are used in this way they’re known as debug registers.

Most CPU’s have 8 debug registers denoted as DR0 through DR7. Up to 4 of the 8 registers can be used for breakpoints and each can only set up to 4 bytes at a time. This means you can only use up to 4 hardware breakpoints at a time. DR0 to DR3 is usually reserved for the breakpoint addresses. DR4 and DR5 are reserved and DR6 is the status register (which determines the type of debugging event triggered by a breakpoint).
Unlike soft and hard breakpoints, memory breakpoints are not true breakpoints. Rather, a memory breakpoint refers to the permissions on a region or page of memory set by a debugger.
memory page is the smallest portion of memory that an OS deals with.
Examples of memory page permissions:
  1. Page execution
  2. Page read
  3. Page write
  4. Guard page
The guard page permission allows us to separate the heap and the stack and can ensure that a chunk of memory does not grow past a given boundary. It does so by  throw a one-time exception whenever accessed and then returning to its original status.