nstruction on their individual packets before the PEs are handed the following common instruction. This approach has some positives and some negatives. On the positive side, the overall code is sim- pler as all PEs execute the same code. You do not have to worry about allocating code to the available computing resources and fine-tuning applications. On the negative side, more resources seem to be wasted than with a more traditional network processor. This occurs especially when multiple protocols are executed at the same time. Some pack- ets may require IPv4 processing, whereas others may require processing according to a different pro- tocol, such as MPLS. Code running sequentially on a classical network processor would first have to identify the type of protocol involved. It would then invoke the appropriate subroutines by conditional branching to handle it accordingly. However, in the approach taken by the ClearSpeed architecture, code is exe- cuted in parallel inside all the PEs of an MTAP processor and completely independently of what pro- tocol is to be applied on the individual packets inside the PE. In this specific example, this means that both MPLS and IPv4 code will be executed in each PE, which wastes resources. However, you should not rush to conclusions for the following reasons: First, we will mention that at their presentation during the Embedded Processor Forum in June 2001, the company stated that their 400 MHz implementation, which was based on four MTAP cores that each contained 64 PEs, achieved 102.4 GIPS (102,400 MIPS). When combined in a die with 40 Gbps interfaces, for example, the ClearSpeed solution will still enjoy the astounding privilege of having 16 times as many MIPS per packet as the EZchip NP-1 network processor, even when EZchip NP-1 is only allowed to work in a 20 Gbps environment. This means that a lot of computa- tional power can be "wasted" without even coming close to worrying about performance penalties. The individual PEs can nullify instructions that do not apply to their